Migration
Tenant to tenant migration
Tenant to tenant migration merges or splits two cloud identity estates after an acquisition or divestment. The hard constraint is the domain: a domain can only be verified in one tenant at a time, so coexistence is achieved with routing, and the domain move itself is a single scheduled event.
| Fixed price | £95 / $125 per mailbox, plus coexistence setup |
|---|---|
| Typical duration | 6–10 weeks including coexistence |
| Hard constraint | A domain verifies in one tenant only |
| Coexistence | Routing and sharing between estates during transition |
| Identity collisions | Resolved by naming convention agreed up front |
| Domain move | Single scheduled event, not a gradual migration |
Why the domain sets the timetable
Both Google Workspace and Microsoft 365 will only verify a given domain in one tenant. That single fact shapes every merge. You cannot gradually move addresses from one estate to another while both claim the domain; you run coexistence, then you move the domain in one scheduled event, then you finish.
Everything else in the project is arranged around that moment. Mail is pre-synced, calendars are made visible across both estates, directories are synchronised for lookup, and the domain move becomes a controlled cutover rather than a migration in itself.
Identity collisions and naming
Two organisations merging produce duplicate names with predictable regularity, and someone always already has an account in both estates, usually a director or a shared finance address. The naming convention for the merged estate has to be agreed before any account is created, because renaming after the fact breaks every reference to the old address.
We produce a full collision report in discovery: duplicate display names, duplicate addresses, aliases that would collide after the domain move, and groups whose membership overlaps. Each one gets a decision and an owner before any data moves.
- Duplicate display names and addresses across the two estates
- Aliases that only collide after the domain moves
- Groups and shared mailboxes with overlapping membership
- Service accounts and application identities nobody owns
The coexistence period
For a few weeks the two organisations need to behave like one while remaining technically separate. That means mail routing between estates, free-busy calendar lookup across the boundary, and a shared directory for address book lookups. None of it is permanent and all of it is dismantled after the domain move.
Coexistence is where the cost of a merge sits. The mailbox transfers themselves are routine; keeping two estates usefully interoperable while people continue working is the engineering.
Divestments run the same way, backwards
Splitting an estate after a disposal is the same project with the opposite sign. A subset of users, their mail, their files and often a subdomain leave for a new tenant, and the constraint is data ownership rather than identity collision: which files belong to the departing entity, who decides, and what retention obligations follow the data.
We treat the classification decision as yours, made with your counsel. We build the mechanism and evidence trail; we do not adjudicate what belongs to whom.
What we see that others don't say
The binding constraint on almost every tenant merge is not data volume but identity collision: two people with the same name, or one person already holding an account in both estates, and a domain that physically cannot exist in two tenants simultaneously.
What this doesn't cover
- We do not adjudicate data ownership in a divestment; classification decisions are made by you and your counsel.
- Free-busy coexistence between Google Workspace and Microsoft 365 is functional but not feature-complete, and we will say exactly what does not work.
- Historical Teams or Google Chat conversations have no supported cross-tenant migration path.
- Regulated archives are transferred as an evidenced export, not as a live retention system.
Get a fixed price for this
Send your seat count, current platform and deadline. You get a fixed price and an available cutover date, usually within one working day, from the engineer who would run the work.
Prefer to talk? Call +44 20 7183 3436 (Mon–Fri 08:00–18:00 GMT), or message WhatsApp +44 7403 423563.
Questions we get asked
- Can a domain exist in two tenants during a migration?
- No. A domain verifies in exactly one tenant at a time on both Google Workspace and Microsoft 365, which is why merges run a coexistence period and then move the domain as a single scheduled event.
- How long does a tenant to tenant migration take?
- Six to ten weeks including coexistence for a typical mid-size merge. The mailbox transfers are routine; the coexistence period and the identity decisions set the timetable.
- What is the most common cause of delay?
- Identity collisions that were not resolved before accounts were created. Renaming after the fact breaks every existing reference to the old address, so the naming convention has to be agreed first.
How this page is verified
Reviewed by Workspace Migration Services migrations desk, Google Workspace migration engineers. Last checked .
- Single-tenant domain verification behaviour is documented by both Google and Microsoft as of 2026-08-12.
- Per-mailbox pricing reflects the Workspace Migration Services rate card as of 2026-08-12.
Sources you can check
Related pages
- Email migration, any platform to any platform
- What an email migration costs, and why
- G Suite to Office 365, done properly
- Escaping GoDaddy-hosted mailboxes
- Fixed-price email migration, any platform
- Auditing a tenant you have just inherited
- Estimate the transfer window per department
- Exit and data-extraction plan for a divested entity
- Scope a merge or divestment
Merging two estates, or splitting one?
Send the two platforms, the headcount on each side and the deal date. We come back with a coexistence plan and a domain-move date.