Migrating to Zoho WorkDrive: Planning, execution, and validation

A company rarely realizes how complicated its file system has become until it needs to be migrated to a new platform.

Over the years, personal drives begin holding departmental documents. Project folders get shared with people who have since changed roles. Former employees leave behind files the business still needs. Shared spaces grow into thousands of folders, and nobody is completely certain which ones are still active.

This is why migrating to a new content platform involves more than transferring files from point A to point B. You also have to decide what should move, where it should live, who should have access, and how you'll verify that nothing important was left behind.

Zoho WorkDrive provides built-in migration capabilities for supported Google Workspace, Dropbox, and Microsoft OneDrive environments. You can manage migration through the WorkDrive Admin Console, where administrators can initiate or request migration, monitor progress, and review reports. If you're moving from another cloud storage service, contact our support team to determine the appropriate migration route.

But the quality of a migration is determined by more than the tool itself. It depends on how well you understand the environment you're leaving and how deliberately you prepare the one you're moving into.

First, understand what you're bringing with you  

Consider a business that has been using the same cloud storage platform for five years.

Finance may have an official shared repository, but some important spreadsheets still sit inside employees' personal drives. Marketing may have hundreds of gigabytes of videos and design files. Project teams may have folders shared across departments. Former employees may still technically own documents that are used every month.

Migrating everything exactly as it exists would move the data, but it could also move years of accumulated clutter and unclear ownership structures.

Start by understanding the broad shape of your existing environment: the number of users, approximate data volume, personal and shared repositories, business-critical folders, former-user content, and any unusually large or specialized files.

You don't need to audit every document. You need enough visibility to identify what deserves attention before migration.

This matters because migration behavior differs by source platform. WorkDrive's Google Workspace migration, for example, can migrate content from My Drive and Shared Drives, while Dropbox and OneDrive follow their own migration models, prerequisites, and limitations.

Knowing your source is therefore the first step toward understanding what your destination will look like.

Choose the migration route that matches your source  

Not every "Google Drive migration" or "Microsoft migration" means the same thing.

WorkDrive's built-in migration tool currently supports organizational migrations from Google Workspace, Dropbox, and eligible Microsoft OneDrive plans. The exact prerequisites and authorization process differ for each platform, so check the currently supported source plans and migration requirements before you begin.

Personal accounts can require a different route. If you're moving from a personal Google Drive account, for example, WorkDrive doesn't provide the same built-in migration used for Google Workspace. Instead, export your data using Google Takeout and then move it into WorkDrive.

Large amounts of data already stored on a computer are another case. For large volumes of locally stored data, you can use WorkDrive TrueSync to move files and folders into WorkDrive directly from your computer.

Before setting a migration date, make sure both sides are ready. WorkDrive's built-in migration capability is currently available on its paid Starter, Team, and Business plans, and you'll need the appropriate administrative access to both WorkDrive and the service you're migrating from.

The detailed setup becomes source-specific from here. A Google Workspace migration has prerequisites that aren't relevant to OneDrive, and Microsoft has its own account and authorization requirements. Those implementation details belong in the respective migration guides.

At this stage, the important thing is to establish which migration route applies to your environment before you begin moving anything.

Decide where your content should live in WorkDrive  

This is where migration becomes more than a technical exercise.

Imagine that an employee named Alex has the following folder in their personal drive:

Alex's Drive → Finance → FY2026 → Approved budgets

The folder may technically belong to Alex, but the information clearly belongs to Finance.

Simply reproducing that structure in another personal workspace preserves the original ownership problem.

In WorkDrive, personal working content can live in My Folders, while organizational content can be managed through Team Folders. That distinction gives you an opportunity to rethink where important information should live after migration.

The previous example could become:

Finance Team Folder → FY2026 → Approved budgets

Now continued access to the documents isn't dependent on one employee remaining with the company.

This doesn't mean migration is the right moment to reorganize every folder you've ever created. Combining a major cleanup exercise with a platform migration can introduce unnecessary complexity.

Instead, resolve the obvious ownership questions. Departmental content should have a departmental home. Project content that needs to survive changes in personnel should have an organizational home. Personal working files can remain personal.

A useful question is:

Does this content belong to an individual, or should the organization continue owning and using it regardless of who works here?

Getting that distinction right before migration can make the destination much easier to manage later.

Users come before permissions  

Once you know where content should go, look at who needs to access it.

WorkDrive's migration processes rely on mapping users from the source platform to users in WorkDrive. This becomes particularly important when email addresses or domains are changing during the migration.

