Healthcare · Australia · ~500 users · 3-month project, delivered 2017
Seventeen tenants into one
Delivered by our European team, with support from our US engineers
A group of clinics had accumulated one Microsoft 365 tenant per practice over several years — each set up by whoever happened to be handling IT at that site, none of them talking to the others.
This was our first large consolidation and we did far too much of it by hand. We renamed users one at a time. We set mail addresses one at a time. With five hundred users and a great many duplicated accounts across seventeen source tenants, that is weeks of work which should have taken hours.
What went wrong
Nothing broke. It was simply far slower than it needed to be, because we had no automation and did not yet know we needed any.
What we changed afterwards
We rebuilt the entire process around PowerShell afterwards. Bulk renaming, address assignment and account mapping are now scripted and repeatable — which is why the thousand-user consolidation below moved faster at twice the size.
17 tenants retired · duplicate per-user licensing eliminated
Group of companies · UAE and Singapore · ~1,000 users · two engagements, six months each
Eight tenants into three, then a carve-out
Delivered by our European team
Growth by acquisition had left the group with eight separate Microsoft 365 tenants. We consolidated them into three.
Eighteen months later they came back with the opposite problem: one company was being divested and needed its own tenant, while two further acquisitions had to be folded into the main one. The same project, run in both directions — which is why we treat divestiture as the same discipline rather than a separate service.
Eight tenants meant many people existed two or three times over, with different usernames and different mail addresses. We mapped them and merged what could be merged. More than half were deliberately left separate, because merging identities belonging to genuinely different roles creates more problems than it solves.
What went wrong
Two hard constraints, neither of them avoidable. Microsoft caps concurrent mailbox migrations at twenty — with a thousand users that alone sets the floor on the schedule. And several users held personal archives of around 2 TB each, which took over six months to move on their own, running in the background while everything else completed around them.
What we changed afterwards
Push harder at the start on migrating only what is actually needed. Months of migration time went into archived mail nobody had opened in years. That is an uncomfortable conversation at kick-off and a far worse one at month five.
8 tenants into 3 · one clean carve-out · duplicate licences removed across the group
Industrial engineering and EPC · Europe · 3,000 users · six months
Three thousand users, and one dead migration host
Delivered by our European team, with input from our US engineers on the on-premises server
A European engineering, procurement and construction contractor was relocating the business to another country, and the entire Microsoft 365 estate had to move with it — around 4 TB of Exchange data and 20 TB of SharePoint, with no downtime.
The approach was the one we use every time: prepare the target tenant and build out users, groups and sites first; migrate data into those prepared containers while people keep working in the source tenant; move domains and addresses in a weekend window; repoint Entra Connect last.
What went wrong
The virtual machine running the mailbox migration died mid-project. We rebuilt it and re-ran the migration, and some mailboxes came back with duplicated mail — because by that point the cutover had already happened and users were live in their new accounts.
The fix was blunt: delete everything older than a fixed date and migrate it again. It worked because Microsoft still allowed bulk mailbox cleanup at 10,000 objects per pass at the time. That option no longer exists, which is worth knowing if you are planning a migration today. The same mistake would now be considerably more expensive to unwind.
Separately, the file migration tool we were using was discontinued by its vendor during the project. We finished moving the remaining data with days to spare.
What we changed afterwards
Size the migration host at roughly 120% of total mailbox volume. It was a capacity problem, not a tooling problem, and it is entirely avoidable.
No downtime, either time · 4 TB Exchange, 20 TB SharePoint · client returned for a second engagement at 1,300 users
Industrial machinery manufacturing · Canada · 25 users · two to three months
Microsoft 365, Intune and Azure in one engagement
Microsoft 365 by our European team; Azure by our US engineers
A small client, but a full-stack move: Microsoft 365 with 200 GB of Exchange and 1.5 TB of OneDrive, Intune for device management, and the Azure infrastructure behind it. We also built a secure baseline for all twenty-five users — device and access policy — in about two weeks.
What went wrong
Everything was migrated, the client went live, and then nobody could log into the virtual machines. RDP access rights had not been carried across.
The engineer who had done that part was by then on a hiking trip with connectivity roughly once a day, at whatever stop had signal. Rather than wait, we reconfigured access on almost every machine directly.
What we changed afterwards
Access rights are now part of the cutover checklist rather than something assumed to have come along with the workload. Nothing about that failure was technically difficult — it was a handover gap, and handover gaps are the ones that surface after the client is already live.
Full estate moved · Microsoft 365, Intune and Azure in a single engagement
Film and media · ~300 users · several TB of SharePoint · two months
A tenant built on the wrong domain
Tenant created by our US location; migration and remediation by our European team
The client was relocating operations to the United States and moving their Microsoft 365 tenant with them.
What went wrong
The tenant had been registered against the wrong domain. Nobody caught it until the migration was complete.
Changing a tenant’s technical domain after the fact is possible, but everything already migrated had been configured against the original name — so links to migrated SharePoint sites broke and had to be reworked.
What we changed afterwards
Verify tenant identity before a single item is migrated, regardless of who set the tenant up. Two minutes of checking at the start against a week of repair at the end. We publish this one because it is the kind of mistake that gets quietly buried, and it is the most useful thing on this page for anyone about to start.
Migration completed · domain corrected · site links rebuilt
Engineering · United Kingdom · long-running client
Licences for years, then a project
Licensing through our EU entity; project delivered by our US engineers
A UK engineering firm bought Microsoft licences through us for several years — a straightforward supply relationship, invoiced in sterling from our EU entity.
When they eventually needed serious project work, they did not run a procurement exercise. They asked us, because we already knew the estate and they already knew who would pick up the phone. The project ran to roughly $35,000.
What went wrong
Nothing. It is on this page because it shows the shape of most of our long-term accounts rather than because it was difficult.
What we changed afterwards
Licensing is the door; engineering is the reason people stay. A client who has been invoiced by you for three years does not put a migration out to tender.
Multi-year licensing relationship · project awarded without tender