Microsoft 365 Migration: Preflight, Cutover, and Cleanup That Actually Close the Job

A Microsoft 365 migration can look successful while leaving the business with missing delegates, broken scanners, split mail flow, inaccessible files, unowned admin accounts, or a source system nobody dares to switch off.

That happens when the project is treated as data movement rather than an operating change.

The useful question is not “Did the migration tool finish?” It is:

Can the business now work from the destination, can the result be proved, and can the old environment be retired without losing access, evidence, or a recovery path?

This guide provides a control framework for answering that question. It deliberately does not give one universal sequence of buttons or DNS values. Microsoft supports several migration paths, and their provisioning order can differ. A rule that is correct for an ordinary IMAP onboarding can be wrong for a tenant-to-tenant orchestrated move.

The short version

A controlled migration has five evidence gates:

1. Define: record the business outcome, in-scope workloads, owners, exclusions, acceptance criteria, and source-retirement conditions.
2. Discover: inventory identities, domains, recipients, permissions, data, applications, devices, policies, integrations, and dependencies from the real environments.
3. Prove: prepare the destination, choose a supported method, run a representative pilot, measure exceptions, and rehearse rollback or containment.
4. Cut over: freeze only what is necessary, make approved changes in a recorded order, monitor both ends, and communicate from a channel that does not depend on the service being changed.
5. Close: validate business workflows, resolve deltas, transfer ownership, remove temporary privilege, retain the source for the approved period, and decommission only after written acceptance.

If a project has no written scope, pilot evidence, rollback criteria, or named acceptance owner, it is not ready for a production cutover.

First decide what “Microsoft 365 migration” means

The phrase can describe very different projects:

• moving mail from an IMAP provider into Exchange Online;
• moving from on-premises Exchange to Exchange Online;
• moving from Google Workspace into Microsoft 365;
• consolidating one Microsoft 365 tenant into another;
• moving file shares into SharePoint, Teams, and OneDrive;
• changing identity from a federated or synchronised model to cloud-managed identity; or
• doing several of those things in one coordinated programme.

Microsoft’s current migration documentation separates tenant-to-tenant and third-party moves, and its current Exchange Online migration overview distinguishes Exchange, IMAP, Google Workspace, PST import, and partner-assisted paths. Those methods do not move the same objects or preserve the same behaviour.

Write a one-sentence outcome before selecting a tool. For example:

Move 42 named people, six shared mailboxes, current mail and calendars, agreed file libraries, and the company domain into the owner-controlled Microsoft 365 tenant, with accepted access and mail flow, then retire the old provider after a 30-day validation period.

That is testable. “Move us to 365” is not.

Build the migration brief before the technical plan

The brief should name:

• the business owner who accepts the result;
• the technical change owner and a separate rollback decision-maker where practical;
• source and destination organisations, tenants, subscriptions, domains, and administrators;
• every in-scope workload and every explicit exclusion;
• user groups, locations, time zones, working hours, and critical dates;
• legal, contractual, retention, eDiscovery, privacy, and data-location constraints;
• the expected coexistence period, if any;
• acceptable interruption and degraded-service windows;
• measurable acceptance tests;
• the source-retention and decommissioning decision; and
• the support and escalation path during and after cutover.

Record assumptions as questions until they are verified. “There are no public folders” is not an inventory result. “The source administrator exported zero public folders at 14:10 SAST on 2 September and the owner confirmed none are expected” is evidence.

Inventory the operating system around the data

Mailbox size and file count matter, but the surrounding relationships cause many of the expensive failures.

Identities and access

Record:

• users, sign-in names, primary addresses, aliases, employee or owner status, and source identifiers;
• administrators, roles, privileged groups, service accounts, guests, and external collaborators;
• authentication methods, MFA registration state, federation, directory synchronisation, Conditional Access, device requirements, and self-service recovery;
• shared or generic sign-ins that must be replaced with accountable access; and
• emergency access that remains usable if the normal identity path fails.

Microsoft’s current emergency-access guidance recommends independent cloud-only emergency accounts, strong authentication, secure credential storage, monitoring, and regular validation. A migration is exactly the wrong time to discover that every administrator depends on the identity system being changed.

Do not copy an emergency-account design blindly. Confirm the organisation’s security policy and Microsoft requirements, then test the agreed access path before the maintenance window.

Mail recipients and relationships

Inventory more than user mailboxes:

