Tenant-to-Tenant Migration: The Complete Pre-Migration Checklist

Tenant-to-tenant migrations are among the most technically demanding operations in the Microsoft 365 ecosystem. On the surface they appear like any other migration: move mailboxes, move files, redirect traffic. In practice they involve identity synchronisation across two separate Entra ID tenants, licence management with hard deadlines, service dependencies that are rarely documented, and the near-certainty that something unexpected will happen during the cutover window.

The migrations that go smoothly are not the ones where nothing unexpected happens. They are the ones where the team is prepared enough to handle it when something does.

This checklist covers 47 verification points across seven workstreams. Items that cannot be checked off are your risk register for the project.

Identity and Directory (8 items)

Before moving any user data, identity must be in a known state in both tenants.

1. UPN alignment confirmed. The target UPN suffix (e.g. company.com) is added and verified in the target Entra ID tenant. Users' UPNs in the source will be renamed at migration to match.
2. Entra ID Connect sync scope defined. If the source uses Entra ID Connect (formerly Azure AD Connect) to sync from on-premises Active Directory, the target tenant's sync scope is defined and tested. Confirm whether the target will be cloud-only or hybrid.
3. Duplicate UPNs checked. Run a comparison of source and target user lists to identify UPN conflicts before migration begins. Conflicts cause silent migration failures.
4. Guest accounts audited. Source tenant guests who need to be migrated or transitioned are identified. External collaborators who will become internal users in the target are documented.
5. Service principals and app registrations inventoried. Applications registered in the source Entra ID tenant that need equivalent registrations in the target are listed. Third-party SaaS applications with Entra ID SSO integration require reconfiguration.
6. Managed identities assessed. Azure resources using managed identities in the source subscription need a migration plan if the Azure subscription is moving.
7. Break-glass accounts created in target. Before any migration work begins, emergency access accounts in the target tenant are created and tested. These are not linked to the migration tooling.
8. Directory synchronisation conflicts resolved. Any objects in the source that have synchronisation errors are cleaned up before migration. These will cause failures in the target if carried across.

Licensing (5 items)

Licence timing in tenant-to-tenant migrations is a constraint, not a detail. Errors here cause service interruptions.

9. Licence availability confirmed in target tenant. Sufficient licences of the correct type are available in the target tenant before users are migrated. Do not assume procurement will move faster than the migration.
10. Licence assignment timing planned. The window between when a source user's licence is removed and when the target licence is assigned must be minimised. During this gap the user has no access. For Exchange, this gap causes mail delivery failures.
11. Specialised licences identified. Users with Defender for Endpoint, Purview compliance, or other specialised licence add-ons require equivalent licences in the target. These are frequently missed.
12. Trial licences excluded from migration scope. Users on trial licences in the source do not have equivalent coverage in the target by default. Identify and address before cutover.
13. Post-migration licence audit scheduled. After migration, a licence audit confirms all users have the correct entitlements. Automate this with a PowerShell report rather than relying on manual review.

Mail Flow and Exchange (8 items)

Exchange Online migration is the workstream with the most visible failure modes. User experience during cutover depends heavily on this preparation.

14. MX record TTL reduced in advance. At least 48 hours before cutover, reduce MX record TTL to 300 seconds (5 minutes) to minimise mail delivery delays during the DNS change.
15. Shared mailboxes and resource mailboxes inventoried. All shared mailboxes, room mailboxes, and equipment mailboxes are documented with their current owners and permissions.
16. Distribution lists and mail-enabled groups mapped. Each distribution list in the source tenant needs an equivalent in the target. Decide whether to migrate or recreate — large DLs with nested groups require particular attention.
17. Mail contacts for coexistence configured. During the migration period, users who have already moved need to receive mail from users who have not yet moved, and vice versa. Mail contacts or cross-tenant synchronisation must be configured for this.
18. Mail flow rules (transport rules) documented. Encryption, routing, and compliance transport rules in the source tenant are documented and prepared for recreation in the target.
19. Exchange Online Protection configuration reviewed. Anti-spam, anti-phishing, and Safe Links policies in the source are documented. Default policies in the target may differ — verify before cutover.
20. Archive mailboxes accounted for. Users with Exchange Online Archive or Compliance Archive enabled require the archive to be included in the migration scope. Archiving is frequently overlooked.
21. SMTP relay configuration verified. On-premises systems, printers, and applications that use SMTP relay through Exchange Online must be reconfigured to use the target tenant's relay endpoint.

Teams and SharePoint (7 items)

Teams and SharePoint are the workstreams where user experience during migration is hardest to manage.

22. Teams meeting links invalidation communicated. All existing Teams meeting links generated in the source tenant will stop working at cutover. Users must reschedule recurring meetings. This needs a user communication plan.
23. Teams channel tabs and connectors inventoried. Custom tabs, Power Automate connectors, and third-party integrations in Teams channels need to be identified and reconfigured in the target.
24. SharePoint permissions documented. Site-level permissions, unique folder permissions, and shared links in SharePoint are documented before migration. Permissions do not migrate automatically — they need to be recreated.
25. External sharing links addressed. "Anyone" and "People in your organisation" sharing links in the source tenant become invalid after migration. External recipients with active links need to be notified.
26. OneDrive migration quota verified. Users with large OneDrive repositories (>100 GB) need a migration timeline that accounts for transfer speed. Do not assume all OneDrives can be migrated in a single cutover window.
27. SharePoint site template compatibility checked. Custom site templates and branding in the source may not transfer cleanly to the target. Test with a representative sample before full migration.
28. Teams recording storage migrated. Teams meeting recordings stored in SharePoint or OneDrive must be explicitly included in the migration scope. Recordings stored in Stream (classic) require a separate migration path.

