A Microsoft 365 migration playbook
Mailboxes are the easy part. What extends a migration is everything that quietly authenticates against the old environment and nobody wrote down.
A Microsoft 365 migration for a hundred users with straightforward mailboxes takes a few weeks including a pilot. Shared mailboxes, public folders, on-premises applications that authenticate against the old directory and untouched archives are what extend it.
Migrate in waves, never all at once, and put at least one difficult user in the pilot. A pilot of willing volunteers proves nothing.
Two things people forget: Microsoft 365 is not backed up for you, and the old environment has to stay reachable until the last dependency is confirmed dead.
Start with an inventory, not a plan
Every migration that goes badly went badly because something was discovered halfway. The inventory is the cheapest insurance available, and it takes days rather than weeks.
What we list: mailbox sizes and count, shared mailboxes and who actually uses them, distribution lists, public folders, calendar delegations, mobile devices, every application that signs in against the current directory, every device that scans to email, and every automated process that sends mail. That last category is where the surprises live: the invoicing system, the alarm panel, the multifunctional in the hallway.
Migrate in waves
| Wave | Who | Purpose |
|---|---|---|
| Pilot | Five to ten users, including at least two difficult ones | Find the problems while they are cheap |
| Wave one | One department that is not customer-facing | Prove the process at scale without exposure |
| Waves two and up | Departments, largest last | Steady rhythm, one rollback path per wave |
| Stragglers | Executives, shared devices, anything unusual | Hand-held, individually scheduled |
Do not migrate the management team first. They are the least tolerant of a problem and the most visible when one occurs.
Put a difficult user in the pilot
The instinct is to pilot with people who are enthusiastic about technology. They will report that everything went well, because they work around problems without noticing. The person you want is the one with fourteen years of mail, six delegated calendars and a mobile device nobody has updated since 2023.
If that migration is clean, the rest will be. If it is not, you have found the issue in week one rather than in wave four.
What always takes longer than planned
- Archives. Personal folders on network drives that nobody has opened in years but everyone refuses to lose.
- Shared mailboxes. Permissions accumulated over a decade, half of them for people who left.
- Public folders. Almost always more used than anyone admits at the start.
- Devices that scan to email. Multifunctionals with a hardcoded SMTP setting and a password nobody has.
- Applications with their own directory connection. Line-of-business software, a Citrix environment, an old intranet.
Identity is the migration, everything else is data
The mailbox move is mechanical. The part that changes how the organisation works is identity: single sign-on, multi-factor authentication and conditional access. Get that right and the rest follows; get it wrong and every application becomes a separate complaint.
We set multi-factor authentication up before the migration rather than after, because doing it afterwards means asking people to change twice. Where an estate uses Okta alongside Microsoft Entra, we agree which one is authoritative before the first wave.
Back it up from day one
Microsoft guarantees the availability of the service, not the recoverability of your content once a retention window passes. A deleted mailbox, a purged SharePoint site or a tidied Teams channel is recoverable for a limited period and then it is not.
We put a separate backup in place as part of the migration, not as a later project. The reasoning is set out under data and business continuity.
The two weeks after
A migration is not finished when the last mailbox moves. Keep the old environment reachable, watch mail flow for anything still routing the old way, and expect a wave of small questions in the first fortnight that has nothing to do with the migration and everything to do with people noticing a changed interface.
Staffing the desk properly for those two weeks is what decides whether people remember the migration as smooth. What we take on is described under cloud services.
Questions we get about this
What comes up before every migration.
How long does a Microsoft 365 migration take?
For a hundred users with straightforward mailboxes, a few weeks including a pilot. Shared mailboxes, public folders, on-premises applications that authenticate against the old directory and large archives extend it. We inventory those before quoting a timeline rather than after.
Will users lose email during the migration?
No. Mail continues to be delivered throughout; what changes is where the mailbox lives. The visible effect for most users is a restart of the mail client and a re-login on their phone.
Do we still need a backup after moving to Microsoft 365?
Yes. Microsoft protects the availability of the platform and offers limited retention for deleted items, but once that window passes the content is gone. A separate backup is standard in every migration we run.
Can we migrate department by department?
Yes, and we recommend it. Waves keep the rollback small and let the desk absorb questions at a manageable rate. Migrating everyone in one weekend concentrates every problem into the same Monday morning.
Where this lands in our work
Where a migration lands.
Want this looked at for your own sites?
Half an hour on a call is usually enough to tell you whether we are the right party for it, and we will say so if we are not.