• shared, room, equipment, archive, inactive, and discovery mailboxes;
• distribution lists, mail-enabled security groups, Microsoft 365 groups, dynamic groups, contacts, and aliases;
• Full Access, Send As, Send on Behalf, folder, calendar, and delegate permissions;
• forwarding, inbox rules, moderation, booking policies, transport rules, journaling, disclaimers, and connectors;
• accepted domains, remote domains, allow and block entries, outbound restrictions, and gateways; and
• mobile devices, Outlook profiles, cached data, add-ins, signatures, autocomplete expectations, and line-of-business integrations.

Mailbox content does not prove that these relationships moved. Microsoft documents recipient permissions separately in its current mailbox-permission guidance; your chosen migration method must be checked against every object and permission type in scope.

Files, sites, teams, and sharing

Record source paths, owners, intended destinations, size, item count, versions, metadata, sharing links, guests, permissions, unsupported names, locked or corrupt items, workflows, apps, and business purpose.

Do not turn every file share into one person’s OneDrive. Personal working data may belong there; team-owned content usually belongs in a shared library or Team. Microsoft’s current file-share migration guide explicitly separates planning, assessment and remediation, destination preparation, migration, and user onboarding. It also documents behaviours that are not carried across exactly, including some advanced file-system permissions.

Applications, devices, and non-human senders

Find website forms, multifunction devices, monitoring systems, payroll and invoicing tools, CRM platforms, backup products, scanners, scripts, applications, and third-party security gateways that send mail or use Microsoft identities and APIs.

For each one, record:

• business and technical owner;
• current identity and authentication method;
• sender address and domain;
• source network or service;
• destination and relay model;
• secret or certificate owner, expiry, and rotation path;
• required permissions;
• test method; and
• retirement or reconfiguration decision.

Do not solve these senders by enabling tenant-wide legacy authentication or anonymous relay. Use the provider’s supported model for the actual application. The separate SMTP diagnostic guide explains how to prove the handoff without weakening transport security.

Establish control of both ends

Before moving data, prove that authorised people can administer and recover both source and destination without relying on one individual, one browser session, or the domain being transferred.

Capture, through an approved secure process:

• tenant and subscription identifiers;
• domain registrar and authoritative DNS host;
• billing and licence ownership;
• normal and emergency administrative access;
• vendor support entitlements and escalation contacts;
• source backup, retention, export, and deletion behaviour;
• destination audit and monitoring access; and
• who can approve DNS, identity, licence, and destructive changes.

Do not paste credentials into the project plan. Record where the approved secret is held, who can retrieve it, and when access was last tested.

For tenant-to-tenant moves, domain ownership is a sequencing constraint. A custom domain cannot simply serve two Microsoft 365 tenants as though they were one. Microsoft’s current tenant-to-tenant planning guidance makes identity mapping, domain transfer, workload dependencies, coexistence, licensing, and batch timing explicit planning concerns.

Choose the method from the source and required outcome

Create a method decision table instead of selecting the most familiar tool.

Microsoft’s current migration-path guidance and migration performance guidance should be checked for the actual source. Performance is influenced by source health, network, data characteristics, service throttling, concurrency, and the chosen protocol. A completion date cannot be guaranteed from raw bandwidth alone.

Be especially careful with provisioning order. Ordinary IMAP onboarding requires destination mailboxes before content migration. By contrast, Microsoft’s current Migration Orchestrator prerequisites warn that prematurely provisioning certain target mailboxes or OneDrive sites can break its identity-mapping workflow. The method’s current documentation—not a generic checklist—must control the sequence.

Prepare the destination before asking users to depend on it

Destination readiness includes more than creating accounts.

Confirm, for the agreed design:

• tenant ownership, billing, privacy, region, support, and service health access;
• verified domains without prematurely changing production routing;
• identity source, naming, user mapping, MFA, recovery, privileged roles, Conditional Access, and device posture;
• licences and service plans assigned in the required order;
• Exchange accepted domains, recipients, permissions, connectors, rules, and protection;
• SharePoint, OneDrive, Teams, sharing, guest, and information-governance settings;
• retention, holds, labels, audit, eDiscovery, and deletion responsibilities;
• support access, user communication, and service-desk scripts; and
• monitoring and evidence collection for the pilot and cutover.

Licences are not merely a purchasing line. They determine service provisioning and feature availability. Microsoft’s current group-based licensing guidance also warns that assignment order can create an avoidable service interruption when moving users between licensed groups. Confirm actual service-plan state for the pilot users; do not infer it from the group name or invoice.

