Two companies, two tenants, one Monday morning
Say a 40-person logistics company buys a 12-person customs broker. The deal closes on a Friday. By Monday the smaller team is supposed to answer mail at the buyer's domain, open the same shared folders, and appear in the same calendar as everyone else. The IT side was never written into the purchase agreement, so it lands on whoever happens to run email.
Everybody calls this a tenant to tenant migration, and the phrase sets the wrong expectation. No tool moves a tenant. What moves is user data, one data type at a time, each with its own tool and its own list of things that stay behind. The work is knowing that list before the deal closes, not during the cutover weekend. We run these moves as a service, and the first hour always goes to the same two decisions.
Decide which tenant survives, and what the domain does
Before anyone opens a console we settle three things: which organisation keeps its identity, where the data has to end up, and which domain people will answer mail at in six months. Those answers set the direction of every copy that follows, and reversing them later means migrating twice.
The domain surprises people, because it moves once and in one direction. On the Google side, a domain that is already a primary domain or an alias on another Google Workspace account cannot simply be added to a second one: Google's help says to remove it from the account that holds it first, and that after a removal it can take up to 24 hours before you can add the domain back, or up to seven days if the account was bought through a reseller. Checked 27 October 2026.
Microsoft draws the same line. Its documentation states that a domain is associated with one Microsoft Entra ID or Exchange Online tenant only, and its cross-tenant mailbox guidance says the primary domain has to be removed from every object in the source tenant before the target tenant can take it over.
So there is no overlap window where both tenants answer for the same domain, which leaves two sane plans. Either the acquired company keeps its domain live in its own tenant while the copies run and the domain moves last, once the mailboxes it serves are already in the surviving tenant. Or everyone gets an address on the surviving domain on day one and the old domain follows later as a secondary domain for inbound mail, with nothing switched off until forwarding is proven. Discovering this rule on cutover night is what turns the project into a lost week.
Google Workspace to Google Workspace: what the tools move
Two Workspace accounts merging is the simpler route, as long as you accept what the built-in import is for. The data import tool in the Google Admin console copies email from another Workspace account: messages, drafts and sent mail, with labels, sublabels and stars carried across. Attachments are skipped when the message plus its attachment goes over 25 MB, so a mailbox full of large files needs a check before the old account is closed.
A super administrator in the target account sets the import up, under Data, then Data import and export, then Data import. You enter the email address of a super administrator on the source account, and only that person can authorise the connection from the link Google emails them. That link expires in 24 hours, and you have to wait 24 hours after sending a request before you can resend it, which is a slow way to lose a day if the named admin is on holiday. Resellers cannot run the import on a customer's behalf. The tool handles up to 1,000 users per import, and the import map that maps source addresses to target accounts is limited to 1,000 source users and 128 MB.
Everything that is not email is a separate job, one route per data type. Above 1,000 source users, Google's product matrix points at Google Workspace Migrate, which runs on Windows servers you host yourself and needs Business Standard or above, or at Domain Transfer, which is not self-service.
| What has to move | Route between two Workspace accounts | What arrives | What you still do by hand |
|---|---|---|---|
Data import tool, Data import and export in the target console | Messages, drafts, sent mail, labels, sublabels, stars | Filters, delegation and vacation replies rebuilt per user | |
| Large attachments | Same import | The message, without the file when message plus attachment exceeds 25 MB | Pull those files out of the source before it is closed |
| Calendars | User-level calendar transfer, or share then re-own | Events on the new owner's calendar | Rooms, resources and appointment pages recreated in the target |
| Contacts | CSV export, CSV import | Personal contacts | The shared directory, which comes from the accounts and groups you create |
| Drive files | Sharing, ownership transfer or the Drive API | Files in the target account | Shared drive structure and membership, designed before anything lands |
| More than 1,000 source users | Google Workspace Migrate, or Domain Transfer with Google | Scope set by the project | A Windows server to host Migrate, on Business Standard or above |
Microsoft 365 to Microsoft 365: the licence, the holds and the one-shot OneDrive move
Two Microsoft 365 tenants merging looks tidier on paper and has more trapdoors. Cross-tenant mailbox migration moves email, contacts, calendar, tasks and notes, but it is not something you switch on in an afternoon.
Three details decide whether the project is viable at all. First, every user you move needs a Cross Tenant User Data Migration licence on top of an Exchange Online licence in the target tenant, and Microsoft's guidance is to apply the licence only after the pre-staged object carries the right ExchangeGUID, because licensing too early provisions a brand new empty mailbox instead. Second, mailboxes on any type of hold are not migrated and the move is blocked for them, so litigation and retention holds have to be found and dealt with in the source tenant before anyone promises a date. Third, each user has to exist in the target tenant in advance as a mail user whose ExchangeGUID matches the source mailbox, carrying the source x500 addresses, with a primary SMTP address in the new organisation and a target address pointing back at the mailbox that is still in the source tenant.
Around all that sits the plumbing: an app registration in the target tenant, admin consent granted by the source tenant, an inbound organisation relationship in the target and an outbound one in the source with mail moves enabled, and a migration endpoint. After a mailbox moves, the source object is converted to a mail user whose target address points at the destination, which keeps mail routing to the person's new home while address books catch up.
Files are a separate exercise with a harder constraint. Cross-tenant OneDrive migration is driven from PowerShell, with Set-SPOCrossTenantRelationship to build the trust and Start-SPOCrossTenantUserContentMove to move each account, in batches of up to 4,000 users. Microsoft is explicit that this is a one-time activity and that incremental or delta passes cannot be performed, and it leaves a redirect at the source. One pass, so the content has to be quiet when it runs. It also fails on read-only OneDrive accounts and on source tenants using Customer Key service encryption, and it is not offered for GCC, GCC High, DoD or consumer accounts.
The cutover hour is the domain move
The order below is our method, not a vendor rule, and it is the part we are usually hired for. The two irreversible steps, the domain change and the single OneDrive pass, sit at the end and cannot be rehearsed on real data.
We copy first and switch last. Mail copies while the old tenant is still the one receiving it, which is why delta passes matter on the Google side and why the Microsoft side needs its pre-staged objects ready early. Authentication is prepared before the MX record changes, not after: SPF on the surviving domain updated to include every sender that will still send for it, DKIM signing with the surviving domain rather than a vendor's, and a DMARC record with a reporting address somebody reads. Then the domain is released on one side and claimed on the other, inside the waiting periods each vendor documents, and only then does MX point at the new home.
The senders nobody remembers are what break the first week after an acquisition, because the acquired company brought its own: an invoicing system, a CRM, a shop plugin, a scanner in a warehouse that still relays through the old provider. Each one has to be authorised to send for the surviving domain or moved off it. If your mail is already landing in spam at the other end after a cutover, start with the authentication records rather than the content.
People, groups and shared drives after day one
The data arriving is not the finish line, and the week after is where an acquisition either settles or stays painful. Shared mailboxes and distribution groups rarely survive a move intact: on the Google side a shared address is a group with its own membership and posting rules, and those get rebuilt rather than copied. Access that lived in one tenant's folder structure has to be re-expressed as shared drives and group membership in the surviving tenant, which is why we design that structure before any file moves, not after.
Keep the source tenant alive and paid for a while. It holds the only copy of whatever the import skipped, it is where the redirect for moved OneDrive accounts still points, and it answers the question somebody asks in week three about a thread from two years ago. Plan the two-factor re-enrolment for the arriving team, confirm each person can sign in and send on the first morning, and keep a short list of what did not come across. We walk through the whole sequence on our tenant to tenant migration page, and the other routes, including hosting and Microsoft 365 sources, sit on the email migration hub.
How Guanacos Tech helps
We run acquisition migrations end to end with the vendors' own tools: decide the surviving tenant and the domain plan, pre-stage the objects and licences, copy mail and files in passes, change MX, SPF, DKIM and DMARC in the right order, then stay on the domain while reputation and routing settle. If you would rather hand that over, that is the job our Google Workspace migration consultants do. Book a 30-minute call with the deal timeline in front of you and we will tell you which steps are irreversible and where the real deadline sits.
Sources
- Google Workspace Help: Import email from a Google Workspace account
- Google Workspace Help: About importing email with the data import tool
- Google Workspace Help: Copy data between Google Workspace accounts
- Google Workspace Help: Google Workspace migration product matrix
- Google Workspace Help: Can't add new domain to Google account
- Microsoft Learn: Cross-tenant mailbox migration
- Microsoft Learn: Cross-tenant OneDrive migration overview
- Microsoft Learn: Migrate mailboxes across Microsoft 365 organizations