Microsoft 365 Migration Checklist: 10 Things to Check Before You Move

1. Count what you actually have, including the DNS

Most migration surprises are things nobody remembered existed: a shared mailbox created years ago, a room calendar, a distribution list that is quietly how invoices reach accounts, a domain registered by someone who has since left. Build the list before you choose a method, because Microsoft's own guidance for choosing one hangs on your source system and how many mailboxes you have.

Your inventory should cover:

Domains deserve their own line. For a cutover migration, Microsoft expects your primary mail domain to be a verified domain in your Microsoft 365 organisation, and verification means adding a record at your registrar or DNS host. Find out now who holds that login, rather than discovering on cutover weekend that the answer is a former supplier.

The command below is read-only. Run it in the Exchange Management Shell on an on-premises Exchange server, or in Exchange Online PowerShell after connecting, if you are moving from another Microsoft 365 tenant. It lists every mailbox with its type and any mailbox-level forwarding. Replace YOUR_EXPORT_PATH with a file location such as a CSV in a restricted folder. The file contains names and email addresses, so keep it somewhere access-controlled and delete it when you are finished.

• Every user, and which of them are licensed or will need to be.
• Mailboxes by type: user, shared, room and equipment.
• Distribution lists and mail-enabled security groups.
• Every domain that receives mail, and who can log in to its registrar or DNS host.
• Current mail DNS records: MX, SPF, DKIM, DMARC and Autodiscover.
• Any mailbox that is not a person, such as an account a scanner or application signs in with.

Get-Mailbox -ResultSize Unlimited | Select-Object DisplayName, PrimarySmtpAddress, RecipientTypeDetails, ForwardingSmtpAddress, DeliverToMailboxAndForward | Export-Csv -Path "YOUR_EXPORT_PATH" -NoTypeInformation

2. Licences and where your tenant lives

Licences come before tooling because the wrong one can stop a move outright. In a cutover migration, mailboxes arrive as new Microsoft 365 users and you still have to assign them licences afterwards. In a tenant-to-tenant move the rule is stricter: every user in both organisations needs an appropriate Exchange Online subscription, and each moved user needs a Cross Tenant User Data Migration licence. It is a per-user, one-time fee that can sit on either the source or target user, and it also covers OneDrive migration. Microsoft states that migrations fail without it and that it makes no exceptions.

Also check that the plan fits the business you will be in a year from now. Microsoft 365 Business plans are designed for up to 300 users, and SharePoint storage is pooled at 1 TB plus 10 GB for each licence purchased. Go over your storage allowance and the tenant can be put into read-only mode, which is a poor way to find out your file share was larger than you thought.

Finally, look at the tenant's data location. You can see it in the Microsoft 365 admin centre under the Data Location card. Microsoft's Multi-Geo feature adds satellite locations around the original primary one rather than moving it, and small business subscriptions do not currently qualify for it. In practice that means the country or region chosen when a tenant is created should be treated as permanent. If you are creating a new tenant for a UK business, get that right at sign-up.

3. Sign-in security: MFA, old protocols and Conditional Access

If your tenant is new, there is a good chance security defaults are already on. Microsoft rolls them out to new tenants, and they require every user to register for multifactor authentication, require MFA for administrators and block legacy authentication, meaning older clients and the IMAP, POP and basic SMTP protocols that cannot do MFA. Since 29 July 2024 there has been no grace period for registration. The practical consequence is that anything on your old estate that signs in with a plain username and password may simply stop working, so find those things before go-live rather than after.

Decide how people will register. A short, supervised session or a clear instruction sheet beats a hundred users each meeting the setup prompt separately on Monday morning. Microsoft's guidance is to have administrators sign in first so they can register their methods, and to keep separate admin and everyday accounts.

If you want more control than security defaults offer, Conditional Access needs at least Microsoft Entra ID P1. Security defaults must be switched off before you replace them with Conditional Access policies, and Microsoft's advice is to enable the replacement policies immediately so you are not left with a gap. Microsoft also recommends two cloud-only emergency access accounts with the Global Administrator role, so a bad policy does not lock everyone out of their own tenant.

Inheriting an existing tenant, or moving into one that already exists? Look before you add users: whether security defaults are on, which Conditional Access policies exist and who holds Global Administrator. Surprises here are cheaper to find on a Tuesday than during a migration.