For Google Workspace migration, for example, only active WorkDrive users can be migrated. WorkDrive also allows administrators to map a source user's email address to a different WorkDrive email address through the migration CSV, which is useful when domains or usernames have changed.

Former employees deserve attention too.

Their user accounts may no longer matter, but their content might. Contracts, customer records, research, project files, and other business information shouldn't disappear from the migration plan simply because their original owner has left.

Before migrating, decide whether that content should be retained, where it belongs, and who should be responsible for it.

Solving ownership before migration is much easier than discovering afterward that an important repository was attached to someone who was never mapped.

Don't expect every permission to translate exactly  

Permissions are one of the areas where migrations between platforms become complicated.

Google, Microsoft, Dropbox, and WorkDrive don't represent collaboration in exactly the same way. Each has its own concepts for personal storage, shared spaces, users, groups, roles, links, and inherited access.

The result is that permission behavior varies by migration source.

For example, when migrating from Google Workspace, certain sharing relationships from My Drive can be retained and Shared Drives can be translated into private WorkDrive Team Folders. However, limitations apply to areas such as external sharing, unmapped users, restricted folders, and Shared Drive permissions.

Rather than asking whether every historical permission can be reproduced exactly, migration gives you an opportunity to ask a more useful question:

Who needs access to this content now, and what should they be able to do with it?

Some permissions may have accumulated because someone needed temporary access years ago. Others may be essential to everyday operations.

Your existing permissions are valuable input, but migration is also an opportunity to make sure the destination reflects how people actually need to work today.

Know what won't migrate before you start  

A file missing after migration doesn't always mean the migration failed.

Every source platform contains content types and conditions that may behave differently during migration. Depending on the source, this can include native file types, file versions, shortcuts, oversized files, trashed content, sharing relationships, or other objects that aren't supported by that particular migration workflow.

Migration limitations vary across Google Workspace, Dropbox, and OneDrive, so review the requirements for your source platform before starting.

The important lesson isn't to memorize every limitation. Reviewing these limitations beforehand helps you identify content that may need to be handled separately.

Instead, create an exception list before migration.

If you know beforehand that certain content requires separate handling, it's part of your migration plan. If you only realize after that you'll need to handle an exception, it becomes a migration incident.

Knowing the difference between an expected exclusion and an unexpected failure makes post-migration validation much easier.

What happens when migration begins?  

Once the prerequisites are complete, migration is managed through the WorkDrive Admin Console.

The exact starting process varies by source. Google Workspace migration can be initiated directly from the migration area, while Dropbox and OneDrive currently use a request-and-enable process before administrators proceed with migration.

From there, administrators can complete the required mapping, start migration, monitor progress, and review the resulting migration reports.

Those reports are important because migration isn't simply a question of whether the process is finished. Administrators need visibility into what was migrated and what issues still require further attention. WorkDrive provides migration monitoring and detailed reports to help administrators review migration activity and identify exceptions.

Cutover planning matters here too.

For larger migrations, consider scheduling the move during a period of lower activity and ask users to avoid—or at least keep track of—changes made in the source while migration is underway.

Don't treat migration as permanent synchronization between the old platform and WorkDrive. Source-specific workflows can restrict migrating the same user's content again. For Google Workspace, for example, each user can only be migrated once per service. This means content added to that user's Drive after migration can't simply be picked up by rerunning the same user migration.

That means there should be a clear point at which users stop treating the old repository as their working environment and begin using WorkDrive.

The process is better understood as:

Prepare → migrate → review → cut over

Rather than simply:

Start → finish

A completed migration still needs validation  

One useful safeguard is that your original source data remains intact during supported migrations. Migrating from Google Workspace or Dropbox, for example, doesn't delete the original data from the source platform.

Use that overlap period.

Don't shut down the old platform the moment WorkDrive reports completion. Keep the source available long enough to compare and verify that what matters most has been successfully migrated.

Start with business-critical repositories rather than randomly checking files. Confirm that important folders arrived, representative files open correctly, and people can access what they need as expected.

Then ask actual users to work in the destination.

Can Finance find its monthly reports? Can a project member reach the right shared content? Can someone who needs to edit actually edit?

File counts are useful, but migration succeeds only when people can continue working.

The migration report gives administrators technical evidence. User validation gives you operational evidence.

You need both.

What if something is missing?  

When an expected file doesn't appear, first establish whether it was eligible to migrate.

