A Microsoft 365 migration checklist covers five stages: plan and licence each user, get the domain, DNS and admin access right, choose the migration method, set up security as part of the move, then switch mail over and check everything. Agree a way back before cutover, and keep the old system until the new one is proven.
I have worked in IT and development since 1998, and Rizonetech is a Microsoft Partner that moves businesses to Microsoft 365 and runs its own email on it. Reviewed 14 October 2026 by Derick Payne.
How do you plan and licence the move?
List what you have before anything moves: every mailbox, shared address, alias and distribution list, and the files and where they live. Add the systems that send mail as your domain, such as accounting software, the website and printers. Look for mail that lives only on people’s computers, such as POP accounts and Outlook data files (.pst): server migration tools do not see it, so plan to import it from the Outlook file and check it arrived.
Then choose a licence for each person, not one plan for everyone. Microsoft says a shared mailbox “can store up to 50 GB of data without assigning a license to it” (Microsoft). Above that size, for a larger archive, or for litigation hold, it needs a licence, and the people who open it need licensed mailboxes of their own. Our Business Standard vs Business Premium guide helps decide who needs which plan.
Read the commitment terms before you order. Annual subscriptions under Microsoft’s New Commerce Experience can only be cancelled in a short window at the start of each term. Our guide to NCE licence terms explains the windows. Our own NCE agreement needs 60 days’ written notice to stop a renewal.
What belongs on the Microsoft 365 migration checklist before mail moves?
- Add and verify your domain. Microsoft asks for a TXT record to prove you own the domain. It says verification can take up to 10 minutes, and some registrars up to 48 hours (add a domain). Verifying proves ownership; it does not move your mail.
- Plan the DNS records. Microsoft’s DNS records page lists the MX record as required, and Autodiscover and SPF as “optional but highly recommended”. Keep a single SPF record: if one exists, add Microsoft 365 to it rather than creating a second.
- Plan email authentication for every sender. Set up and test SPF, DKIM and DMARC for each service that sends as your domain. Authentication helps receivers verify your mail; it does not guarantee the inbox. Google says “We can’t guarantee messages sent by email providers will pass Gmail’s spam filters”.
- Decide who holds admin access. Your business should hold the Global Administrator accounts, with your provider given access it can be removed from. Our security settings guide covers admin accounts.
- Plan how files move. Local file shares and on-premises SharePoint can move with the free SharePoint Migration Tool. From Google Drive, Microsoft uses Migration Manager, which converts Google files to Office formats and tells you to “Review unsupported files and migration reports to identify content that wasn’t copied”. Decide which content goes to each person’s OneDrive and which to shared SharePoint sites. Before copying, map users and groups, and choose the permission and version settings. Microsoft says file-level permissions “aren’t migrated by default” and “only the most recent file version is copied” by default. Also find orphaned Google files, which “aren’t scanned, migrated, or listed in migration reports”. External sharing links are not recreated, so list the ones you need.
Then set a date when people stop editing the old files. Run a final migration pass to copy what changed. By default, Migration Manager’s “Migrate again” copies only new or modified files, and it does not overwrite a destination file that was edited more recently, so resolve files edited in both places. Check it, and keep the old files read-only until the checks pass.
Our own domain, rizonetech.com, shows the DNS side of the result. On 13 October 2026 its MX record pointed to Microsoft 365, its single SPF record named Microsoft 365 and ended in -all, and both DKIM selector records pointed to the tenant. Those records alone do not prove that mail is signed; a test message’s headers do. Its DMARC policy was p=none, which asks receivers to take no action on failing mail while the domain is monitored.
Which migration method fits: all at once, or in stages?
It depends on where you are moving from and how many mailboxes:
| Moving from | Microsoft’s method | What moves |
|---|---|---|
| Your own Exchange server, 150 mailboxes or fewer | Cutover migration | Mailboxes, all at once |
| Your own Exchange server, more mailboxes | A method that moves a few users at a time, such as hybrid; check Microsoft’s guidance for your version | Mailboxes, in groups |
| Google Workspace | Google Workspace migration | Mail, calendars and contacts, in batches, with exclusions |
| Another email host | IMAP migration | Mail only |
Microsoft’s migration overview says a cutover can move up to 2,000 mailboxes, “but due to length of time it takes to create and migrate 2,000 users, it’s more reasonable to migrate 150 users or less”. For larger moves from Exchange 2010 to 2016, its older migration paths page recommends a hybrid migration. Microsoft also says support for Exchange Server 2019 and 2016 ended on 14 October 2025. Record your server’s version and support status first, and check the current requirements for that version. The Google route does not move items such as room bookings and shared calendars. With IMAP, “Contacts, calendar items, and tasks can’t be migrated”, so plan to export and import them separately.
Each method prepares the destination differently, so follow Microsoft’s guide for your source. Where the method moves users in batches, migrate a small pilot batch first. A cutover from Exchange moves everyone in one batch, so test with a few representative users’ mail and devices before the switch instead. For a Gmail move by IMAP, Microsoft’s own advice is: “It’s a good idea to create a test migration batch with a small number of mailboxes to first test the process” (Microsoft). Choose deliberately, and write the choice into the plan with its dates.
When should you set up security?
As part of the move, in the written scope and the quote, so it is planned before cutover rather than left for later. That means multifactor sign-in for every user, protected admin accounts, and, on Business Premium, device enrolment, Conditional Access and device protection, each tested before people rely on it. Our Microsoft 365 security settings guide gives the settings for each licence. When we move a business, the setup is checked step by step, and the admin access and a written record are handed to the client at the end.
What happens at cutover, and in the days after?
- Lower the MX record’s time to live first. Microsoft suggests setting it to 3,600 seconds or less before the migration, so the final switch takes effect sooner (cutover migration).
- Confirm the destination is ready. Before the MX change, every destination mailbox must exist and its first migration must be checked. Microsoft’s DNS guide says to “add users and set up mailboxes in Microsoft 365 for all email users on your domain” before updating the MX record. How they are created depends on the method.
- Agree a way back. Write down what would make you stop, who decides, and how mail returns to the old system. Include how mail and file changes made in Microsoft 365 after cutover are kept and copied back. Our cloud migration rollback plan guide explains the parts of a rollback plan.
- Switch the MX record in a quiet window. Microsoft says that after the change, “all new email for anyone who uses your domain is sent to Microsoft 365”. In practice, mail moves over as sending systems refresh their DNS, so some can still reach the old system for a while.
- Wait before you tidy up. Microsoft says it can take up to 72 hours for other mail systems to see the new MX record. In a cutover from Exchange, only delete the migration batch once its last sync is more recent than the switch. After that, mail to the old system is no longer copied.
- Check the move, then retire the old system. Use the checks below. If you ran your own Exchange server, also find what else still depends on it, such as devices relaying mail through it or managing users. Microsoft warns: “If you use your last Exchange server for any purpose other than recipient management (for example, SMTP relay), then don’t shut it down.” Replace those uses first, and follow Microsoft’s decommissioning steps.
How do you know it worked? Check:
- the migration reports, for failed and skipped items;
- a sample of mailboxes and folders, against the old system;
- mail in and out with outside addresses, including aliases and shared mailboxes;
- Outlook on computers and phones for a few users;
- a test message from every service that sends as your domain, for SPF, DKIM and DMARC passes;
- file access for a few users in each shared folder, including someone who should not have access, and the external sharing links you recreated;
- that important documents open, converted spreadsheets and their linked formulas still work, and the version history you chose is there;
- calendars and contacts for a few users, against the old system, with anything the tool does not move either preserved or accepted as lost.
Our free Microsoft 365 check is one part of that. From your browser, it reads whether Microsoft recognises your domain, how your mail is routed, and whether your SPF, DKIM, DMARC and Autodiscover records are in place. It cannot see mailbox contents or sign-in settings. In the first week, have someone available for “where did my folder go?” questions.
What mistakes cause a bad migration?
- Switching the MX record before the destination mailboxes are ready, so new mail arrives at missing or empty mailboxes.
- Deleting the migration batch or the old system too early, so late mail is lost.
- A second SPF record, when Microsoft’s guidance is that “there should be a single SPF TXT record”.
- The provider holding the only admin account, so the business cannot get back in if the relationship ends.
- No checks after cutover, so a missing mailbox, calendar or shared file is found weeks later.
FAQ
How long does a Microsoft 365 migration take?
It depends on the number of mailboxes, how much data each holds and the source system. Plan at least 72 hours after the MX change before tidying up, because Microsoft says other systems can take that long to see it.
Can we lose email during the move?
Yes, it can happen, which is why the checks matter. The risk drops when the destination mailboxes are ready before the MX change and the migration reports are reviewed. Keep the old system until the move is proven, and have a written way back.
Can we keep our old email addresses?
Yes, if you control the domain. Add and verify it in Microsoft 365, create the mailboxes and aliases the addresses need, then switch mail routing when you are ready. The domain’s registration does not need to move.
What should you do next?
Run the free Microsoft 365 check on your domain to see where it stands today. For help moving to Microsoft 365, we plan the move so mail keeps arriving. We warn you before any step that could interrupt it.
Published 16 June 2026. Last updated 14 October 2026.