Microsoft 365 Tenant-to-Tenant Migration: A Practical Guide

A tenant-to-tenant migration looks simple on a whiteboard: copy the mailboxes, copy the files, move the domain. In practice the copying is the easy part. What decides whether Monday morning is quiet is the order you do things in, and how much you found out before you started.

This is the sequence I follow. It comes from real cross-tenant work, including a property business with a separate family tenant and domains moving between the two; the outline is on the case studies page. I use MigrationWiz (BitTitan) for the mailbox and OneDrive passes, but the sequence holds whichever tooling you choose.

When you actually need one

Four situations account for almost every tenant-to-tenant project I see:

• Acquisition or merger. The acquired company’s users, mail and files need to live in the parent’s tenant.
• Demerger or divestment. Part of a business is leaving and has to take its data and domain with it.
• Rebrand to a new domain where the old tenant is messy enough that starting clean is cheaper than tidying up.
• Consolidation. Several small tenants, often created ad hoc over the years, being collapsed into one.

Ask first whether you need to migrate at all. If the real requirement is that one business unit runs its own IT inside a shared tenant, administrative segregation is often the better answer; see delegating admin in a shared tenant.

Discovery: count everything before you commit to a date

Before agreeing a cutover date I want an inventory of:

• Users and mailboxes, including shared mailboxes, room and equipment mailboxes, and archive mailboxes, with sizes and item counts.
• Licences in the source, and what each user will hold in the target. A mailbox or archive that depends on a plan the target does not have is a problem you want to find now.
• OneDrive and SharePoint data volumes, per user and per site.
• Groups: distribution lists, mail-enabled security groups, Microsoft 365 groups and Teams, with owners and members.
• Guests in the source tenant, and the external tenants where your own users are guests.
• Devices: how each one is joined (Entra joined, hybrid joined, or just registered), whether it is in Intune, and whether it is registered for Autopilot.
• DNS: every record on the domain, who controls the zone, and the current TTLs.
• Third-party apps tied to the old tenant: single sign-on, app registrations, SMTP relay from printers and line-of-business systems, backup products, and anything that sends mail from a shared mailbox.

The last item takes the longest. Mailboxes migrate; an integration that authenticates against the old tenant has to be rebuilt.

The constraint that shapes the plan: one domain, one tenant

A custom domain can only be verified in one Microsoft 365 tenant at a time. If users are keeping their email addresses, the domain has to be removed from the source tenant before it can be added to the target. There is no overlap period where both tenants hold it.

That single rule drives the whole design:

• The domain cannot be removed while anything still uses it. Every user sign-in name, email address, group address and Teams or SIP address on that domain has to be changed first, normally to the tenant’s onmicrosoft.com domain. This is scripted, and worth rehearsing.
• Between removal from the source and verification in the target, the domain belongs to no tenant. Mail to it has nowhere to land. Your job is to make that window short and to control what happens to mail during it.
• Cutover is therefore a single event for everyone on that domain. Data can be migrated in batches beforehand, but moving half the users on a domain one week and half the next needs address rewriting or forwarding, which adds its own complexity.

Build the target tenant before any data moves

I do not start a copy until the target is ready to be lived in. Otherwise you spend the first month after go-live retrofitting controls around people who are already working. The baseline is:

• Identity. Target accounts created with a temporary sign-in name on the target’s onmicrosoft.com domain, ready to be switched to the real domain at cutover.
• MFA and Conditional Access. Policies in place and tested with pilot accounts before users arrive. Break-glass accounts created and excluded deliberately.
• Licence groups. Licences assigned by group rather than by hand, so a new account picks up the right plan automatically. Group-based licensing has its own licence requirement, so check what your plan includes.
• Device management. Intune enrolment, compliance and configuration policies built, so devices have something to enrol into.

It is the same foundation described on the infrastructure and security page.

Pre-stage, then delta

Mail and files are copied in two stages. The pre-stage pass moves the bulk of the data, typically everything older than a cut-off date, while users carry on working in the source. The delta pass runs at and after cutover and picks up whatever changed since.

