Tenant-to-tenant Microsoft 365 migrations

When this comes up

Tenant-to-tenant migrations almost always arrive with a deadline attached and someone else's timetable driving it. The common triggers:

• An acquisition — two businesses becoming one, and one set of staff needs to land in the other's environment
• A demerger or divestiture — separating one business into two, which means deciding what data belongs to whom before anything moves
• A rebrand onto a new domain — new identity, new email addresses, same people and history
• Leaving a managed provider who holds the tenant on your behalf, and taking ownership of your own environment

What makes this harder than a first-time migration is that both tenants are live and in use the whole time. There is no quiet source environment to copy from at leisure — people are sending mail and editing files in both places while the move happens.

What moves

Mail, calendars and contacts

Mailboxes including archives, shared mailboxes, distribution groups and calendar permissions. Archive size is the thing that most often stretches a timeline, and it is worth measuring early rather than assuming.

OneDrive and SharePoint

Personal files and site content, with the permission structure carried across rather than rebuilt from memory. Long-lived SharePoint sites tend to hold years of accumulated sharing that nobody has audited — a migration is a reasonable moment to look at it.

Teams

Teams, channels and the files behind them move well. Private chat history is the awkward part, and it is covered honestly in the questions below rather than glossed over.

Identity and licensing

Accounts, sign-in names, groups and licence assignment. This is the part that determines whether people can actually work on the Monday morning after, and it is sequenced so nobody is stranded between two tenants.

How it runs

1. DiscoveryBoth tenants: user counts, mailbox and archive sizes, SharePoint and OneDrive volumes, domains, licensing on each side, and the integrations that send mail through the old tenant. Surprises found here are cheap; found at cutover they are not.
2. Decide the destination shapeNaming, groups, licences and what does not come across. A migration is the one sensible opportunity to leave old clutter behind — but that has to be a decision, not an accident.
3. PilotA small group moved first, working properly in the destination before anyone else follows. This is where the plan gets corrected while it is still cheap to correct.
4. Pre-stage the dataMail and files synchronised into the destination over days or weeks. By cutover, only the recent delta remains — which is why a well-run cutover is short.
5. Domain cutoverThe tight window: the domain is removed from the source tenant and added to the destination, mail routing switches, final syncs run. Scheduled outside business hours and rehearsed beforehand.
6. AftercareThe first week is when the real questions surface — signatures, mobile devices, a shared mailbox nobody mentioned, an app still pointed at the old tenant. We stay close through it.

The parts people underestimate

The domain can only live in one tenant. It has to be removed from the source before it can be verified in the destination. That constraint sets the shape of the entire cutover, and it is the reason this work is planned backwards from the domain move.

Licensing overlaps. For a period you are likely paying on both sides. Knowing that upfront and keeping the overlap short is a cost question as much as a technical one.

Things that send mail as you. Line-of-business applications, the scan-to-email on the copier, alerts from monitoring tools, invoicing systems. These are almost never documented and are the most common cause of "something stopped working" a week later.

The outgoing provider. Where a migration is a provider exit, the constraint is often access and goodwill rather than technology. Sorting out early exactly what you control and what must be requested avoids a stalled project.

Common questions

How long does a tenant-to-tenant migration take?

For a business of 5 to 50 users, four to six weeks from discovery to cutover is typical — longer than a first-time migration because both tenants are live and in use throughout. What actually drives the timeline is data volume, how much Teams and SharePoint content has to move, and how quickly decisions get made about domains and licensing.

Can we keep our email address after the migration?

Yes, if the domain is moving with you. A domain can only exist in one Microsoft 365 tenant at a time, so it has to be removed from the old tenant before it can be added to the new one — which is the single tightest window in the whole project and is planned carefully rather than left to the day.

Does Teams chat history move across?

Teams files, channels and site content move well. Private chat history is the awkward part — it is limited by what Microsoft exposes, and expectations are better set at the start than discovered at cutover. Where chat history genuinely matters, we will tell you honestly what can and cannot come across before you commit.

Will people be locked out during the move?

No. Data is pre-staged into the destination tenant over days or weeks, so cutover moves only the small amount that changed since the last sync. The switch is scheduled outside business hours, and mail sent during it queues at the sending server and delivers once DNS updates.

We are leaving our current IT provider who owns the tenant. Can you help?

Yes, and it is a common reason for this work. The complication is rarely technical — it is access, timing and goodwill with the outgoing provider. Establishing exactly what you control, what they control, and what has to be requested from them is the first thing we sort out.