Retention also needs precise language. Microsoft service retention after account or subscription deletion is not the same as the organisation’s configured retention policy, legal hold, recoverable backup, or accepted source-retention plan. Use current tenant-specific evidence and Microsoft’s data retention, deletion, and destruction overview as one platform boundary—not as a substitute for the organisation’s obligations.

Treat DNS as a controlled mail-flow change

Before the window, export the current zone and record authoritative answers for the relevant names. Identify the registrar, DNS host, approver, TTLs, DNSSEC state, and any split internal/external DNS. Record which services depend on each entry.

For mail, reconcile:

• domain verification;
• MX routing and any security gateway;
• Autodiscover and client-discovery behaviour;
• SPF senders;
• DKIM selectors and signing state;
• DMARC policy and reporting;
• application, website, bulk-mail, and relay dependencies; and
• any coexistence connector or smart host.

Microsoft’s current custom-domain setup guidance says to prepare users and mailboxes before changing the MX record in an ordinary onboarding scenario. Its DNS-record guidance supplies tenant-specific values through the admin workflow. Use the values shown for the actual tenant and service selection; do not copy records from another domain or an old article.

If mailboxes remain in more than one location, document the intended routing model and validate the current Microsoft multi-location mail-flow guidance. Improvised forwarding can create loops, break replies or authentication, hide delivery evidence, and leak messages to a source that was supposed to be retired.

Changing MX does not migrate old mail, and changing SPF does not route inbound mail. The DMARC operating guide explains why the complete sender estate must be reconciled before policy is tightened.

Run a representative pilot—not a ceremonial one

A pilot should deliberately include awkward cases:

• an ordinary user with a manageable mailbox;
• a large or high-change mailbox;
• a delegate and delegated mailbox;
• a shared mailbox or group workflow;
• a mobile and desktop user;
• an external collaborator;
• a user with calendar history and recurring meetings;
• a file owner with sharing and permissions;
• a line-of-business sender or device; and
• a user in a remote location or constrained network.

Before the pilot, record expected source counts, sizes, mappings, permissions, and workflow outcomes. After it, reconcile:

• copied, skipped, failed, duplicate, and transformed items;
• identity and address mapping;
• folder, calendar, contact, delegate, and group behaviour;
• client sign-in and rediscovery;
• internal, inbound, outbound, relayed, and external-domain mail flow;
• SharePoint, OneDrive, Teams, sharing, and sync behaviour in scope;
• authentication, Conditional Access, MFA, and recovery;
• application and device integrations;
• user understanding and support volume; and
• actual duration, throughput, throttling, and retry behaviour.

Do not mark the pilot successful because the tool says “completed.” Every exception needs a disposition: fix before cutover, accept with owner sign-off, exclude explicitly, or change the method.

Define the cutover gate

The change owner should be able to answer “yes” to all of these before authorising the window:

• The scope and object inventory are current and signed off.
• The source and destination administration paths were tested.
• The selected method is supported for the measured source and required outcomes.
• Pilot exceptions are resolved or explicitly accepted.
• Pre-stage or synchronisation is within the agreed delta threshold.
• Target identities, licences, recipients, permissions, and policies match the method’s required order.
• DNS values, current zone export, approver, TTL evidence, and rollback entries are recorded.
• Coexistence and routing have one documented model.
• Communication can continue if email or Teams is unavailable.
• Support staff have user mappings, known issues, escalation contacts, and a secure evidence template.
• The rollback or containment trigger has an owner and a latest decision time.
• No source deletion or licence removal is bundled into the cutover merely for neatness.

If any answer is “we assume so,” either gather evidence or record an explicit owner-accepted risk. Silence is not acceptance.

Run the cutover as a decision log

Use the exact approved runbook for the chosen method. For every material action, record:

• planned and actual time;
• actor and approver;
• source and destination state before the action;
• command, portal action, or provider change reference without exposing secrets;
• immediate verification;
• unexpected result and decision; and
• rollback or containment status.

Keep the action list short enough to operate. Put explanations, inventories, and evidence in linked records rather than making the live runbook unreadable.

Monitor source and destination service health, migration status, authentication, mail flow, DNS answers, security alerts, and support reports. A rising error count, stalled batch, unexpected lockout, or routing loop is a decision signal—not a reason to make several unrecorded changes.

Validate business outcomes after cutover

Validate with named owners and time-stamped evidence.

Identity and administration

• normal users and administrators can sign in through the intended path;
• MFA, recovery, Conditional Access, device requirements, and emergency access behave as designed;
• privileged roles are limited and temporary migration access is identifiable;
• source and target identities map to the intended people; and
• leavers, guests, service identities, and unlicensed accounts have explicit dispositions.

