Microsoft 365 migrations have a reputation problem built on survivor stories: the weekend cutover that ran into Tuesday, the vanished calendar invites, the shared mailbox nobody mentioned until it mattered. The reputation is unearned in one specific sense: migrations go wrong in the same half-dozen ways every time, all of them known, all of them preventable with sequencing. A properly planned SME migration is an anticlimax, and this page is the sequencing that makes it one.
It covers the move from wherever you are (old email hosting, an exchange server in the cupboard, a rival cloud suite, or the classic tangle of POP mailboxes and a file server) to Microsoft 365, phase by phase, with the snag list DIY migrations discover the hard way.
Before anything moves: the audit
Every clean migration starts with an honest inventory, because the surprises live in the things nobody wrote down:
- Mailboxes, including the shared ones, the aliases, the info@ addresses forwarding somewhere forgotten, and the departed-staff mailboxes still quietly receiving.
- Where email actually lives now: hosting provider, old server, or (the finding that changes timelines) years of PST archives on individual machines.
- Files and their permissions: what is on the server or old cloud, who can see what, and how much is duplicate and debris that should not make the trip (per the SharePoint move guide, a large fraction usually is).
- The dependents: scanners that email, applications that send invoices, website contact forms, anything with SMTP settings pointing at the old world. These are the migration’s quiet analogue-lines equivalent: invisible until they stop.
- Domain access: who controls the DNS. If the answer involves a departed web designer, resolving it is step zero, and the ownership doctrine applies in full.
The phases, in the order that avoids the stories
1. Build the destination properly
Tenancy created, licences chosen per role (the plan comparison decides tiers), users and groups structured, and, crucially, security configured before data arrives: MFA enforced from day one, hardening baseline applied. Migrating first and securing later is choosing to run the risky window with all your data inside it.
2. Pre-stage the mail
Modern migration tooling syncs mailbox content to the new tenancy in the background over days while everyone keeps working on the old system: mail, folders, calendars, contacts. By cutover day, 99% of the data is already across, which is the trick that shrinks “the weekend” to an evening.
3. Cut over the mail flow
DNS records switch, new mail starts arriving in Microsoft 365, a final sync catches the stragglers, and Outlook profiles reconnect (largely automatic with current tooling). Done mid-week in the evening, not Friday: if anything needs attention, you want a staffed morning after, not a weekend of voicemail. Expected staff-visible downtime in a well-run cutover: minutes to zero, plus a re-authentication.
4. Move the files, deliberately
Files follow mail, not simultaneously (one change at a time keeps every problem diagnosable): structure designed, debris left behind, staged copy, sync clients configured. The full logic lives in the file-server-to-SharePoint guide; the sequencing point here is simply that it is phase four, not phase one.
5. Repoint the dependents and land the people
Every scanner, application and form from the audit gets its settings updated; M365 backup switches on (the platform does not back itself up); old services run read-only for a grace period, then retire, ending their bills. And staff get the twenty minutes of orientation that determines whether the new tools get used or resented: where things went, how sharing works now, who to ask. Communication is a phase, not a memo.
The snag list, so you can check your plan against it
The recurring causes of migration stories, all audit-preventable: the forgotten shared mailbox (surfaces Monday morning as “where are the orders?”); PST hoards on desktops that were never on any server; DNS delays from high TTLs nobody lowered in advance, stretching cutover; legacy protocols (an old app speaking unauthenticated SMTP that modern security rightly refuses); permission surprises where the old world’s loose access becomes visible in the new one’s honest reporting; and the licence mismatch discovered when someone needs a desktop app their tier lacks. None is serious with a day’s notice; each is a bad afternoon without.
Timeline and cost shape
A typical 10-to-50-user SME migration runs two to four weeks end to end, most of it background syncing and coordination rather than disruption, with one evening cutover at the centre. Cost is a fixed project fee (scoped from the audit, since mailbox count and file volume drive effort) plus the ongoing licences; for businesses moving onto our managed support, migration is commonly folded into onboarding. The saving on the other side of the ledger: the old hosting, the old server’s refresh liability, and the Friday-night backup ritual, all retired.
Frequently asked questions
How long does a Microsoft 365 migration take?
Two to four weeks for a typical SME, dominated by background mail syncing and planning; the staff-visible cutover is an evening, with minutes of disruption when pre-staged properly.
Will we lose emails during migration?
Not in a pre-staged migration: content syncs across before cutover and a final pass catches in-flight items. The loss stories come from cutover-first approaches and forgotten PST archives, both of which the audit eliminates.
Can we keep our email addresses?
Yes, identically: your domain moves its mail routing to Microsoft 365 and every address carries over. Callers and correspondents notice nothing.
Should we migrate email and files at the same time?
No: mail first, files second, one change at a time. Simultaneous moves compound every problem’s diagnosis; sequenced moves keep each phase boring, which is the goal.
Do we need to buy anything besides the licences?
Migration tooling (bundled in a provider-run project), and third-party backup for the new tenancy, which is standard practice rather than optional. Hardware needs are usually nil; ageing machines are a separate conversation the audit will flag honestly.
Can we do the migration ourselves?
Small, simple estates: feasibly, with care and this page’s snag list. The cases that justify a provider are the same ones that punish DIY: shared mailboxes, servers, compliance needs, and any business where a bad email day costs real money. The audit is where that judgement gets made with numbers.
Start with the audit, not the date
The migration date everyone wants to discuss first is actually the last decision; the audit is the first. Ours comes inside the free IT health check: your mailboxes, files, dependents and domain control mapped, the snags found while they are cheap, and a fixed quote with the timeline attached. Get in touch and we will make your migration the anticlimax it should be.
