Microsoft 365 Migration Checklist
The sequence we actually work from: four weeks out, one week out, cutover night, and the first week after.
Published in full rather than gated behind a form. If you have competent internal IT, this is most of what you need — and we would rather you run a good migration yourself than a bad one with us.
If you read one line of this page: lower the DNS TTL on your MX records several days before cutover. It takes two minutes, costs nothing, and shrinks the window where mail can split between two systems from most of a day to under an hour. More rough migrations trace back to skipping it than to any other item here.
Four weeks out
Decisions and discovery. Nothing is built yet, and everything that is expensive to change later is settled here.
- check_circle
Confirm the destination — plan mix per person, not one plan for everybody
- check_circle
Inventory every mailbox, including shared and role addresses nobody owns
- check_circle
Record the size of the largest mailboxes; these set your timeline
- check_circle
Locate PST archives on laptops — start this now, it always takes longer than expected
- check_circle
Confirm who controls your DNS, and that someone can actually make changes
- check_circle
List every system that sends mail as your domain: invoicing, CRM, website forms, marketing tools
- check_circle
Decide the naming convention and whether the old domain stays live
- check_circle
Decide what happens to a leaver's mailbox, and write it down
- check_circle
Agree the cutover window with the business, not just with IT
One week out
Everything is staged and verified. If something is wrong, this is when you want to find it.
- check_circle
Lower the DNS TTL on your MX records — the single highest-value item on this list
- check_circle
Complete the first full data copy and verify message counts against the source
- check_circle
Confirm SPF, DKIM and DMARC records are prepared for the new sending source
- check_circle
Create shared mailboxes as shared mailboxes, not as licensed user accounts
- check_circle
Rebuild distribution lists and verify membership with the people who own them
- check_circle
Test send and receive on a pilot mailbox, externally in both directions
- check_circle
Write the note to staff: what changes, when, and what they must do on their phone
- check_circle
Confirm rollback: the old system stays live and authoritative until you say otherwise
Cutover night
The only genuinely time-sensitive step. Short, watched, and reversible until the last moment.
- check_circle
Final delta sync from the source
- check_circle
Switch MX records to Microsoft 365
- check_circle
Publish the new SPF record and enable DKIM signing
- check_circle
Send test mail in both directions from outside the organisation
- check_circle
Reconfigure the mail settings on any invoicing, CRM or website system that sends as your domain
- check_circle
Confirm shared mailboxes are receiving
- check_circle
Leave the old system running and receiving — do not decommission anything tonight
The first week
Where the real questions arrive. Budget attention for it rather than declaring victory on Monday.
- check_circle
Run a second delta sync to catch anything delivered late to the old system
- check_circle
Walk the floor, or the equivalent — most problems are not reported, they are worked around
- check_circle
Help people reconnect phones and tablets; expect this to be most of the volume
- check_circle
Rebuild the complex server-side rules that did not migrate
- check_circle
Check DMARC reports for legitimate systems now failing authentication
- check_circle
Confirm nobody is still working in the old system out of habit
- check_circle
Reclaim licences from the source platform once you are genuinely done
What actually goes wrong
Across the migrations we are called in to rescue, these four account for most of it. None are technical failures.
DNS TTL left at the default
The most common single cause of a bad cutover. A default TTL can leave mail splitting between two systems for most of a day. Lower it several days ahead and the ambiguous window shrinks to under an hour.
The invoicing system nobody mentioned
Accounting software, CRM and website contact forms that send as your domain will keep using the old settings and will start failing authentication. They are never on the first inventory and always on the second.
Decommissioning too early
Keep the old system live and readable for an agreed period. Cancelling the old hosting the same weekend saves one month of fees and occasionally costs a great deal more.
Telling people too late
A migration that is technically flawless still feels like an outage if nobody was warned. One short note a week ahead and one on the day removes most of the support volume.
Using this checklist — common questions
helpCan we use this checklist ourselves?
expand_more
Yes — that is why it is published rather than gated behind a form. It is the sequence we actually work from. If you have competent internal IT, this is genuinely most of what you need. Where people usually want help is the verification step and the cutover night itself, because those are the parts that are hard to undo.
helpWhat is the single most important item on the list?
expand_more
Lowering the DNS TTL on your MX records several days before cutover. It costs nothing, takes two minutes, and is the difference between an ambiguous window of under an hour and one lasting most of a day. More rough cutovers trace back to this than to anything else on the list.
helpHow far ahead should we start planning?
expand_more
Four weeks is comfortable for a typical business of 10 to 50 users. It can be compressed, and the things that suffer when it is are the discovery items — finding PST archives, and identifying every system that sends mail as your domain. Those two are slow because they depend on other people remembering things.
helpDo we need to tell staff, and when?
expand_more
Yes, twice. One note about a week ahead saying what is changing and when, and one on the day with the specific instructions for reconnecting a phone. Migrations that go perfectly on the technical side still generate complaints when the first anyone hears of it is their mail not working.
helpWhat if something goes wrong on cutover night?
expand_more
Until MX records change, nothing has happened that cannot be abandoned — the old system is still live and authoritative. After the change, reverting DNS restores the previous routing, which is precisely why the old system is kept running rather than decommissioned. Having that fallback is the reason the sequence is ordered this way.
helpDoes this checklist cover files as well as email?
expand_more
It is weighted towards mail, because mail is the time-critical part and the part everybody notices. File migration into SharePoint and OneDrive runs on a longer timeline and is less dependent on a single cutover moment. Our migration page covers the file side and how the two are sequenced together.
Related pages
Microsoft 365 Migration
The full service: mail and files, methods and cutover planning.
Email Migration to Microsoft 365
Migration methods by source, and what each one carries.
Google Workspace to Microsoft 365
The source-specific version, where file mapping is the real work.
Microsoft 365 Business Email
How mailboxes and shared addresses should be structured on arrival.
Microsoft 365 Implementation
Tenant, identity and security baseline — the work around the data.
Microsoft 365 Services
Licensing, implementation, migration, security and support in one place.
Google Workspace Migration Checklist
The equivalent list for a move to Google.
Have us run it
Or use the list yourself — both are fine.
Or have us run the migration
The checklist is yours either way. If you would rather not spend a weekend watching DNS propagate, tell us what you are moving from and how many mailboxes.
- check_circle
Data verified against the source before any switchover
- check_circle
Cutover night watched, not started and left
- check_circle
The first week's questions treated as part of the job
If a server room is involved, add one item to this list — everything that sends email through the old server; our page for Microsoft 365 partner in Ernakulam explains why.
Prefer to talk first? Call +91 99467 89916 or email admin@techgeum.com.