The constraint that shapes the whole plan
A custom domain can be verified in only one Microsoft 365 tenant at a time. Before the destination tenant can add example.com, every reference to it must be removed from the source: user names, email addresses, aliases, groups and the domain itself. During that window, the domain is not attached to either tenant.
This is why cutover is a scheduled event, not a gradual move. Everything else in the plan is about making that window short and predictable.
1. Discovery
- User mailboxes, shared mailboxes, resource mailboxes and their sizes, including archives
- Distribution lists, Microsoft 365 groups and their owners
- OneDrive accounts and SharePoint sites, with total data volume and item counts
- Teams, channels, private and shared channels
- Every domain and subdomain in the source tenant, and every DNS record that points to Microsoft
- Applications that sign in with Microsoft accounts, including SSO apps, line-of-business apps and scanners using SMTP
- Devices joined to the source tenant or enrolled in Intune
- Licences in use and licences needed in the destination
- Mail-flow rules, retention policies, legal holds and anything under litigation hold
2. Design decisions to agree in writing
- Identity. How user names will look in the destination, and whether users keep their current addresses.
- Tooling. Microsoft's native cross-tenant mailbox migration needs a per-user add-on licence and trust configured between the tenants. Third-party tools such as BitTitan MigrationWiz are also licensed per user and cover mailboxes, OneDrive and documents in one place. Choose per workload.
- Teams. Agree up front what happens to chat history. Channel files move with SharePoint. Chats are the most limited part of most tools.
- Cutover date and time, usually a Friday evening or weekend, with a named go or no-go decision point.
- Rollback. What you will do if the destination cannot verify the domain within the window.
3. Prepare the destination tenant
- Create users with temporary
onmicrosoft.comaddresses and assign licences - Set up MFA, conditional access, admin roles and break-glass accounts before anyone signs in
- Recreate shared mailboxes, groups and distribution lists
- Create SharePoint sites and Teams structures that match the agreed design
- Prepare DKIM for the domain so it can be enabled immediately after verification
4. Pilot
Move 3 to 5 users across different roles, including someone from finance and someone with a large mailbox. Check mail, calendars, delegation, shared mailboxes, OneDrive and Teams. Fix what you find and update the runbook before the main migration.
5. Pre-stage
- Copy mailbox and OneDrive data in the background, one to two weeks before cutover
- Run a delta pass a day or two before cutover to keep the final sync small
- Lower the TTL of MX, Autodiscover and SPF records to 300 seconds at least 48 hours before cutover
- Send users a short note with the date, what will change and what to do on the first morning
6. Cutover
- Freeze changes in the source: no new users, groups or aliases.
- Point MX to a holding destination, or accept a short queue. Sending servers retry for days, so mail is delayed, not lost.
- Remove the domain from every object in the source tenant, then remove the domain itself.
- Verify the domain in the destination tenant and switch users' primary addresses to it.
- Update MX, Autodiscover, SPF and the DKIM records for the destination. Enable DKIM signing.
- Run the final delta sync of mail and files.
- Send test messages in both directions from outside the company, and check headers for SPF, DKIM and DMARC passes.
7. Day-one support
- New Outlook profiles, or Outlook signed in again with the new account
- OneDrive sync client signed in to the new tenant
- Mobile mail and Authenticator apps reconfigured
- Shared mailboxes and calendar delegation checked for each team
- Someone available in person or on a call for the first hours of the morning
8. Close out
- Keep the source tenant read-only for an agreed period, then decommission it and cancel its licences
- Watch DMARC reports for a few weeks for any sender still using the old tenant
- Restore normal DNS TTLs
- Hand over documentation: users, groups, DNS, security settings and the migration report
The most common problems
| Problem | Cause | Prevention |
|---|---|---|
| Domain will not verify in destination | A forgotten alias, group or user still uses it in the source | Script the search for every object using the domain before the night |
| Calendar invites reply to old addresses | Cached addresses in Outlook autocomplete | Clear autocomplete and tell users to re-add external contacts |
| Scanners and apps stop sending email | They authenticate to the old tenant | List every SMTP sender in discovery and reconfigure them during cutover |
| Mail from the new tenant goes to spam | DKIM not enabled or SPF not updated | Prepare DKIM in advance and test authentication before users start work |