Microsoft 365 migration checklist for UK firms

Moving a business to Microsoft 365 is usually less about technology than about order of work. The tools exist and the steps are well understood, but projects run into trouble when something is missed: a shared mailbox nobody mentioned, an old scanner that sends email, or a domain record changed too early. This checklist covers a migration from on-premises Exchange, from Google Workspace or between Microsoft 365 tenants, in the order most projects need it. Microsoft changes its tools and guidance, so confirm each step against Microsoft’s current documentation, linked below.

Which kind of migration is it?

The method depends on where you are coming from.

• From on-premises Exchange. Smaller organisations often use a cutover or staged migration, while larger ones run a hybrid setup so mailboxes can move in batches. Microsoft’s mailbox migration overview compares the methods. Note that Exchange Server 2016 and 2019 reached the end of Microsoft support in October 2025, so staying put is itself a risk worth weighing.
• From Google Workspace. Mail, calendars, contacts and files move to different Microsoft 365 services, and file sharing links will not carry across, so plan for that. See Microsoft’s Google Workspace migration guide.
• Between Microsoft 365 tenants. Common after a merger or a rebrand. It is the most demanding type, because two identities, two sets of policies and often a shared domain have to be reconciled. Microsoft documents cross-tenant mailbox migration separately.

Choose the method after the inventory, not before.

Before you move anything

1. Take an inventory. Users, shared mailboxes, room and equipment mailboxes, distribution lists, mailbox sizes, archives, public folders and any applications or devices that send or receive email.
2. Decide what to leave behind. Old mail, dormant accounts and unused groups cost time and licences to move. Agree retention rules with the people who own the data.
3. Check your licences. Work out which plan each person needs before you assign anything. Our guide to Microsoft 365 plans explains the differences.
4. Set a realistic timetable. Mailbox volume, internet bandwidth and the number of devices all affect how long it takes. Build in time for testing.
5. Name an owner. Someone needs to decide when a problem is serious enough to pause.

Identity and domains

6. Plan identity. Decide whether accounts will be created in the cloud or synchronised from an existing directory, and how people will sign in.
7. Check the domain. Confirm who controls your domain name and its records. You will change several, including MX, autodiscover, SPF, DKIM and DMARC, and the order matters.
8. Avoid changing mail flow too early. Lower the time-to-live on records ahead of the cutover so changes take effect quickly, and leave the final switch for the agreed moment.
9. Prepare for legacy systems. Scanners, line-of-business applications and printers often send email using older settings. Find them now, because they are easy to forget and hard to diagnose later.

Security baseline first

Do not move people into a tenant that is not ready for them. Before cutover:

10. Turn on multi-factor authentication for administrators and plan it for everyone. Microsoft’s baseline settings, called security defaults, are a reasonable start if you have not set your own policies.
11. Set up email protection. Check SPF, DKIM and DMARC, and apply the anti-phishing and safe links settings your licence allows.
12. Protect administrator accounts, with separate admin accounts and a small number of emergency accounts set up following Microsoft’s current emergency access guidance.

Our guide to ten Microsoft 365 security controls to set first gives the full order of work.

The move itself

13. Pilot first. Move a small, friendly group and ask what broke. Pilots find the surprises while they are cheap to fix.
14. Migrate in batches. Group people by team or by mailbox size, and avoid migrating a department the week it closes its books.
15. Move files separately. Documents and shared drives go to SharePoint and OneDrive, and they need their own plan for structure, permissions and naming.
16. Handle devices and Outlook profiles. Decide how each device reconnects. Mobile phones, shared computers and older Outlook versions are the usual sources of support calls.
17. Keep a way back. Know what you will do if a batch fails, and keep the source system available until you are confident.

People and communication

A migration succeeds or fails on whether staff know what is happening. Tell them what will change and when, what they need to do (such as setting up multi-factor authentication), who to contact, and what to expect on the first morning. A short, plain message a week ahead and a reminder the day before prevent most of the avoidable calls.

After cutover

18. Check mail flow and calendars, including shared mailboxes, delegates and any rules that forward mail.
19. Review security again, and look at the sign-in and audit logs for anything unusual during the first weeks.
20. Set retention and backup. Microsoft keeps the service running, but you should decide how you would recover mail and files after an incident or a mistake, and test it.
21. Decommission carefully. Switch off the old system only after an agreed period and a final check, and keep a copy of anything the business must retain.
22. Tidy licences. Remove accounts and plans you no longer need. Our renewal checklist shows what to check before your next renewal.

When to bring in help

Projects with several hundred mailboxes, a hybrid setup, a tenant merger or strict regulatory duties deserve specialist planning. A cloud migration assessment maps your landscape, the real cost and a sequenced roadmap before you commit.

About this guide

Innoligo is an authorised Microsoft CSP partner. This checklist is general information and applies whoever you buy your licences from or migrate with.

Microsoft, Microsoft 365, Exchange, SharePoint, OneDrive and Outlook are trademarks of the Microsoft group of companies. This guide is independent and is not published or endorsed by Microsoft.