Skip to main content

“We’re moving to Microsoft 365 next month” sounds straightforward, until someone asks whether the backup restores, the shared mailbox permissions are documented, or the MX record change has a rollback path.

Before cutover, the key question isn’t whether the migration is scheduled. It’s whether the people, data, mail flow, access, and recovery plan are ready to move together.

Recent client migrations have ranged from a small business with 16 mailboxes and 15 distribution lists to a 130-mailbox, two-site move. The size changes the workload; the readiness fundamentals stay the same.

Use this checklist to ask your IT team or IT support provider what has to be true before the switch.

1. Backups Must Be Verified, and Restorable

A backup job that reports “successful” is not proof that the right data can be recovered. Before cutover, establish what is protected, how recovery works, and whether a test restore has succeeded.

  • Confirm scope: Identify which mailboxes, archives, shared mailboxes, calendars, and other data are covered. Record anything excluded.
  • Test a restore: Restore representative content and check that it opens, is complete, and can be recovered using the planned process.
  • Keep the evidence: Save the restore result, backup coverage, recovery steps, and the name of the person responsible.
  • Preserve migration records: Keep a source inventory and configuration exports for items that may not be included in mailbox backups, such as group membership and mail-flow settings.

Microsoft distinguishes backup and recovery planning from simply relying on the availability of Exchange Online. Review its guidance on backing up email in Exchange Online, and verify that your specific backup approach meets your recovery needs.

Who owns it: Your IT lead or managed IT services migration partner, with a business owner approving recovery requirements.
Risk of skipping it: You may discover a gap only after something is missing, and need it back.

A technician verifies that backed-up mailbox data can be restored

2. Distribution Lists and Shared Mailboxes Need Owners and Maps

Mailbox counts alone do not describe how your company communicates. Distribution lists, shared mailboxes, aliases, delegates, and permissions also need to be accounted for.

For every distribution list and shared mailbox, document:

  • Its address, purpose, owner, members, and aliases.
  • Who can send to it, who can send from it, and whether messages require moderation.
  • Who has access, and whether that access is Full Access, Send As, or Send on Behalf.
  • Where mail should route after cutover, including forwarding and application-generated mail.

Then test representative cases: an internal sender, an external sender, a restricted list, and someone replying from a shared mailbox. Don’t assume that recreating an address recreates the way it works.

Who owns it: Department leads confirm the business purpose and membership; IT maps and tests the technical configuration.
Risk of skipping it: Messages can go to the wrong people, important senders can be blocked, or staff can lose access they rely on.

3. Mail Flow, DNS, and Domain Verification Must Be Ready

A move is not ready just because the target mailboxes exist. The internet and your business systems need to know where to send mail.

Before cutover, confirm that:

  • Your business domain is verified in the destination tenant.
  • DNS access is available to the person making the change, and current records are documented.
  • The team has reviewed the records that may need changing, including MX, SPF, DKIM, DMARC, and Autodiscover.
  • Mail gateways, connectors, printers, scanners, and applications that send email have been inventoried and tested.
  • The team knows the expected change window and how it will confirm mail is flowing after DNS changes.

Microsoft’s guidance on DNS and Microsoft 365 migrations explains why DNS planning matters. Exact records and steps depend on your migration design, so verify them against your environment rather than copying a generic checklist.

Who owns it: The administrator with DNS access and your migration lead.
Risk of skipping it: Inbound or outbound messages may be delayed, misrouted, or rejected.

A clear map of mailboxes, groups, domains, and mail-flow routes

4. Licences Must Be Counted and Right-Sized Before Cutover

Before migration, reconcile the users and services that need licences against the licences available. Confirm that the selected plans support the features each person or shared mailbox actually needs, and assign them before the move.

A practical count should cover:

  • Active users and their required services.
  • Shared mailboxes and any requirements that affect licensing.
  • People or resources that need access to email, Office apps, Teams, or other services.
  • Available seats, planned assignments, and any gaps to resolve before cutover.

This is the right-sizing work for the migration, not the whole subscription-cleanup exercise. Dormant or “zombie” licences are a separate cost-control problem. Review our guide to common IT cost-saving mistakes for that follow-up.

Who owns it: Your licensing or finance contact, with IT validating technical requirements.
Risk of skipping it: Users may arrive in the new environment without the access they need, or the business may pay for more than it uses.

5. Consent, Credentials, Admin Rights, and Sign-In Are Tested

Your migration team needs approved access before cutover, not a last-minute scramble for passwords, tenant permissions, or application consent.

Confirm that:

  • Required administrators have named accounts, appropriate roles, and working access.
  • A secure process is in place to provide and store credentials; credentials are not passed around in email or chat.
  • Any tenant-to-tenant permissions, application integrations, or admin-consent requests are reviewed and approved by the right person.
  • A pilot group has tested sign-in with MFA and any Conditional Access policies on the devices and apps employees use.
  • Support staff know what to do if a user cannot authenticate or complete MFA registration.

