The data is the straightforward part. Identity is what makes these projects hard, and the domain can only live in one tenant at a time.
Mail and files move between tenants with mature tooling. What makes a tenant-to-tenant migration different from any other is that user identities cannot come with them: the accounts are new objects, devices joined to the old tenant have to be dealt with, and every application authenticating against the source identity needs re-establishing. On top of that a verified domain can only exist in one tenant at a time, which turns the cutover into a genuinely constrained event rather than a flexible one.
- New identitiesAccounts do not carry across
- One tenantA domain can only be verified once
- DevicesRe-registration is a user-facing event
- Deal-drivenThe date usually is not yours
Eight workstreams, and identity determines the shape of all of them.
Identity, which is genuinely rebuilt rather than moved
Accounts in the target are new objects with new underlying identifiers. Nothing about the old identity carries across, which affects anything that referenced a user by identifier rather than by address. Where an on-premises directory is involved, the synchronisation arrangement has to be redirected as well, and that sequencing is one of the more delicate parts of the whole exercise.
The domain, and the constraint it creates
A verified domain can exist in only one tenant at a time, which means it must be removed from the source before it can be added to the target. That is the pivot point of the entire migration and it is why cutover is a genuinely constrained event with a real window rather than a gradual transition. Everything in the plan is arranged around this single fact.
Mail, with a delta pass at the end
Mailbox content migrates with mature tooling, and the pattern is a bulk pass well ahead of cutover followed by a delta pass in the window itself. What needs deliberate handling is the period around the domain move, when mail may be arriving at one tenant while users are being moved to another, and where inbound mail routing has to be planned rather than assumed.
OneDrive, SharePoint and Teams content
File content moves reasonably well. Teams is more involved, because a team is a group, a set of channels, a SharePoint site, a chat history and a membership list, and not all of it migrates equally. Private channels, chat history and Planner plans are the recurring gaps, and the honest approach is to establish what will not come across and communicate it rather than discover it.
Devices, which is the visible part for users
Machines joined to the source Entra tenant have to be re-registered or rejoined, and depending on the approach this ranges from a background operation to something requiring each user to sign in again and reconfigure. It is the part users actually experience, so it needs planning and communication far more carefully than the data migration does.
Applications bound to the source identity
Every SaaS product using single sign-on against the source tenant, every enterprise application registration, every service principal and every automation authenticating with a source identity. These have to be re-established in the target, and the inventory is invariably longer than anybody expects because departments have connected things independently over years.
Policy, compliance and the configuration nobody lists
Conditional access policies, device compliance, sensitivity labels, retention policies, DLP rules and legal holds. None of this migrates: it is rebuilt in the target, ideally deliberately rather than by replicating whatever the source had. For a divestiture there is also the question of what compliance data must be extracted before access to the source is lost.
Coexistence, which is more limited than in hybrid Exchange
Two tenants can share some visibility, and cross-tenant synchronisation can give people access across the boundary during a transition. It is genuinely useful and it is not the same as Exchange hybrid, so expectations need setting: free/busy and collaboration across tenants are more constrained, and the aim is to keep the overlap period as short as the business can tolerate.
Eight things that make tenant migrations different, and how we handle each.
The domain can only be in one tenant
Removing it from the source and adding it to the target is a hard pivot with a real window. Everything else in the plan arranges itself around this constraint.
- Plan the window with the business, since it constrains mail flow
- Have inbound routing decided for the period around the switch
- Rehearse the sequence, because it is not something to improvise
Identifiers do not carry across
Target accounts are new objects. Anything that referenced a user by identifier rather than by email address will not follow them, and that includes more than people expect.
- Inventory anything keyed on user identifiers rather than addresses
- Third-party SaaS user mappings frequently need rebuilding by hand
- Plan for permissions to be reapplied rather than transferred
Devices have to be re-established
The most visible part of the project for end users, and the one that generates the support volume. The approach chosen determines whether it is quiet or disruptive.
- Decide the device approach early, since it drives the communication plan
- Pilot on a real cross-section before committing to a method
- Schedule waves so the support desk can absorb the sign-in questions
Every integrated application needs re-establishing
Single sign-on integrations, app registrations, service principals and automations authenticating against the source. The list is always longer than the one you are given.
- Enumerate from the source tenant rather than by asking departments
- Some integrations need vendor involvement, which has a lead time
- A number will turn out to serve a process nobody needs any more
Teams does not move as one thing
A team is a group, channels, a SharePoint site, chat history and membership. Files and structure migrate reasonably; private channels, chat history and Planner are the recurring gaps.
- Establish and communicate what will not come across, before cutover
- Chat history is the item users ask about most and expect least
- Rebuild team structure deliberately rather than replicating clutter
Compliance data is lost when source access ends
Legal holds, audit logs, retention and eDiscovery content live in the source tenant. For a divestiture, access to that tenant may end on a contractual date.
- Establish retention obligations before the migration, not during
- Export what must be retained while you still have access
- Involve legal early, since this is their decision rather than IT
The date is usually set by the deal
Mergers, acquisitions and divestitures come with contractual dates and transitional service agreements. The migration schedule is a constraint rather than something you propose.
- Work backwards from the contractual date to find what must be dropped
- Scope reduction is usually the only real lever available
- Agree explicitly what moves later, rather than pretending it all fits
A divestiture is not a merger in reverse
Separating a business out has its own problems: shared content that must be split, mailboxes with mixed history, and defining what the departing entity is entitled to take.
- The entitlement question is legal and commercial, not technical
- Shared document estates rarely split along clean lines
- Plan for a period where neither side is fully self-sufficient
We plan around the domain constraint rather than discovering it.
We sequence the whole project around the pivot
The domain can be verified in one tenant at a time, and that single fact determines the shape of the plan. We build the sequence around it, rehearse the switch, and make sure inbound mail routing is decided for the period around it rather than improvised on the night.
We enumerate integrations from the tenant, not from a list
Asking which applications use single sign-on produces an incomplete answer every time, because departments connect things independently. Enumerating app registrations, service principals and consented applications from the source tenant produces the real inventory, which is what stops a post-cutover application outage.
We treat the device experience as the user-facing project
Users judge a tenant migration on whether their laptop still works on the Monday. The device approach determines that entirely, so we decide it early, pilot it on a genuine cross-section rather than on IT machines, and build the communication plan around what people will actually experience.
We are honest about what will not fit the date
When a transaction sets the deadline, the only real lever is scope. We would rather agree explicitly at the start what moves later than deliver a cutover that technically happened on time and left the business struggling for a fortnight.
Why tenant migrations happen.
Acquisition into a parent tenant
The acquired entity moves into the buyer tenant, usually with a contractual date and a transitional services agreement defining how long the old environment remains available.
GCC consolidation into a group tenant
Common in India, where an entity set up independently is brought into a global group tenant. Frequently combined with an on-premises Exchange migration, which makes sequencing the main design problem.
Divestiture and carve-out
A business unit separating out, which is harder than a merger because shared content has to be split and entitlement to data is a legal question rather than a technical one.
Consolidating tenants created by accident
Organisations that ended up with several tenants through acquisitions, regional autonomy or a shadow signup that grew. Usually driven by security and licensing rather than by a transaction.
Regulatory or residency restructuring
Restructuring so that data sits in a tenant with the right residency and governance position, which is increasingly a live question for Indian entities of global groups.
Rebranding and legal entity changes
A change of legal entity or brand requiring a new domain and a clean tenant, where the migration is a consequence of a corporate decision rather than an IT initiative.
The decisions in a tenant migration, and whose they actually are.
| Decision | Whose decision | When it has to be made | |
|---|---|---|---|
| What the departing entity is entitled to take | Legal and commercial, informed by IT | Before any scoping. Everything else in a divestiture depends on this answer and it is the item most often left until it blocks progress. | |
| What must be retained from the source tenant | Legal and compliance | Before the source becomes inaccessible. Audit logs, eDiscovery content and legal holds cannot be recovered once access ends. | |
| The cutover date and window | The transaction, with the business | Set by the agreement. IT works backwards from it, which is why scope rather than date is the negotiable variable. | |
| What moves now against phase two | Business sponsor, with IT advice | During scoping, in writing. Leaving it implied is how a deferred item becomes a surprise omission. | |
| The device re-registration approach | IT, with the business on timing | Early, since it drives the user communication plan and is what people actually experience. | |
| Target conditional access and compliance policy | IT and security, not replicated by default | During design. A rebuild is an opportunity to fix what accumulated in the source rather than to reproduce it. |
Hybrid Exchange migration against a tenant-to-tenant move.
| Feature | Dimension | On-premises to Exchange Online | Tenant to tenant |
|---|---|---|---|
User identity | The same identity, synchronised | A new object, with nothing carried across | |
The domain | Stays with you throughout | Must leave one tenant before joining the other | |
Coexistence | Full hybrid, mail flow and free/busy shared | More limited, and best kept short | |
Devices | Unaffected | Re-registered or rejoined, visible to users | |
Integrated applications | Largely unaffected | Every one re-established in the target | |
Policy and compliance | Migrated or extended | Rebuilt in the target from scratch | |
What sets the date | You do, within reason | The transaction does | |
Rollback | Per mailbox, reasonably clean | Very limited once the domain has moved |
When the deal sets the date, scope is the only lever you have.
Tenant migrations are almost always driven by a merger, an acquisition or a divestiture, which means the date arrives with the transaction and is not negotiable. Pretending the full scope fits into a fixed window is how these projects produce a bad cutover. The productive conversation is the opposite one: agree explicitly what moves by the date, what moves in a later phase, and what does not move at all. A transitional services arrangement usually gives more room than people assume, and using it deliberately is far better than discovering at the last week that something has to be dropped anyway.
- Work backwards from the contractual date and find the real constraint early
- Agree a phase two in writing rather than leaving it implied
- Historical archives and low-use content are the usual candidates to defer
- A transitional services agreement is a planning tool, not just a legal formality
Five stages, arranged around a single constrained window.
- 1
Assess both tenants and the transaction constraints
Users, mailboxes, file volume, Teams estate, and crucially every integrated application enumerated from the source rather than from a list. Alongside that, the contractual date, the transitional services arrangement and what the business can tolerate in the cutover window.
- 2
Design the target and agree the scope that fits
Identity model, device approach, Teams structure, and the conditional access and compliance policies to be built rather than replicated. Then the honest scoping conversation about what moves by the date and what is explicitly phase two.
- 3
Prepare, pre-seed and pilot
Target accounts provisioned and licensed ahead of time, bulk mail and file passes running well before cutover, integrations re-established and tested, and a pilot group taken through the full experience including the device step, on real machines.
- 4
Execute the window
The rehearsed sequence: final delta passes, domain removal and addition, mail routing switched, accounts activated, devices handled per the chosen approach. A named decision maker present throughout, because judgement calls will be needed and they cannot wait.
- 5
Stabilise, then close out phase two
Concentrated support in the days after cutover when volume spikes, integrations verified in production rather than assumed, compliance data confirmed in the target, and the deferred scope delivered rather than quietly forgotten.
Twelve things to have settled before the domain moves.
Identity and access
- Target accounts created and licensed, ready to activateProvisioned ahead, not on the night
- Every integrated application enumerated from the source tenantNot from a list somebody wrote
- Device approach chosen and piloted on a real cross-sectionThis drives the whole user experience
- Directory synchronisation redirection sequencedWhere an on-premises directory is involved
Content
- Bulk mail and file passes complete, delta pass plannedOnly the delta belongs in the window
- Teams structure agreed, and gaps communicated to usersChat history and private channels especially
- Compliance and legal hold data exported from the sourceWhile you still have access to it
- Shared content split agreed, for a divestitureA legal question before it is a technical one
The window
- Domain removal and addition sequence rehearsedNot improvised on the night
- Inbound mail routing decided for the transition periodMail arrives during the switch regardless
- Conditional access and compliance policies built in the targetRebuilt deliberately, not replicated
- A named decision maker available throughout the windowBecause judgement calls will be needed
Tenant to tenant, answered plainly.
What sits either side of this.
Exchange to Exchange Online
The on-premises path, which frequently runs alongside a tenant consolidation and needs sequencing against it.
Learn moreMicrosoft Entra
The identity platform underneath all of this: single sign-on, conditional access, governance and the model you rebuild in the target.
Learn moreSharePoint permissions cleanup
A tenant migration is the best chance you will get to not carry accumulated oversharing into the new environment.
Learn moreOfficial documentation
- Cross-tenant mailbox migration, Microsoft Learn
- Microsoft 365 for enterprise documentation, Microsoft Learn
Start with the integration inventory and the date.
The two things that determine whether a tenant migration goes well are the real list of applications bound to the source identity, and an honest conversation about what fits the contractual window. Both take days to establish. Remote-first from Hyderabad, serving all of India.
Related Services
Explore more solutions that work great with this service