Microsoft 365 migration readiness checklist

A Microsoft 365 migration checklist is the difference between a tenant move that goes cleanly and one that costs weeks in clean-up, because almost everything that determines the outcome happens in the preparation, not the cutover. The checklist below runs through audit, identities, permissions, pilot, cutover, rollback and go-live.

A tenant migration moves an organisation’s entire Microsoft 365 environment, including email, files, user identities, permissions and devices, from one Microsoft tenant to another. It is most common after an acquisition, a demerger, a rebrand or a change of IT provider.

For the case for why preparation matters so much, see the hidden cost of a bad Microsoft 365 tenant migration. This page is the plan itself.

Before you start: what a tenant migration moves

You are moving several things at once: mailboxes and their full email history, OneDrive and SharePoint files, Teams and the structures beneath them, user identities and passwords, permissions and sharing links, device enrolment and licensing.

These elements depend on one another. Identities are the foundation. If a user’s identity does not come across cleanly, they cannot log in, so they cannot reach the files and email you carefully migrated. That is why the checklist is ordered as it is: audit first, identities and permissions next, then the cutover, then the safety net, then the people.

Phase 1: audit and discovery

You cannot move cleanly what you have not mapped. This is the phase most often skipped under time pressure, and the one that most reliably prevents surprises.

• Inventory all users, mailboxes, shared mailboxes and distribution lists.
• Map file and SharePoint data volumes.
• List every Team and confirm its owner.
• Document current licensing across the estate.
• Identify what is in use versus dormant.
• Flag anything that can be retired rather than migrated.

A migration is the best opportunity a business gets to leave clutter behind. The output is a complete picture of the estate, which every later decision depends on.

Phase 2: identities and permissions

This is the foundation, and the block that most rewards careful planning.

• Plan the identity model for the target tenant.
• Map each source identity to its target.
• Plan how permissions and sharing links will carry across.
• Plan for guest and external access, which is easy to forget and disruptive when it breaks.
• Decide the approach to passwords and multi-factor authentication so users are not locked out on day one.

This block is the most often under-planned and the most costly to get wrong. Everything a user owns is reachable only through their identity.

Phase 3: plan the cutover

• Choose a phased or piloted approach rather than a big-bang switch.
• Select a representative pilot group to move first.
• Set a realistic timeline that protects the planning time even when a corporate deadline is fixed.
• Plan mail routing and coexistence so the two environments work together during the move.
• Schedule the cutover for the lowest-impact window you can find.

The first real test of a migration should be a small pilot you can learn from, not the whole company on the first Monday morning.

Phase 4: rollback and contingency

A migration without a way back is a bet, not a plan. This phase is short but non-negotiable.

• Define a tested rollback position, not just a theoretical one.
• Set clear go/no-go criteria so the decision to proceed is made on evidence.
• Keep the source tenant available until the target is fully verified.
• Plan for the known failure points: mail flow, access and directory sync.

The value of this phase only becomes visible if something goes wrong, and by then it is too late to create it.

Phase 5: communication and go-live

A well-briefed team absorbs disruption that an unprepared one turns into a support queue.

• Brief users on exactly what is changing and when.
• Prepare short quick-reference guidance for the first day.
• Staff the support window heavily for the first 48 hours, when questions cluster.
• Confirm mail flow, access and file availability immediately after cutover.
• Run a defined post-migration verification rather than assuming success.

The National Cyber Security Centre’s cloud guidance is worth a read on keeping the environment secure through a change, since the migration window is one of the moments an estate is most exposed. Microsoft’s own cross-tenant mailbox migration documentation covers how the mailbox move is handled technically.

After the migration: the productivity tail

The cutover is not the finish line. In the following weeks, small breakages, a broken link here, a missing calendar permission there, quietly drain hours across the business if nobody is watching.

• Schedule a post-migration review a couple of weeks out.
• Give users a clear channel to report small breakages.
• Run a Microsoft 365 licence review once the estate has settled, so you do not carry licences you no longer need into the new tenant.
• Look at wider cloud spend, which our guide to Azure cost optimisation for UK SMBs covers.

How Lanmark runs Microsoft 365 migrations

We treat a migration as a planning problem first and a technical one second. Lanmark is a Microsoft Direct CSP partner, with a direct billing and support relationship with Microsoft rather than working through a distributor. We run migrations to this checklist: an audit first, identities and permissions planned first, a phased cutover with a pilot, and a tested rollback position.

Plan the migration before you commit to a date

The best time to work through this checklist is before a timeline is locked and before the first cutover. If an acquisition, a rebrand or a change of provider puts a Microsoft 365 migration on your horizon, see our Microsoft 365 services or SmoothSwitch, and get in touch to scope it properly.