Last, decide where identities will be mastered. Staged and Exchange hybrid migrations both need directory synchronisation with your on-premises directory. A cutover migration instead creates new cloud users that you then manage in Microsoft 365. Neither is wrong, but changing your mind afterwards is more irritating than choosing deliberately now.

4. The devices and apps people sign in from

Mailboxes move; the Outlook profile on each person's computer and the mail app on their phone do not move themselves. Microsoft's cutover guidance notes that desktops need to be updated and set up before users can sign in from desktop apps, and that an Autodiscover DNS record, which lets mail apps find the right server, is a post-migration task. Our advice is to list the real variety in your business and test one of each: a Windows PC with the Office version you actually run, a Mac, an iPhone, an Android phone and a shared machine.

Pay particular attention to anything old. A mail client or phone set up with IMAP or POP will fall foul of blocked legacy authentication, and an Office install old enough to lack modern sign-in is better replaced or updated before the move than debugged during it. If any of these are unmanaged personal phones, tell people they will need to re-add their work account.

5. File shares, SharePoint and OneDrive: map before you copy

Moving files is mainly a design job. Shared team content normally belongs in SharePoint document libraries, personal working files in each person's OneDrive, and the old folder tree rarely maps one to one. Decide what goes where, and who needs access, before any copying starts. In our judgement, do not recreate fifteen years of accumulated folder permissions exactly as they were. SharePoint copes better with a small number of sensible permission groups than with thousands of individually permissioned folders.

Microsoft documents limits that bite during real migrations:

Long paths are the usual first casualty, and SharePoint counts the path in the destination, including the site and library, not your old share. The read-only command below, run in PowerShell on a machine that can read the share, lists items whose path beneath the share root is more than 250 characters, which leaves headroom for the destination prefix. Replace YOUR_SHARE_PATH with the share location. Do not suppress its errors: a path too long for PowerShell to read is itself a finding.

• Each file can be up to 250 GB, and the full path including the file name cannot exceed 400 characters.
• When a list, library or folder holds more than 100,000 items, you cannot break or restore permission inheritance on it.
• Microsoft's supported limit for unique permissions in a library is 50,000, with a recommended general limit of 5,000.
• For good OneDrive sync performance, Microsoft recommends syncing no more than 300,000 files in a single library.

$root = 'YOUR_SHARE_PATH'
Get-ChildItem -LiteralPath $root -Recurse -Force | Where-Object { $_.FullName.Length - $root.Length -gt 250 } | Select-Object -ExpandProperty FullName

6 and 7. Forwarding, delegation and everything that sends email on its own

Two kinds of dependency tend to sit unnoticed. The first is people-shaped: mailbox forwarding (shown in the export from check 1), inbox rules that forward mail elsewhere (which that export does not show), Full Access and Send As permissions, calendar delegates and shared mailbox membership. Write these down per mailbox and recheck them after the move. A missing Send As permission produces a bounce containing 5.7.60 when a device or person tries to send as another address. If you are doing a cross-tenant move, remember Microsoft's warnings that mailboxes on any type of hold are blocked and that only user-visible content (email, contacts, calendar, tasks and notes) is migrated.

The second kind is machines. Scanners, line-of-business applications, alarm systems, website contact forms and backup alerts often send mail through your old server with settings nobody has touched since installation. Somewhere there is a scanner that was configured once and will be the first thing to complain. Check device configuration pages, application settings and the old server's relay or connector settings to find them all.

Then pick a route that Microsoft 365 will still support. Client SMTP submission (SMTP AUTH) is off by default for organisations created after January 2020, can be enabled per mailbox, and is disabled while security defaults are on. Basic authentication for it is scheduled for retirement. The timeline has already slipped once, and Microsoft's January 2026 update puts final removal in 2027 or later, but check the current Exchange team announcement before relying on a date. Microsoft's alternatives are OAuth where the device supports it, High Volume Email for internal recipients only, Azure Communication Services Email for internal and external recipients, an SMTP relay connector that authenticates by certificate or static public IP address, and Direct Send, which Microsoft recommends only as a last resort. For fixing a scanner that is already failing, see our Field Note on scan to email and SMTP authentication errors in Microsoft 365.

Once mailboxes exist in Microsoft 365, these read-only commands in Exchange Online PowerShell show whether SMTP AUTH is switched off for the whole organisation and which mailboxes have it explicitly enabled. They help you confirm that exactly the mailboxes you intended to allow can still be used by devices.

Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
$Users = Get-CASMailbox -ResultSize unlimited
$Users | where {$_.SmtpClientAuthenticationDisabled -eq $false}

