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. 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. This page sets out a step-by-step readiness checklist covering audit, identities, permissions, pilot, cutover, and rollback, in plain English. As a Microsoft Direct Cloud Solution Provider, Lanmark plans and runs these moves with direct Microsoft support behind the work.

If you want the case for why the preparation matters so much, our companion piece on the hidden cost of a bad Microsoft 365 tenant migration sets out where rushed migrations lose money. This page is the constructive other half: the plan itself.

Before you start: what a tenant migration moves

It is worth being clear about the scale, because the interdependence is what makes a migration harder than it looks. You are not moving one thing, you are moving several 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, which means they cannot reach the files and email you carefully migrated. That single fact is why the checklist below is ordered the way it is: audit first so you know what you are moving, identities and permissions next because they are the foundation, 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 phase is the one most often skipped under time pressure, and the one that most reliably prevents nasty surprises.

Work through: 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 actually in use versus what is dormant; and flag anything that can be retired rather than migrated. A migration is the best opportunity a business ever gets to leave clutter behind, so use it. The output of this phase is a complete picture of the estate, which is the thing every later decision depends on.

Phase 2, identities and permissions

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

Work through: 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; and decide the approach to passwords and multi-factor authentication so users are not locked out on day one. Be honest with yourself here, because this is the block that is most often under-planned and the most costly to get wrong. Everything a user owns is reachable only through their identity, so if the identity is wrong, the well-migrated data behind it is worthless until it is fixed.

Phase 3, plan the cutover

With the estate mapped and identities planned, the next decision is how you flip the switch.

Work through: 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; and schedule the cutover for the lowest-impact window you can find. The principle is simple: 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.

Work through: define a tested rollback position, not just a theoretical one; set clear go/no-go criteria for the cutover so the decision to proceed is made on evidence; keep the source tenant available until the target is fully verified; and plan specifically for the known failure points, which are 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. Build it before you need it.

Phase 5, communication and go-live

A well-briefed team absorbs disruption that an unprepared one turns into a support queue. The final phase is as much about people as technology.

Work through: 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; and 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 weeks that follow, small breakages, a broken link here, a missing calendar permission there, quietly drain hours across the business if nobody is watching for them.

Plan for it: schedule a post-migration review a couple of weeks out, give users a clear channel to report the small breakages, and take the chance to run a Microsoft 365 licence review now that the estate has settled, so you are not carrying licences you no longer need into the new tenant. This is also the natural moment to look at wider cloud spend, which our guide to Azure cost optimisation for UK SMBs covers.

Download the checklist

We are preparing a one-page version of this readiness checklist as a downloadable PDF, built to be board-briefable and practitioner-usable, so you can work through it or use it to hold a partner to account. In the meantime, if you would like a copy or want to talk through your own migration, get in touch and we will send it over.

How Lanmark runs Microsoft 365 migrations

We treat a migration as a planning problem first and a technical one second, because that is where it is won or lost.

Lanmark is a Microsoft Direct CSP partner, which means we hold a direct billing and support relationship with Microsoft rather than working through a distributor. We are also accredited with the Microsoft Support Service Designation, held by only a handful of partners worldwide, which gives us a direct line to Microsoft’s support when a migration needs it. In practice, we run migrations to exactly the checklist above: an audit first, identities and permissions planned first, a phased cutover with a pilot, and a tested rollback position, all with Microsoft support behind the work rather than a ticket in a global queue.

Frequently asked questions

What is a Microsoft 365 migration readiness checklist?

It is a structured, phase-by-phase plan for moving an organisation’s Microsoft 365 environment from one tenant to another cleanly. It covers auditing what exists, planning identities and permissions, sequencing a phased cutover, preparing a rollback position, and communicating with users. The purpose is to make sure nothing critical is missed before the cutover, because that is where migrations succeed or fail.

What should I do first when planning a tenant migration?

Start with a full audit and discovery phase. Inventory users, mailboxes, shared mailboxes, files, Teams, and licensing, and identify what is actually used versus dormant. You cannot migrate cleanly what you have not mapped, and the audit is also the best opportunity to retire clutter rather than carry it into the new tenant.

Why are identities and permissions so important in a migration?

Identities are the foundation of a Microsoft 365 environment. If a user’s identity does not come across cleanly, they cannot log in, which means they cannot reach their files or email regardless of how well those were migrated. Permissions decide who can see what. Both are the blocks most often under-planned and the most costly to get wrong, so they should be planned first.

Should we migrate everyone at once or in phases?

A phased or piloted cutover is almost always safer than a big-bang switch. Moving a small pilot group first lets you find and fix problems before the whole business depends on the migration. A big-bang cutover can look faster and then cost weeks in clean-up if something breaks on the first day.

Do we need a rollback plan?

Yes. A tested rollback position, with clear go/no-go criteria and the source tenant kept available until the target is verified, is what separates a plan from a bet. If something goes wrong during the cutover, you need a clean way back rather than a scramble under pressure.

Can Lanmark run our Microsoft 365 migration for us?

Yes. Lanmark is a Microsoft Direct CSP partner accredited with the Microsoft Support Service Designation. We run tenant migrations to this checklist: an audit first, identities and permissions planned first, a phased cutover, and a tested rollback position, with direct Microsoft support behind the work.

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 means a Microsoft 365 migration is on your horizon, get in touch and we will help you scope and plan it properly. You can also read the companion piece on the hidden cost of a bad tenant migration and more about our wider Microsoft cloud services.

Lanmark is a Microsoft Direct CSP partner accredited with the Microsoft Support Service Designation, an accreditation held by only a handful of partners worldwide.