How to Plan a Cloud Storage Migration: The Complete Checklist

A cloud storage migration checklist is a structured plan that covers every step from audit to validation when moving files between cloud providers. It exists because the gap between "copy files to a new service" and "actually migrate a team's working environment" is enormous.

The files themselves are the easy part. The hard part is everything attached to them: who has access, which links are shared externally, what integrations depend on specific folder structures, and which files haven't been touched in three years but would cause a crisis if they disappeared.

According to Flexential, 23% of organizations experience some form of data loss during migration. Permission mapping errors affect roughly 1 in 4 enterprise migrations, often because different platforms handle access control in fundamentally different ways. Dropbox uses shared links and team folders. Google Drive uses ownership-based sharing. SharePoint uses role-based site permissions. Moving between any two of these means translating an entire access model, not just copying files.

A proper checklist breaks the migration into phases: pre-migration audit, planning, execution, and validation. Each phase has specific deliverables that prevent the next phase from going sideways. Skip the audit and you'll discover halfway through that 40% of your data is redundant. Skip permission mapping and your legal team loses access to their contracts folder on Monday morning.

The rest of this guide walks through each phase with specific action items you can assign to your team.

Helpful references: Fast.io Workspaces, Fast.io Collaboration, and Fast.io AI.

Before you move a single file, you need a complete picture of what you're working with. This audit phase prevents the most common migration failures.

1. Inventory total data volume and file counts

Log into your current provider's admin console and pull storage usage by department or team. Note the total volume, the number of files, and the largest individual files. Large files (video assets, design files, database backups) need special handling because they're more likely to fail during transfer and take longer to retry.

2. Identify active vs. dormant data

Most cloud storage accounts are 30-50% dormant data: files nobody has opened in over a year. Pull last-accessed dates if your provider supports it. You don't need to migrate dead weight. Archive it separately or delete it with stakeholder approval.

3. Map your folder structure

Export or screenshot your top-level folder hierarchy. Document any naming conventions, nested structures deeper than 4 levels, and folders shared across multiple teams. Deep nesting and long path names cause failures on some platforms due to character limits.

4. Document all sharing links

External sharing links are the most fragile element of any migration. Every public link, shared folder invitation, and embedded document link will break when files move. Export a list of all active shares from your admin panel. Prioritize the ones shared with clients, vendors, or partners because those are the links you can't quietly fix after the fact.

5. Audit user permissions

Export your current permission structure: who has owner, editor, and viewer access to each workspace or folder. Map these roles to equivalent roles on your destination platform. This is where most enterprise migrations hit trouble. Google Drive's "Editor" doesn't map cleanly to SharePoint's "Contribute" role, for example.

6. List all integrations and connected apps

Check which third-party tools connect to your storage: Slack integrations, Zapier automations, backup tools, design apps that sync from cloud folders. Each one needs to be reconnected or replaced after migration.

7. Check compliance and retention requirements

If your industry requires data retention policies, verify that your destination platform supports equivalent retention rules. Document any files under legal hold. These cannot be deleted from the source until the hold is released, even after migration.

8. Verify destination platform limits

Every platform has limits: maximum file size, path length restrictions, forbidden characters in filenames, API rate limits for bulk transfers. Check these against your inventory. A single file named with a special character can stall an entire batch transfer.

9. Assess bandwidth and transfer time

Calculate how long the transfer will take at your available bandwidth. A 5 TB migration on a 100 Mbps connection takes roughly 4.5 days of continuous transfer. Factor in API throttling from both source and destination providers, which can double or triple that estimate.

10. Identify version history requirements

Decide whether you need to migrate version history or just current files. Version history migration is more complex and not supported by all migration tools. If you need it, confirm your tool handles it before starting.

11. Plan your rollback strategy

Define the point of no return. Keep the source account active and read-only during migration so you can roll back if validation fails. Set a specific date for decommissioning the source, at least two weeks after migration completes.

12. Assign ownership and timeline

Name a migration lead. Set phase deadlines. The audit phase typically takes 1-2 weeks for organizations with under 10 TB. Rushing it is how teams end up in the 23% that lose data.

With the audit complete, you have the data you need to build a migration plan that accounts for your specific risks.

Choose your migration approach

There are three common strategies:

• Big bang migration: Move everything at once over a weekend. Works for small teams (under 50 users) with less than 1 TB. Fast but risky because there's no gradual rollout.
• Phased migration: Move one department or team at a time over several weeks. Gives you a chance to catch problems early with a smaller group before migrating the whole organization. This is the most common approach for mid-size teams.
• Parallel run: Keep both systems active for a defined period while users gradually shift to the new platform. Safest but most expensive, since you're paying for two services and managing sync between them.

Select your migration tool

For cloud-to-cloud migration, you have several options. Direct provider tools (like Google Workspace Migrate or SharePoint Migration Tool) work well when moving into that specific ecosystem. Third-party tools like Movebot, CloudFuze, or Cloudsfer handle cross-platform migrations with permission mapping and scheduling. For smaller moves, manual download-and-upload or the destination provider's import feature may be enough.

Build a permission mapping table

This is the single most important planning document. Create a spreadsheet that maps every role from your source platform to an equivalent role on the destination. Include edge cases: What happens to "link-only" shares? How do you handle files owned by former employees? What about nested permissions where a subfolder has different access than its parent?

Set your communication plan

Users need to know what's happening and when. Send a timeline at least two weeks before migration starts. Include: what will change, what they need to do (if anything), when to expect downtime, and who to contact if something breaks.

Schedule around your team's workflow

Don't migrate your sales team's files during end-of-quarter. Don't migrate your finance team's files during month-end close. Check the calendar for deadlines, product launches, and holidays. The best migration windows are boring weeks.