Mail and calendars

• internal, inbound, outbound, reply, forwarded, and external-domain messages trace end to end;
• aliases, shared mailboxes, groups, rooms, equipment, delegates, rules, connectors, and gateways behave as accepted;
• calendars, recurring meetings, organisers, permissions, and free/busy work for the chosen coexistence state;
• applications, websites, scanners, and other approved senders authenticate and align as intended; and
• no broad relay, allowlist, legacy-authentication, or security bypass was introduced.

Files and collaboration

• source-to-destination counts and exception reports are reconciled;
• business owners can reach the intended files, sites, teams, and libraries;
• permissions and sharing were tested with both allowed and disallowed users;
• sync clients, known folders, links, workflows, metadata, versions, and external collaboration behave according to the accepted mapping; and
• unmigrated or transformed content has an owner and resolution date.

Operations

• help-desk ownership, monitoring, alerting, audit, backup, retention, recovery, billing, and licence administration are live;
• user communications match the real experience;
• known issues and workarounds have expiry and review dates; and
• the destination can be operated without depending on the migration engineer’s private notes or personal account.

Cleanup is a controlled phase, not an afterthought

Cleanup should reduce temporary risk and operational ambiguity without destroying the recovery path.

Remove temporary migration access

Review and remove, rotate, or expire:

• migration service accounts, application consents, secrets, certificates, API permissions, and delegated roles;
• temporary firewall, connector, allowlist, Conditional Access, throttling, and logging exceptions;
• staging storage, exported CSV files, reports containing personal data, diagnostic traces, and local tool caches; and
• vendor access and support accounts no longer required.

Retain only the evidence required by the approved project, security, legal, and privacy policy. Store it in an owner-controlled location with access and deletion dates.

Reconcile the destination

Close failed and skipped items; remove test users and test messages appropriately; confirm final aliases and group membership; review duplicate objects; apply normal licence governance; rotate temporary credentials; and confirm the responsible owners for domains, DNS, billing, security, retention, and support.

Do not hide unresolved exceptions inside a “migration complete” percentage. A tiny failed item count can contain the one mailbox, permission, or file the business needs tomorrow.

Keep the source deliberately

Define a source state for the validation period:

• read-only where supported, or otherwise tightly controlled;
• no unintended mail routing or ongoing content changes;
• licences sufficient for the approved access and retention model;
• monitored administrator access;
• preserved logs, exports, and rollback evidence; and
• a named decision date for final decommissioning.

Do not assume that cancelling a subscription, removing a licence, deleting a user, or releasing a domain has the same retention and recovery effect. Confirm the actual source-provider and contract behaviour first.

Decommission only after acceptance

Before destructive source changes, require:

• written business acceptance against the agreed tests;
• resolved or accepted delta and exception reports;
• confirmed legal, retention, eDiscovery, export, and backup decisions;
• proof that mail, identity, files, applications, and devices no longer depend on the source;
• owner-controlled destination administration and documentation;
• final source evidence and a credible recovery route for the agreed period; and
• a separately approved decommission plan with its own rollback boundaries.

A migration and a source decommission may be in the same programme, but they are different changes.

Hand over an operable service

The final handover pack should contain:

• approved scope, exclusions, owners, and acceptance record;
• source-to-destination identity, recipient, site, team, and data mappings;
• final domain, DNS, mail-flow, authentication, and sender-estate records;
• licence and subscription ownership;
• migration batch, exception, delta, and validation evidence;
• privileged-access and temporary-access closure evidence;
• known issues, workarounds, owners, review dates, and expiry dates;
• backup, retention, restore, audit, monitoring, and incident responsibilities;
• normal support and vendor escalation paths;
• source-retention state and decommission date; and
• a short “how we know it works” summary a future administrator can reproduce.

Avoid a handover that is only screenshots. Screenshots help with context but are poor inventories and cannot reliably prove all values. Preserve structured exports where supported, plus readable decisions and enough current portal evidence to explain them.

A migration is complete when the old ambiguity is gone

The strongest migration projects do not merely move content. They replace an uncertain source state with an understood destination state.

You know who owns the tenant and domain. You know which identities, mailboxes, files, permissions, applications, and devices moved. You can trace mail, recover access, operate the service, explain the exceptions, and show why the source can be retained or retired.

That is a more demanding finish line than “the batch completed.” It is also the finish line that lets the business move on.