Migration Sizing Bench

Every quote for a Microsoft 365 or Google Workspace exit in this market is priced in gigabytes. Ask three vendors how long it takes to move 200 GiB and you get three numbers derived from the same arithmetic: volume divided by link speed. That arithmetic is wrong, and it is wrong in the direction that costs money, because it gets the ordering of the work wrong and not just its duration.

So we built a bench to measure it rather than argue about it. A fixed-seed synthetic tenant generates nine data types, from mailboxes to video, spanning four orders of magnitude in mean file size. A timing harness runs the file leg and the mail leg, serially and in parallel, against a real Nextcloud and Dovecot target rather than a mock. A model fitter turns the runs into per-file and per-byte coefficients. Every raw run is retained, so any number published here traces back to a run.

What we measured

The fit is wall seconds = 0.179 × files + 4.33e-9 × bytes, at R² = 0.998 across all nine profiles. Read the coefficients rather than the hours: the per-file term dominates everything except video.

Why it holds

That term is protocol round trips, and bandwidth does not help round trips. This is the part that surprises people: divide the link by eighteen and office documents lose only thirteen percent of their throughput, because they were never bandwidth-bound to begin with. One identical 200 GiB corpus takes 40 machine-hours as office documents and 4.8 as video, a factor of 8.4. A quote priced in gigabytes does not merely get the number wrong. It gets the order wrong, and schedules the cheap job first.

What this changes in practice: sizing a migration starts by counting objects, not by measuring volume, and the mail leg gets scheduled first because it carries the most objects per gigabyte.