If it falls under a documented limitation for that source platform, it may need to be handled separately. If the content was eligible but failed, the migration report should be the starting point for investigation.

WorkDrive's migration reports can help administrators identify failed items and understand why some content didn't migrate as expected. For example, the Google Workspace migration workflow provides migration reports that administrators can use to investigate unsuccessful items. Depending on the cause and source platform, the next action may be to retry the item, move it manually, correct a mapping or access issue, or escalate it for further investigation.

For larger migrations, keep track of these exceptions rather than solving them informally. Record what was affected, why, who owns the resolution, and what needs to happen next.

The detailed diagnostic process belongs in our WorkDrive migration troubleshooting guide. At the pillar level, one principle is enough:

Don't judge migration quality by the progress bar. Judge it by what you can verify.

When is the migration actually finished?  

A migration is finished when WorkDrive has become the environment your organization can confidently work from.

That means the required users are present, critical content has been validated, shared content has the right organizational home, access permissions are working, important exceptions are understood, and teams know where they should work going forward.

Only then should you begin retiring the source platform.

A useful way to frame the complete migration journey is:

The actual file transfer is only one stage in that journey.

Final thoughts  

Migration is one of the few times an organization gets to reconsider years of accumulated content decisions.

You don't need to use that opportunity to redesign everything. But it is worth correcting the things that matter: business content living in personal accounts, unclear ownership, obsolete access, and repositories that nobody knows how to validate.

WorkDrive provides the migration workflows, user mapping, destination workspaces, monitoring, and reporting needed to support the move. What determines the quality of the outcome is how deliberately those capabilities are used.

Understand the source first. Decide what the destination should look like. Move the content using the appropriate migration path. Validate what matters. Help users make WorkDrive their new working environment. And only then leave the previous platform behind.

From here, the process becomes source-specific. If you're moving from Google, our Google Workspace to WorkDrive migration guide goes deeper into prerequisites, user mapping, My Drive, Shared Drives, and Google-specific migration considerations. For Microsoft environments, continue with our Microsoft OneDrive to WorkDrive migration guide. If your migration has already run but you're dealing with missing, failed, or mismatched files, use our WorkDrive migration troubleshooting guide.

Planning a move to WorkDrive? Explore WorkDrive for your organization or talk to our team about your migration requirements.

Frequently asked questions  

Which platforms can I migrate to WorkDrive from?  

WorkDrive currently provides built-in migration for Google Workspace, Dropbox, and supported Microsoft OneDrive plans. If you use another cloud storage service, contact our support team to identify the best available migration approach.

Can I use WorkDrive's migration tool during a free trial?  

Yes. If you need to evaluate WorkDrive's migration capabilities during your trial, reach out to our presales team. Migration access can be enabled on a request basis to support your evaluation.

Can I migrate from a personal Google Drive account?  

Yes, but not through the organizational Google Workspace migration workflow. For a personal Google Drive account, export your content using Google Takeout and then move the exported data into WorkDrive.

Does my existing cloud storage subscription need to remain active during migration?

Keep the source service active and accessible until migration is complete. For example, Google Workspace migration requires an active source account with the necessary administrative access. If your Google Workspace subscription has expired, you may need to reactivate it before migration can proceed. Keeping the source available through validation also gives you a reference if files or access need to be checked.

Will all sharing permissions migrate?  

Not necessarily. Permission behavior depends on the source. Google Workspace migration can retain certain sharing relationships, subject to limitations, while other migration sources behave differently. Check the requirements for your source platform and validate important access after the move.

Will migration delete my files from the old platform?  

No. Your original source data remains intact when migrating from supported sources such as Google Workspace and Dropbox. Keeping the source available until validation is complete gives you a reference point before retiring the old environment.

Can I stop or cancel a WorkDrive migration after it starts?  

Don't begin a migration until you've validated the users, mappings, scope, and destination. Depending on the migration source and its current status, an active migration may not be cancelable once it has started. If a migration that's already underway needs intervention, contact our support team.

Can I migrate new data from the same source user again later?  

Don't assume you can. Migration behavior is source-specific. In many cases, each user can only be migrated once per service, so data added to that user's Drive after migration can't be migrated again through the same user migration. Plan your cutover accordingly.

How can I verify that the migration succeeded?  

Use more than one signal. Review the migration report, check business-critical repositories against the source, test representative files, confirm that users have the expected access, and ask business owners to verify the content they depend on. Migration is complete when the destination works for the business—not merely when the transfer reports completion.