Migrating cloud services looks like a copy operation and isn't. Files move fine. What doesn't move is everything wrapped around them: sharing links other people are using, version history, native document formats, comments, and the folder someone shared with you that was never yours to move.
Here's how to do it without discovering the gaps in six months.
Before you start: what will not survive
Set expectations, because these losses are unavoidable and it's better to plan around them than to be surprised.
Shared links break. Every link you've given anyone points at the old service. When you eventually delete the source, those links die. If you've shared links publicly — in a listing, a document, an email signature — you'll need to replace them one by one.
Version history doesn't transfer. The new service starts your files at version one. If old versions matter, download the specific ones you need as separate files before migrating.
Comments and annotations don't transfer. Comment threads on documents live in the platform, not the file.
Native documents need converting. A browser-native document isn't a file in the ordinary sense. Exporting it produces a standard-format file, and the conversion is imperfect — complex formatting, embedded elements, and scripts often break. Anything that matters should be opened and checked after conversion.
Permissions don't transfer. Everything you'd shared with collaborators needs resharing in the new service.
Timestamps may not survive. Depending on the method, files can arrive with today's date as their creation and modification time. If chronological order matters — photos, financial records — check this early with a test batch, because it's very hard to fix afterwards.
"Shared with me" isn't yours. Files other people shared with you live in their account. You can copy them, which creates a new file you own, but you can't move them. Decide deliberately which of these you actually need.
Step 1: audit before you move
Don't migrate everything. Migration is the best opportunity you'll ever have to not carry forward a decade of junk.
Go through your source account and mark:
- Move — active material you need
- Archive — keep it, but to an external drive, not the new service
- Delete — genuinely finished with it
Most people find a third to a half falls in the second two categories. Moving less means a faster migration, a smaller plan, and a cleaner starting point.
Also note, in a text file: every shared link you're aware of, and who has it. This list is what you'll work through afterwards.
Step 2: choose a method
Download and re-upload. Download everything to your computer, then upload to the new service. Slow, requires enough local disk space, and it's the most reliable and most transparent method. You can see exactly what you have at the midpoint, and you get a free local copy in the process.
This is the right choice for most personal migrations.
Run both desktop clients at once. Install both services' desktop apps, and drag files from one synced folder to the other. The clients handle upload and download. Simple, but it can be slow, it consumes local disk space for anything not streaming, and a mid-transfer interruption can leave you unsure what completed.
A third-party transfer service. Several exist that move data cloud-to-cloud without it passing through your computer. They're fast and convenient, and the trade-off is that you're granting a third party full access to both accounts. If you use one, prefer an established provider, check what they say about data retention, and revoke the access permissions immediately afterwards.
Provider export tools. Some providers offer a bulk export of your data as a downloadable archive. These are thorough — often including metadata that a simple download misses — and they're the best option if you're worried about completeness.
Step 3: move in batches, not all at once
Take the largest folder tree first, and move it as a single batch. Then verify it before starting the next.
Batching matters because a failed 500GB transfer tells you nothing about what got through. A failed 20GB batch is easy to check and easy to redo.
Order the batches so the most important material moves first, while your attention is highest.
Watch for these failures, which are common and often silent:
Path length limits. Deeply nested folders with long names can exceed limits and fail to transfer. The failure is frequently reported quietly or not at all. If you have a deep structure, flatten the worst of it before migrating.
Illegal characters. Some characters permitted on one platform are rejected on another. Files with these in their names get skipped or renamed.
Zero-byte files. Files that transfer as empty shells. These look correct in a listing and contain nothing, which is why counting files isn't sufficient verification.
Upload throttling. Some services limit how much you can upload per day. Hitting the limit mid-migration stalls the transfer, sometimes without a clear message.
Step 4: verify properly
This is the step people skip and it's the one that determines whether the migration succeeded.
Compare file counts and total size. Both services can report these per folder. They should match closely. Small discrepancies are normal (system files, format conversions); large ones need investigating.
Spot-check by opening files. Not looking at a listing — actually opening them. Ten files, chosen from different folders and different types: a document, an image, a video, a spreadsheet, a design file, something old, something large. Zero-byte and corrupted transfers only reveal themselves on open.
Check the oldest and largest files specifically. These fail most often — old files may use formats that convert badly, and large files are most likely to have been interrupted.
Check dates. Sort by modified date in both places and see if the order matches.
Verify converted documents. Every native document you exported should be opened and checked, especially anything with complex layout, tables, or embedded content.
Step 5: rebuild sharing
Work through the list you made in step one.
For each shared item, reshare from the new service and send the new link to whoever needs it. For anything shared publicly, update the source — the listing, the page, the document that links to it.
Set a reminder to check for links you missed. Search your sent email for the old service's link format; that finds most of them.
Step 6: leave the old account alive for a while
Don't cancel immediately. Downgrade to the free tier if you can, and leave the account intact for at least three months.
The reason: you will discover something missing, and you'll discover it by needing it. Three months covers most of that. Six is better if the account is free.
During that window:
- Note anything you find missing and copy it over
- Watch for people telling you a link is broken
- Check the old account's trash before it purges, in case something was deleted rather than moved
Only after that window, and after you've taken a full local copy of the old account as an archive, should you close it.
Step 7: take a local copy before closing anything
Before you delete or close the source account, download a complete copy to an external drive and put it somewhere safe.
This costs you one drive and it converts an irreversible action into a reversible one. Migration is exactly the kind of complicated multi-step process where something goes wrong quietly, and the archive is what makes that recoverable.
The migration checklist
- Audited: decided what moves, what archives, what goes
- Listed every shared link and who has it
- Chose a method; checked whether it preserves timestamps with a test batch
- Flattened any deeply nested folders
- Exported native documents and checked the conversions
- Moved in batches, verifying each
- Compared counts and sizes; opened ten sample files
- Rebuilt sharing and updated public links
- Took a full local copy to an external drive
- Left the old account alive for three months before closing
Next in this series: Selective Sync and Smart Sync Explained