The point of pre-staging is that the cutover-weekend copy is small. How long the first pass takes depends on data volume, item counts and throttling by the service. Migrate a handful of representative mailboxes and OneDrives first, measure, then plan the rest from what you observed.

Microsoft also has native cross-tenant mailbox and OneDrive migration features, with their own licensing and prerequisites. Check the current Microsoft documentation before choosing between native and third-party tooling.

The cutover sequence

This is the order I write into the runbook.

1. Lower DNS TTLs on the mail records a few days ahead, so changes take effect quickly on the night.
2. Deal with inbound mail (see below) before the domain comes out.
3. Strip the domain from the source. Run the script that moves every user, group and resource off the custom domain, then remove the domain from the source tenant. Removal can take a while to complete, so allow for it.
4. Add and verify the domain in the target, then switch target users to their real sign-in names and primary email addresses and recreate aliases.
5. Update DNS. MX, Autodiscover, SPF, DKIM and DMARC. Use the exact values the target tenant gives you. DKIM in particular has to be set up again, because the records point at the tenant that signs the mail. SPF needs every legitimate sender listed, not just Microsoft 365.
6. Run the delta pass against the source mailboxes and OneDrives, which are still reachable under their onmicrosoft.com addresses.
7. Test inbound and outbound mail, DKIM signing and a DMARC pass before anyone signs in.
8. Re-point users and devices, covered next.

What happens to mail in flight

While the domain sits in neither tenant, a message sent to it cannot be delivered. If the MX record still points at Exchange Online and no tenant accepts the domain, the sender is likely to get a non-delivery report, which is the outcome you most want to avoid.

The usual mitigations are to keep the gap short and out of hours, and to change the MX record beforehand so that sending servers cannot connect at all, or connect to a service that holds mail for you. A sending server that cannot connect will normally queue the message and retry. How long it keeps trying is decided by the sender’s system, so treat queuing as cover for hours, not days.

Devices: the part that reaches every desk

An Entra joined Windows device cannot simply be pointed at the new tenant. It has to leave the old one and join the new one, and the user gets a new profile when it does. Plan for:

• Autopilot. A device registered for Autopilot in the source has to be deregistered there before it can be registered in the target.
• Intune. Devices are retired from the source and enrolled into the target, across Windows, macOS, iOS and Android. Mobile devices usually need the old management profile removed first.
• Profile rebuilds. A reset and fresh Autopilot enrolment is the cleanest route. Profile migration tools exist, but test them on your own hardware first.
• Outlook. A new Outlook profile against the new mailbox. Cached autocomplete entries for colleagues can point at old internal addresses and cause bounces, so clear them or add the old addresses to the new mailboxes.
• Teams and OneDrive. Sign out and back in with the new account. OneDrive needs unlinking and relinking, and users need telling what to do with the old synced folder left on disk.

What breaks that people forget

Hypercare

The first working day is where the project is judged. I plan for someone on site or on a staffed line, a short list of known issues with fixes, and one person triaging so the same problem is not solved five times. Log everything reported: it shows which issues are one-offs and which need a fix pushed to everyone.

Leave the source tenant intact, with its licences, until you are sure nothing was missed. A further delta pass a few days in catches stragglers. Anything on a retention or legal hold needs a decision before the source is decommissioned.

A short pre-cutover checklist

• Inventory signed off, including groups, guests and third-party apps.
• Target tenant baseline live: MFA, Conditional Access, licence groups, Intune policies.
• Pre-stage pass complete, with errors reviewed, not just counted.
• Domain removal script tested, and the plan for inbound mail during the gap agreed.
• DNS access confirmed, TTLs lowered, new record values written down in advance.
• Permissions and delegation exported from the source.
• Device plan agreed, user guide issued, hypercare cover booked.
• A rollback decision point defined: the last moment at which you can still put the domain back.

The scope and approach I work to are on the Microsoft 365 migration page.

FAQ