Cloud Transfer Planner: What Will Break Before You Start

Large cloud transfers do not usually fail at the beginning. They fail eleven hours in, at a number nobody mentioned, on a Friday night.

The limits are all published. They are just published separately, in help articles written for a different question, and none of them appear in the interface at the moment you press the button.

The three that catch people

750 GB in 24 hours. Google states that each user can upload and copy 750 GB to Drive within a rolling day. This is not a setting, a tier or a support request — there is no documented way to raise it. A 3 TB migration is a four-day job whether you planned it that way or not.

10,000 files. Both Dropbox and OneDrive cap bulk browser downloads at ten thousand files. That sounds enormous until you count a photo library, which will usually clear it on its own. Dropbox is explicit that files in nested folders count toward the same total, so the obvious workaround of splitting by top-level folder often does not work.

20 GB overall. Microsoft's compressed download ceiling is 10 GB per zip and 20 GB in total. For a service selling terabytes of storage, being asked to retrieve it through a browser 20 GB at a time is not a serious proposition — which is why the sync client, not the website, is the answer for any real OneDrive exit.

Why the clock matters more than the cap

The calculator gives you a transfer time at the theoretical maximum for your line speed, and it is worth being clear about what that number is and is not.

It is arithmetic: gigabytes, converted to bits, divided by your connection. It assumes the transfer never pauses, never retries, and never spends a moment on anything but payload.

No real transfer achieves it. Every file carries its own setup cost, so a million small files take dramatically longer than one enormous one at identical total size. Consumer connections are asymmetric, and the upload figure — the one that matters here — is usually a fraction of the download speed on the advertisement.

So treat the output as a floor. If the floor is already longer than the window you have, you do not have a plan, and no amount of optimism changes that.

Where the floor collides with an expiry

This is the failure mode worth designing around, and it is specific to exports.

Google Takeout archives expire in about seven days and permit five downloads. Seven days is 168 hours. If your data takes 90 hours to pull at your real speed, a single interruption — a router reboot, a laptop sleeping, one failed attempt — can put you past the expiry with nothing to show for it. Then you request the archive again, and wait for it to build again.

Request it in sections. Smaller archives build faster, download faster, and a failure costs you one section rather than everything. It is slower on paper and far more likely to finish.

Count before you start, and count afterwards

Whatever the method, the discipline that prevents silent loss is arithmetic at both ends.

Note the file count and total size before you begin. Check them again when you think you are done. If the two do not match, you have a gap — and finding it while you still have the source account costs an afternoon, while finding it next year costs the files.

Nothing in any of these products does this check for you.

If the transfer is an exit rather than a migration, the exit reports score what each product actually lets you take. If individual files are refusing to move, the name and path checker covers the other common cause.