Decommission from one tenant to become separate tenant

This is a pretty common scenario for university/school district spinoffs — the domain decommissioning piece trips people up more than the mailbox migration itself, so a few things worth adding to what's already been said:

Domain removal has a real sequencing dependency. You can't add a domain to the new tenant while it's still verified/active in the parent tenant — it has to be fully removed from the source first (all UPNs, aliases, and mail-enabled objects referencing it cleared), which usually means a short window where users are on a temporary .onmicrosoft.com address before the domain lands in the new tenant. Worth planning that gap with end users ahead of time rather than letting it surprise them.

OneDrive and SharePoint are the part that actually gets "hairy," as mentioned above — mail and calendars map fairly cleanly tenant-to-tenant, but document libraries, site permissions, and sharing links don't migrate as a byproduct of moving mailboxes. That's usually a separate workstream with its own tooling and timeline, so it's worth scoping that out early rather than assuming it rides along with the mailbox move.

If there's any shared collaboration during the transition (the child entity still needs to coordinate with the parent for a while), it's worth deciding upfront whether you need any kind of free/busy or directory visibility between the two tenants during the cutover window — that's easy to forget until someone notices meetings stop showing availability correctly.

On tooling — alongside the other options mentioned in this thread, EdbMails Office 365 Migration also supports this exact tenant-to-tenant scenario (mailboxes, public folders, archive mailboxes, SharePoint, OneDrive, and Teams data) with incremental/delta sync, so re-running a migration pass after the domain swap doesn't duplicate anything that already moved. Good idea to run a pilot batch with a handful of mailboxes regardless of which tool you land on, just to validate how your specific tenant/domain sequencing behaves before committing the whole org.

Hi,

As for mailbox migration between Office 365 tenants, it is recommended to use a third party tool like CodeTwo Office 365 Migration: https://www.codetwo.com/office-365-migration/. 

The tool has a free trial version available if you would like to give it a try.

Thanks,

Adam

Also, define "other data", Office 365 has a vast array of workloads. Splitting up e-mail is probably one of the easiest, together with OneDrive. Then it gets more "hairy" when you go to Sharepoint and others

https://quadro.tech - https://quadro.tech/autopilot, https://quadro.tech/reporting and https://quadro.tech/migration for Office 365

this includes several steps but in overall:

- Create a new tenant

- How is the identitys created/synced? How do the current setup look! Users in common AD today? Cloud only?

Is their domainname in current tenant - Shall it be moved or replaced?

If moved - the domainname need to be decommissioned in the current tenant then added to the new one

Regarding migration a third-party tool is recommended..There is a few great tools out there - just search for Office 365 migration tools

The DNS records for the domain needs to be setup for the domain(s) used

Will the same DNS provider be used, same domainname or new?

/ Adam