Postmortem
A relocation, 24 TB, no downtime allowed — and a failed virtual machine that put duplicate mail in live mailboxes. What broke, how it was fixed, and why the same fix would not work today.
By Alex Makey · 3 September 2026 · 7 min read
Most case studies are written by the marketing department. This one is a postmortem, published because the useful part is what broke rather than what worked.
A European engineering, procurement and construction contractor was relocating the business to another country. The entire Microsoft 365 estate had to move with it: about 3,000 users, roughly 4 TB of Exchange data and 20 TB of SharePoint. The requirement was no downtime, which for a firm running construction projects across several time zones was not negotiable.
It took six months. It worked. And in the middle of it, the migration host died.
The sequence we use every time, and the reason it survived what happened next:
One: prepare the target tenant. Build users, groups and site structure in the destination before anything moves. Map identities. Decide explicitly which duplicated accounts merge and which stay separate. This stage produces nothing visible and determines everything.
Two: move the data in the background. Mailboxes, archives, OneDrive, SharePoint and Teams migrate into containers that already exist, while people keep working in the source tenant. Nobody notices.
Three: cut over domains and addresses. A weekend window. This is the only part users experience.
Four: switch identity across. Entra Connect is repointed last, once everything else is verified, followed by a delta pass for anything that arrived during cutover.
The virtual machine running the mailbox migration died mid-project. Not gracefully — it stopped, and it did not come back.
We rebuilt it and re-ran the migration. That is where the real problem started. By that point the cutover had already happened for a portion of the estate, and those users were live in their new mailboxes, sending and receiving. Re-running the migration pushed the source mail into mailboxes that already had it. Users opened Outlook to find every message twice.
For a business coordinating construction sites by email, that is not a cosmetic issue.
The clean-up was blunt: identify everything that arrived before a fixed cut-off date and remove it in bulk, then migrate again cleanly. At the time, Microsoft allowed bulk mailbox operations at 10,000 objects per pass, which made this feasible across several thousand mailboxes.
That option no longer exists at the same scale. If you are planning a migration today and thinking of it as your safety net, it is not there. The same mistake would now be considerably more expensive to unwind, and in some cases would mean restoring from backup rather than cleaning in place.
This is the single most useful sentence in this article, and it is the reason we published it.
Partway through, the vendor of the file migration tool we were using discontinued the product. Mid-project. With terabytes still to move.
We finished the remaining data with days to spare before it stopped working. That was luck rather than planning, and it changed how we choose tooling: we now check the vendor’s roadmap and support commitments before a long project, not just the feature list. A tool that is perfect and abandoned is worse than one that is adequate and maintained.
The migration host failed because it ran out of capacity under sustained load. It was sized for the job on paper and not for the job in reality, with retries, logs and staged content all competing for the same disk.
We now size migration hosts at roughly 120% of total mailbox volume. It is not elegant and it costs a little more in compute. It is also the cheapest insurance in this kind of project, and it was entirely avoidable the first time.
Freeze the source mailbox before re-running anything. The duplication happened because a mailbox was live in two places while a migration pass was running. Any re-run after cutover should start by cutting mail flow to the source, not by starting the copy.
Stage the cutover more finely. Cutting over in larger groups meant more users exposed when the host failed. Smaller waves would have contained the blast radius, at the cost of a longer schedule — a trade we would now make.
Say the word “duplicate” out loud at kick-off. The client understood the technical explanation afterwards. They would have understood it better before.
The client came back later to fold a smaller company of their own into the same tenant, at 1,300 users. That second project ran without incident, which is the only endorsement in this article that means anything.
Every migration of any size hits something unplanned. A partner who shows you six flawless projects is either very new or editing heavily — it is the third question we suggest asking before you sign. What you should be asking is not whether things go wrong, but whether the person telling you about it knows why, and what they changed afterwards.
One email a month, at most
Postmortems, timelines, licensing changes that cost people money. No newsletter cadence, no digest of other people’s news. If a month has nothing worth your time, you hear nothing.
Please enter a work email address.
Done. Unsubscribe by replying to any email; we will not argue.
Related questions
Data already migrated is in the target tenant and safe. The risk is re-running a pass for mailboxes that are already live in the destination, which duplicates mail. Cut mail flow to the source before any re-run.
At roughly 120% of total mailbox volume. Sizing to the data volume alone ignores retries, logs and staged content competing for the same disk under sustained load.
It is far harder than it used to be. Microsoft previously allowed bulk mailbox operations at 10,000 objects per pass, which made large-scale clean-up feasible. That is no longer available at the same scale, so prevention matters more than it did.
Yes. Data moves in the background while people keep working in the source tenant, and domains and addresses cut over in a weekend window. This project moved about 3,000 users and 24 TB with no planned downtime.
The vendor’s roadmap and support commitments, not only the feature list. On this project the file migration tool was discontinued by its vendor mid-project.
Working on one of these?
How many tenants, roughly how many users, and what is forcing the timing. You get back a sequence, an honest view of what will be slow, and a fixed price — usually within one business day.