Microsoft explains the security implications of granting tenant-wide admin consent. Treat consent as an approval decision: understand what access is being granted and to whom.

Who owns it: The tenant administrator and designated business approver.
Risk of skipping it: Users can be locked out, applications can stop working, or permissions can be granted without clear approval.

6. The Cutover Has a Sequence and a Rollback Plan

“Change the records and see what happens” is not a cutover plan. Your team should be able to explain the order of work, the go/no-go point, and what will happen if a critical test fails.

Ask for a written runbook that includes:

  1. The cutover date, time, change window, and named decision-makers.
  2. The order for final data synchronization, DNS and mail-flow changes, and user access checks.
  3. Clear success criteria and conditions that would pause or stop the cutover.
  4. The exact rollback actions, who can authorize them, and how messages or data created during the change will be handled.
  5. How long the source environment will remain available while the new setup is verified.

Keep the source system and migration evidence available until the agreed validation period is complete. A rollback should not be treated as automatic or lossless; the team needs to consider what happens to new mail and changes made after cutover.

Who owns it: The migration lead prepares the runbook; the business owner approves the decision points.
Risk of skipping it: A problem can become a prolonged outage while people decide what to do next.

A business owner and IT lead review a phased cutover and rollback plan

7. Post-Migration Verification and User Communication Are Scheduled

The move is not finished when the last mailbox sync completes. Users need to confirm their everyday work functions, and your IT team needs to know how issues will be reported and tracked.

Schedule checks for:

  • Inbound and outbound mail, replies, attachments, aliases, and important distribution lists.
  • Shared mailbox access, delegated permissions, and sending from the expected address.
  • Outlook, webmail, mobile access, calendars, and essential business applications.
  • Mail from key external partners and systems such as scanners or line-of-business software.
  • Migration reports, failed items, and unresolved issues.

Tell employees what is changing, when to expect it, what they may need to do, and where to ask for help. Give them one clear support route and an update cadence. If your provider offers a customer/member portal, use it to see ticket status and project updates in one place. Ask your provider whether a migration pre-flight checklist is available in your member portal.

Who owns it: IT coordinates testing and support; department leads confirm business-critical workflows.
Risk of skipping it: Small issues can linger, leaving users to improvise fixes or report the same problem through multiple channels.

Be Ready Before You Move

Before approving cutover, ask for evidence, not just reassurance. You should be able to see a successful restore test, a reconciled mailbox and licence count, documented list and mailbox settings, reviewed DNS and mail flow, tested sign-in, a named cutover owner, and a rollback plan.

That is the practical difference between moving to cloud services and managing an orderly managed IT services migration. For business IT support services, you need a partner who can explain the sequence, show what is verified, and tell you what happens if a test fails.

  • IT Downtime Cost Calculator: Link pending.
  • Shadow AI Risk Self-Assessment: Link pending.

Talk with PWP SYSTEMS about the readiness questions your team still needs to answer. Be Faster. Do More.


Companion Cheat Sheet for Sonny

Five-Step Summary

  1. Prove recovery: Verify backup coverage and complete a test restore.
  2. Map people and mail: Document distribution lists, shared mailboxes, owners, permissions, and routing.
  3. Prepare the destination: Verify the domain, DNS, mail flow, licences, admin access, consent, and sign-in.
  4. Plan the switch: Approve cutover sequencing, go/no-go criteria, and rollback steps.
  5. Test and communicate: Validate business workflows after migration and tell users where to get support.

Social Caption

Moving to Microsoft 365 next month? Don’t stop at “the migration is scheduled.” Before cutover, verify that backups restore, mail routes correctly, licences and permissions are ready, and your team has a rollback plan. Our practical pre-cutover checklist helps business owners know what to ask before the switch. Be Faster. Do More.

Suggested Carousel

  1. M365 migration next month? Ask these questions first.
  2. Can you restore the backup? A backup exists ≠ a restore is proven.
  3. Do you know who gets the mail? Map distribution lists and shared mailboxes.
  4. Are DNS, licences, consent, and sign-in ready? Check them before cutover.
  5. What’s the rollback plan? Define the sequence, decision-makers, and tests.
  6. Verify, communicate, and move with confidence. Read the full checklist.

Visual Direction

Use PWP SYSTEMS’ navy, cobalt blue, cyan, and white palette. Keep each carousel slide focused on one checklist item, with simple mailbox, cloud, DNS, shield, and checkmark icons. Use a clean, high-contrast layout and practical language. End with the PWP SYSTEMS name and “Be Faster. Do More.”

Leave a Reply