Why a Microsoft 365 migration takes as long as it takes

It is the first question on every call, and the honest answer annoys people: it depends far less on your budget than you would like. Most of what sets the schedule of a Microsoft 365 tenant migration is fixed by the platform, and no amount of money or urgency moves it.

Here is what actually governs the timeline, roughly in order of how much it matters.

Concurrency, not throughput

The instinct is to think about total volume: five terabytes of mail, so many days at so many gigabytes an hour. That is the wrong model.

Migration runs mailbox by mailbox, and only a limited number move at once. In our projects that ceiling sits at around twenty concurrent mailbox moves. Everything else queues behind them.

So the arithmetic that matters is not volume ÷ bandwidth. It is:

total mailboxes ÷ concurrent moves × average time per mailbox

With a thousand users that is fifty passes through the queue. If an average mailbox takes six hours, you are looking at roughly twelve days of continuous running before anything goes wrong — and something always does. Doubling your budget does not raise the concurrency ceiling.

The distribution of mailbox sizes, not the average

Averages hide the problem. A thousand mailboxes averaging 8 GB sounds manageable. But if four of those users are on 2 TB personal archives, those four will still be running long after the other nine hundred and ninety-six have finished.

This is not hypothetical. On one consolidation for a group in the UAE and Singapore, several users held archives of about 2 TB each. Those mailboxes took over six months on their own, running quietly in the background while the rest of the project completed around them.

Nobody had done anything wrong. The archives had accumulated over a decade, and moving them was simply going to take that long. The mistake would have been promising a date without looking at the size distribution first.

Before quoting any migration, ask for the mailbox size report. Not the total — the list, sorted descending. The top ten rows tell you more about the schedule than the headcount does.

Throttling, which is invisible until it is not

Microsoft throttles migration traffic to protect the service for everyone else on it. You will not get an error; things will simply run slower than the same job ran last week. Throughput varies by time of day and by how busy the region is.

You cannot negotiate this away, and you should be suspicious of any partner who implies otherwise. What you can do is plan around it: run the heavy passes outside business hours in the source region, and build the schedule with slack rather than to the optimistic number.

SharePoint and OneDrive are a different problem

Mail is many small items in a queue. SharePoint is a permissions model — and if you are coming from Google Drive, the two models do not agree.

The volume moves reasonably well. What takes time is deciding what the target structure should be, and resolving what does not map. Sharing that was set up ad hoc over years — personal permissions on individual folders, links shared outside the organisation, sites nobody owns any more — has to be untangled before anything is copied, or you replicate the mess into a clean tenant.

On our largest project this was 20 TB of SharePoint alongside the mail. The copying was not the hard part.

Identity, which decides the last day rather than the duration

Directory synchronisation does not affect how long the data takes to move, but it does determine how risky the final step is. A tenant syncing from an on-premises Active Directory is a different cutover from a cloud-only one, and two tenants syncing from two separate directories is different again.

Conditional Access policies do not migrate. They have to be rebuilt in the target tenant. If nobody mentions they exist, users find out on the Monday after cutover, when they cannot sign in.

What we tell clients at kick-off

These are not padded. For a first number against your own headcount and data, the cost calculator uses the same arithmetic. They assume the estate is roughly normal, the client can make decisions in reasonable time, and nothing exotic turns up in the audit. Every one of those assumptions has been wrong at least once.

What you can compress, and what you cannot

You can decide what does not move. This is the single biggest lever, and it is entirely in the client’s hands. Months of migration time have gone into archived mail nobody had opened in years. Agreeing what can be archived elsewhere or left behind under a retention policy is an uncomfortable conversation at kick-off and a far worse one in month five.

You can start the slow things first. The 2 TB archives should begin on day one, in the background, while the planning for everything else is still going on. They finish when they finish; the only question is whether they started early enough.

You can prepare the target properly. Our kick-off checklist is the list of what that means in practice. Time spent building users, groups and site structure before anything moves is time not spent fixing it afterwards. This is the stage where the project is won or lost.

You cannot buy concurrency. No commercial arrangement raises the ceiling.

You cannot shorten a 2 TB archive. You can decide not to move it, which is a different conversation and often the right one.

The question to ask a partner

If a partner gives you a date before seeing your mailbox size report, tenant count and identity configuration, they are guessing. The other questions worth asking are in the buyer’s guide. That guess will be optimistic, because optimistic guesses win work.

The more useful question is not “how long will this take” but “what would make this take twice as long, and how would we know early?” A partner who has run these projects will have a short, specific list. A partner who has not will tell you it will be fine.