When people picture moving from on-premise servers to Microsoft 365, they picture a weekend. Everyone goes home on Friday using the old server; everyone comes back on Monday in the cloud; something, inevitably, is on fire.
That’s the wrong mental model, and it’s the one that causes the disasters. A good migration isn’t a single switch-over. It’s a sequence of small, reversible steps, each of which you can stop and undo if it misbehaves. Done that way, most of your people barely notice it happened. Here’s what the sequence actually looks like, week by week, for a typical small-business move.
Before week one: the part people skip.
The migrations that go wrong almost always skipped discovery. You cannot safely move what you haven’t catalogued. So before anything touches the cloud, we build a real picture:
- Every mailbox, its size, and any shared or resource mailboxes hiding in the mix.
- Every file share — and, crucially, how big it really is and who actually opens it. Half a terabyte of files nobody’s touched since 2019 doesn’t need to migrate at speed; it needs archiving.
- The line-of-business apps that talk to email or files. The practice management system that sends statements. The scanner that drops PDFs to a folder. These are where surprises live.
- Who works how — who’s remote, who’s on a desktop that never moves, who has a 90,000-item mailbox that’ll take days to sync.
Out of that comes the plan. No two are identical, but the shape below holds for most firms of 20–80 people.
Week one — foundations.
Nothing visible to users happens yet, which is exactly right. We set up the Microsoft 365 tenant properly: licensing, the security baseline (MFA, conditional access, the things we’d argue you should have had years ago), and the admin structure. We verify your domain and get the DNS groundwork ready without yet redirecting live mail.
This is also when we set up the security posture from day one rather than bolting it on later — see our Microsoft 365 and cloud approach for what that baseline includes. Migrating into a badly-configured tenant just means doing the hard work twice.
Week two — the pilot.
We move a small, friendly pilot group first — usually IT-comfortable people and one or two patient volunteers from each team. Their mail, their files, their day-to-day. Then we leave them on it for several days and listen.
The pilot is where you find the thing the discovery missed: the mail-merge that breaks, the desktop scanner that needs reconfiguring, the one add-in nobody mentioned. Far better to find it with five forgiving colleagues than with the whole firm on cutover morning. If something’s badly wrong, the pilot is still small enough to roll back cleanly.
Weeks three to four — mailboxes, in waves.
With the pilot’s lessons folded in, we migrate the rest of the mailboxes in batches — by team, or by floor, whatever keeps disruption contained. The mail copies up to Microsoft 365 in the background, ahead of time, so by the time we flip a user over, their history is already there waiting.
The actual cutover for each person is small: their mail flow redirects, Outlook reconnects to the cloud, and they carry on. We schedule the redirect for quiet hours and keep the old system running in parallel, so there’s always a path back if a batch misbehaves.
Week four to five — files and SharePoint.
Files are where the “just copy it all up” instinct does real damage. Dump a tangled on-prem share straight into SharePoint and you inherit every bad habit — the 14-folders-deep nesting, the FINAL_v3_actualfinal documents, the permissions nobody understands — except now it’s slower to navigate and harder to fix.
So we treat this as a tidy-up, not a transplant. Agree a sensible structure, decide what’s active (migrate), what’s reference (archive to cheaper storage), and what’s genuinely dead (leave behind). The bulk copies up quietly in the background; the final sync of recent changes happens at cutover so nothing’s lost.
Cutover — the quiet weekend.
By now the “big weekend” everyone feared is an anticlimax, which is the goal. The data is already in the cloud. Cutover is mostly flipping the last mail routing, doing a final delta sync of files changed that week, and pointing the line-of-business apps at their new home. We do it out of hours, with a tested rollback for each piece, and we’re on hand first thing Monday.
The measure of a good cutover is that the Monday-morning support queue is boring: a few password prompts, someone who needs their signature re-added, the usual. Not a queue full of “I can’t get my email.”
The week after — decommission, deliberately.
Here’s the discipline that separates a finished migration from a half-done one: don’t switch the old server off on Monday. Leave it running, but read-only, for two to four weeks. It’s your safety net — the place you go if someone says “where’s the file from March?” and it didn’t come across.
Once that window passes with no surprises, then you decommission properly: securely wipe the old kit, cancel the things you were quietly still paying for, and update your documentation to reflect reality. Skipping this step is how firms end up paying for a server room they no longer use and an internet line sized for a building that’s now half-empty.
A migration you can feel is a migration that went wrong. The good ones are almost boring from the user’s chair — their email still works, their files are where they expect, and the only difference they notice is that things stopped breaking.
Where the real risks sit.
If you take one thing from this: the risk in an M365 migration is almost never the technology. Microsoft’s tooling for this is mature and well-trodden. The risk is in the things around it —
- the app nobody mentioned until cutover;
- the mailbox that’s too big to sync in the window you planned;
- the files migrated so badly that people can’t find anything and quietly start emailing documents to themselves again;
- and switching the old system off before you’re sure.
All four are killed by the same thing: proper discovery up front and a sequence that’s reversible at every step. That’s the whole method. Everything else is detail.