Migrating to a New Cloud Workspace?

Fast.io imports files directly from Google Drive, Dropbox, OneDrive, and Box with folder structure preserved. Files are automatically indexed for search and AI chat once they land. Free plan includes 50 GB storage, no credit card required. Built for cloud storage migration checklist workflows.

Sign Up Free

Execution is where preparation pays off. Follow the plan, but stay flexible when unexpected issues surface.

Run a pilot migration first

Pick a small, non-critical folder (100-500 files) and migrate it end to end. Verify that files arrive intact, permissions map correctly, sharing links are documented, and version history transfers if required. Fix any issues before scaling up.

Migrate in batches

Even with a "big bang" approach, transfer files in batches rather than one massive operation. Batches of 10,000-50,000 files give you manageable checkpoints. If a batch fails, you retry that batch instead of restarting everything.

Monitor transfer progress

Track completion percentage, error counts, and transfer speed in real time. Most migration tools provide a dashboard. Watch for throttling from either provider, which shows up as a sudden drop in transfer speed. If you hit rate limits, slow your batch size or add delays between batches.

Handle errors as they occur

Common transfer errors include:

• File name conflicts: Destination already has a file with the same name. Decide in advance whether to overwrite, rename, or skip.
• Character encoding issues: Files with special characters, emojis, or non-ASCII characters in names may fail on certain platforms.
• File size limits: Some platforms restrict individual file sizes. Identify oversized files during the audit so they don't surprise you mid-transfer.
• Path length limits: Windows-based platforms often enforce a 260-character path limit. Deeply nested folders with long names hit this regularly.

Preserve metadata

File timestamps (created, modified), tags, and descriptions are often lost during migration. If metadata matters for your workflows, verify your tool preserves it. Some tools require explicit configuration to carry metadata across.

Lock the source

Once you start migrating a batch, set the source folder to read-only if possible. Users editing files in the source during transfer creates version conflicts that are painful to untangle. Communicate the read-only window .

Fast.io's Cloud Import feature handles the OAuth connection to Google Drive, Dropbox, OneDrive, and Box directly. It preserves folder structure during import and automatically indexes files for search and AI chat once they land in a workspace. For teams migrating to Fast.io, this eliminates the need for a separate migration tool for those four providers.

Validation is where teams cut corners and regret it weeks later. Budget at least as much time for validation as you spent on execution.

Verify file counts and checksums

Compare the total file count on the destination against your source inventory. For critical files, run checksums (MD5 or SHA-256) on both sides to confirm data integrity. A matching file count doesn't guarantee integrity because files can arrive corrupted or truncated during transfer.

Test permission access

Have at least one person from each team verify they can access their files with the correct permission level. Check both internal team access and external sharing. The most common post-migration support ticket is "I can't access my folder anymore."

Validate sharing links

For every external sharing link you documented during the audit, verify its replacement works. Update links in emails, documents, websites, and client portals. If you used a redirect approach, test the redirects.

Check integrations

Reconnect every third-party integration you documented during the audit. Test each one: does the Slack integration still post file notifications? Does the backup tool still run? Do design applications still sync from the expected folders?

Verify search and discoverability

Users rely on search to find files. Test search on the destination platform with common queries your team uses. If your new platform supports AI-powered search or semantic search, verify that indexing has completed. On Fast.io, files imported through Cloud Import are automatically indexed by Intelligence Mode, so semantic search and AI chat work immediately after import completes.

Run a user acceptance period

Give your team 1-2 weeks to work in the new environment before decommissioning the source. Collect feedback through a shared channel or form. Common issues that surface during this period: missing files that weren't in the original inventory, workflows that depended on specific folder paths, and automation scripts that hardcoded the old provider's API endpoints.

Document what you learned

Write a short post-mortem: what went well, what broke, and what you'd do differently. This document becomes invaluable the next time your organization needs to migrate, whether that's switching providers again or onboarding an acquired company's files.

After researching dozens of migration case studies and post-mortems, the same failures keep showing up. Here's what to watch for.

Underestimating the permission mapping effort

Teams routinely spend 60% of their migration time on permission mapping after planning to spend 10%. Different platforms don't just use different role names. They use different permission models entirely. Google Drive's sharing model is file-centric. SharePoint's is site-centric. Dropbox Business uses team folders with inherited permissions. Mapping between these requires a decision for every edge case, and mid-size organizations have hundreds of edge cases.

Ignoring shared link dependencies

If your team shares links in Notion pages, Slack channels, email templates, or client-facing documents, those links break silently after migration. Nobody notices until a client clicks a dead link in a proposal three weeks later. Audit shared links proactively and set up redirects where possible.

Skipping the pilot

A pilot migration with 200 files takes a few hours and catches 90% of the issues you'd otherwise discover at scale. Skipping it to "save time" almost always costs more time in cleanup.

Migrating everything

Organizations that audit before migrating typically find 30-50% of stored data is redundant, obsolete, or trivial. Migrating dead data wastes transfer time, inflates storage costs on the new platform, and makes the new environment feel just as cluttered as the old one. Clean first, then move.

Not planning for the long tail

The bulk migration finishes in days. The long tail of exceptions, edge cases, and stragglers takes weeks. Budget for it. Someone will have files in a personal folder that wasn't included in the team migration. Someone else will have a critical spreadsheet embedded in an email that links to the old system. Plan for at least 2-4 weeks of post-migration support.

Forgetting mobile and desktop sync clients

If users have desktop sync apps (like Google Drive for Desktop or Dropbox's desktop client), they need to uninstall the old client and install the new one. Forgetting this creates ghost sync conflicts where the old client tries to sync to a read-only or deleted source. Include client-side cleanup in your communication plan.