Devices and Intune (6 items)

29. Autopilot profiles prepared in target tenant. Windows Autopilot deployment profiles in the target tenant are created and tested before any device migration begins.
30. Intune compliance policies recreated. Device compliance policies, configuration profiles, and app protection policies are recreated in the target Intune tenant. Do not attempt to export/import — rebuild from documentation to avoid carrying over misconfigurations.
31. Device enrolment strategy confirmed. Decide whether devices will be re-enrolled (device wiped and enrolled fresh to target) or migrated using a tool such as the Opsora Endpoint Migrator, which moves devices without requiring a wipe. For organisations with distributed workforces, remote re-enrolment is complex — a migration tool significantly reduces the risk.
32. Conditional Access policies prepared. Target tenant Conditional Access policies must be configured before device migration begins. Migrated devices that cannot pass compliance checks will lose access immediately.
33. BYOD (personally owned devices) addressed. Personal devices enrolled in the source Intune tenant need a separate communication and migration plan. A wipe-and-re-enrol approach is not feasible for personal devices.
34. Certificate profiles assessed. Devices with SCEP or PKCS certificate profiles require the certificate infrastructure to be replicated or equivalent in the target before device migration.

Cutover Planning (8 items)

35. Migration waves defined. Users are grouped into migration waves by department, location, or risk tolerance. The first wave should be IT staff and willing volunteers — not the executive team.
36. Rollback procedure documented. If a critical failure occurs during cutover, what is the procedure to restore service? For Exchange, this means reverting MX records. For identity, it means restoring source tenant access. Document this and test it.
37. Communication plan approved. Users receive advance notice of the migration window, what will change, and who to contact if they experience issues. The communication should be plain language, not technical. Allow 5 working days' notice minimum.
38. Helpdesk briefed and scheduled. First-line support needs to know what is happening, what the common issues are, and how to resolve them. Schedule additional helpdesk coverage for the 48 hours following each migration wave.
39. Migration tooling tested in a pilot. The migration tool (IMAP migration, batch migration, or a third-party tool) is tested against a pilot group of 5–10 users before any production waves begin. Verify that mailbox content, calendar items, and contacts all migrate correctly.
40. DNS change authority confirmed. Who has access to change DNS records, and how long does the change propagate within your organisation's DNS infrastructure? This must be confirmed before the cutover window, not during it.
41. Cutover window timing agreed. Migration cutover should happen outside business hours for the affected user population. For pan-European organisations, this may require weekend cutover windows.
42. Post-cutover verification tests defined. Before declaring a migration wave complete, run a standard set of tests: send and receive a test email, access a shared mailbox, verify OneDrive sync, confirm Teams access, check Conditional Access compliance.

Post-Migration (5 items)

43. Source tenant decommission timeline agreed. Define when licences in the source tenant will be removed and when the tenant itself will be closed. The source tenant should not run indefinitely — it creates a security and cost overhead.
44. DNS cleanup completed. Old MX records, SPF entries, DKIM selectors, and any other DNS records pointing to the source tenant are removed after the migration and coexistence period ends.
45. Residual access revoked. Any service accounts, guest accounts, or admin accounts in the source tenant that were created for the migration are reviewed and removed.
46. Documentation updated. The organisation's IT documentation is updated to reflect the new tenant. Runbooks, onboarding guides, and support procedures that reference the source tenant are revised.
47. Post-migration health check scheduled. 30 days after the final migration wave, run a structured health check: verify licence compliance, confirm no orphaned accounts, check audit log retention, review Conditional Access policy effectiveness.

The Three Most Common Failure Points

Mail coexistence is not configured. The most disruptive failure mode in a phased tenant-to-tenant migration is mail not flowing between users who have already migrated and users who have not. This requires explicit coexistence configuration — mail contacts, cross-tenant synchronisation, or a similar mechanism — and it must be tested before the first user moves.

Device re-enrolment is underestimated. Organisations that plan to wipe and re-enrol devices frequently discover that a significant portion of their device fleet cannot be reached remotely for the re-enrolment process. Users on leave, devices in remote locations, and shared workstations all present challenges. A migration approach that moves device enrolment without a wipe — such as the Opsora Endpoint Migrator — eliminates this class of problem.

Teams meeting link communication is missed. Every scheduled Teams meeting in the organisation has a link that will break at cutover. This is not a technical failure — it is an expected consequence of the migration. It becomes a support incident when users are not warned in advance. The communication plan must explicitly address this, and users need to receive clear instructions for rescheduling recurring meetings before the cutover date.

Tenant-to-tenant migrations are not inherently dangerous, but they are unforgiving of incomplete preparation. Every item on this checklist represents a discovered failure mode from real migrations. Working through it systematically before you begin is the difference between a well-executed cutover and a multi-day incident.

If you are planning a migration and need experienced programme leadership, see how Opsora approaches tenant-to-tenant migrations.