8. Choose a migration method and decide how mail will coexist

Microsoft's decision guide for moving from Exchange Server splits by version and size. Cutover migration moves everything at once. It is supported up to 2,000 mailboxes, though Microsoft says migrating 150 or fewer is more reasonable, and until you change the MX record, which tells the internet where to deliver your mail, messages continue to arrive in the old mailboxes. For more than 150 mailboxes from Exchange 2003 or 2007, Microsoft points to staged migration; from Exchange 2010, 2013 or 2016 it points to Exchange hybrid. IMAP migration copies email only, so calendars and contacts need another route, and it is the only option for very old Exchange versions and many non-Exchange systems. For mailboxes with a large amount of data, Microsoft also describes importing PST files through the Purview import service. Microsoft suggests involving a partner for very large moves of 5,000 mailboxes or more.

For tenant-to-tenant moves, Microsoft's native cross-tenant mailbox migration needs the target tenant configured first. It also needs a mail-enabled security group in the source tenant to scope who may move, and each person pre-created in the target as a MailUser with specific attributes. After a move, the source mailbox becomes a MailUser pointing at the new tenant, which allows mail routing to continue while the move runs in stages. The native feature covers mailbox content, and the licence also covers OneDrive migration, which has its own process. Plan SharePoint sites and anything else separately.

Whatever the method, run a pilot with a few people who use mail differently, not just the most patient colleagues. Decide in advance how mail and calendar sharing will behave between people who have moved and people who have not. Hybrid and cross-tenant setups are designed for that gap; a cutover avoids it by moving everyone together. Check the time-to-live on your MX record, since it influences how quickly senders pick up the change, and schedule the switch for a quiet period.

9. Rollback and recovery: prove it before you rely on it

What "going back" means depends on the method. In a cutover or hybrid move, the old mailboxes still exist until you remove them, so keep the old server running until the business has signed off. Cross-tenant is different: Microsoft states that after a successful migration the source mailbox is deleted and is not available, discoverable or accessible in the source tenant. Once a person has moved, there is no switching back, so your safety net is testing with a pilot first and having a restorable copy before you start.

Microsoft 365 Backup exists for OneDrive, SharePoint and Exchange Online, and third-party products cover the same ground, so choosing between them is a separate decision. What matters here is narrower. Take a copy of what you cannot afford to lose before the move, then actually restore one mailbox and one folder tree from it and open the result. A backup that has never been restored is a hope, not a recovery plan. Microsoft's own backup documentation makes the same point: what matters is not just taking the backup but restoring to a healthy state quickly.

Finally, do not decommission anything early. Keep the old server, the old subscription and the old DNS records somewhere recoverable until your acceptance checks have passed.

10. Tell people, agree what done means and check after the move

People tolerate change much better when they know what is happening. Tell everyone, in plain words, what changes for them: when it happens, how they will sign in, that they will register for MFA, whether Outlook or their phone needs re-setting up and who to call. Tell them when mail might behave oddly, without promising an exact outage length you cannot control.

Agree acceptance criteria with whoever owns the business before the move, and write them down. Arguing about whether it worked is much easier when you agreed in advance what working means. A sensible list includes:

Confirm the DNS side with a read-only lookup. Run the command below in PowerShell on any Windows computer, replacing YOUR_DOMAIN with your mail domain. The result should point to your Microsoft 365 endpoint, which Microsoft says takes the form YOUR_DOMAIN-com.mail.protection.outlook.com. Compare it with the value shown against your domain in the admin centre. DNS changes can take a while to be seen everywhere, so test from more than one network if the answer is mixed.

If you have read this far and still have unanswered items, that is not a failure. Hybrid coexistence, mailbox holds, tenant-to-tenant moves and tenants you inherited without documentation are the points where it is sensible to bring in someone who has done them before.

• Mail flows in both directions with an address at a completely different provider.
• Shared mailboxes open, and Send As and delegate permissions work.
• Calendars show the right meetings and room bookings still work.
• A scanner, an application and the website contact form each deliver a test message.
• A sample of users can sign in with MFA on their own phones.
• Files are reachable by the people who should have access, and not reachable by someone who should not.
• Every migrated user has a licence assigned.
• Your restore test from check 9 succeeded.

Resolve-DnsName -Name YOUR_DOMAIN -Type MX