How to Split a Microsoft 365 Tenant After a Divestiture

When a business unit gets sold, spun off, or carved out into its own legal entity, IT is usually the last team to find out and the first team expected to have it sorted by go-live day. Splitting a Microsoft 365 tenant, that is, pulling a defined set of users, mailboxes, and data out of the parent tenant and standing them up cleanly in a new one, sits right at the center of that work, and getting the data transfer itself right is exactly what a tool like EdbMails Office 365 Migration is built for.

It's a deceptively technical project. The mechanics of moving mail, files, and Teams data are well understood, but the failure points tend to show up in the corners: a domain that won't verify for a few hours, a laptop still tied to the old Intune environment, an Outlook profile that quietly keeps routing replies to the wrong tenant. None of these are exotic problems, but each one generates support tickets exactly when the new entity needs IT working, not firefighting.

This guide walks through what a tenant split actually involves, why companies end up doing one, where it tends to go wrong, and how a dedicated migration tool fits into the plan.

Why Companies End Up Splitting a Tenant

A Microsoft 365 tenant split isn't a routine IT project; it's almost always tied to a business event with its own deadline that IT doesn't control. The most common triggers are:

• Divestitures. A parent company sells a division, product line, or subsidiary, and the buyer needs that unit's users and data separated from the seller's tenant by close date.
• Mergers and acquisitions, in reverse. Sometimes a company that was previously absorbed into a tenant needs to be carved back out, often because a deal unwinds or a unit is being resold.
• Spin-offs. An internal division becomes its own independent company, with its own domain, its own Microsoft 365 subscription, and no ongoing dependency on the parent's tenant.
• Regulatory or compliance separation. In regulated industries, certain business lines sometimes need to be demonstrably separated from the rest of the organization, including at the data and identity level.
• Internal restructuring. Less common, but it happens: a large enterprise decides to split a sprawling single tenant into smaller, more manageable ones along business unit lines.

Whatever the trigger, the IT side of the project looks similar: move a defined population of users and their data into a new tenant while the rest of the organization keeps operating without interruption.

What "Splitting a Tenant" Actually Means

A Microsoft 365 tenant split is a specific flavor of tenant-to-tenant migration: instead of moving an entire organization from Tenant A to Tenant B, you're moving a subset, the users, mailboxes, group memberships, and data that belong to the divested unit, while the parent company keeps operating in the original tenant the whole time.

That "operating the whole time" part is what makes it harder than a full tenant migration. You're not doing a clean cutover for everyone at once; you're surgically separating one part of the organization from another while both keep running, often with a fixed legal closing date that doesn't move regardless of how the migration is going.

What to Sort Out Before Touching Anything

A rushed start is where most of the pain later in the project gets created. Before any data moves, it's worth getting clear, written answers on the following:

• Scope of users and mailboxes. Build the actual list, including shared mailboxes, room and equipment resource mailboxes, and distribution groups that straddle both sides of the split. It's common for a distribution list to contain members from both the divested unit and the parent company; someone has to decide what happens to that list before migration day, not during it.
• Data volume. Get a real number for Exchange mailbox size, OneDrive storage, and SharePoint site collections in scope. This single figure drives your realistic migration timeline more than anything else in the plan.
• Target tenant licensing. Confirm the new tenant's licenses match what users currently have, not a lighter SKU that quietly drops a feature someone depends on (shared mailbox limits, archive mailbox availability, and Teams features are common casualties of a licensing downgrade).
• Calendar visibility needs. Decide early whether people in the new tenant still need to see free/busy information for colleagues staying behind in the old one, since this affects whether you need any kind of organizational relationship configured between the two tenants after cutover.
• Connected apps. Inventory Power Automate flows, custom line-of-business apps, and anything wired into specific SharePoint sites or user accounts. These tend to break silently once the underlying account or site moves, and nobody notices until someone tries to run the flow.
• Migration approach. Microsoft's own cross-tenant mailbox migration capability, built into Exchange Online, can move mailboxes between tenants, but it comes with tenant-level prerequisites, specific licensing requirements, and a fairly narrow scope limited mostly to mailbox data. For organizations that also need to move Teams data, SharePoint, OneDrive, public folders, or archive mailboxes, or that simply want a more straightforward setup with clearer reporting, a dedicated third-party migration tool such as EdbMails Office 365 Migration is usually the more practical route.

How Long Should You Budget for This?

There's no single answer, but a few rough anchors help with planning conversations:

• A department-level split involving a few dozen mailboxes and a modest amount of SharePoint/OneDrive data can typically be planned and executed within one to two weeks, assuming the target tenant and licensing are already sorted.
• A mid-size divestiture, in the low hundreds of mailboxes with several terabytes of file data, more commonly runs four to eight weeks once you include planning, the initial seeding pass, and a buffer for the inevitable pitfall or two.
• A large enterprise carve-out, thousands of mailboxes and a heavy SharePoint/Teams footprint, can extend into several months, mostly because of how long the initial bulk data transfer takes and how much coordination is needed across business units.

The single biggest lever on timeline is almost always data volume, not user count. A small mailbox population with enormous OneDrive archives will often take longer than a much larger population with lean mailboxes.

The Shape of the Migration

At a high level, most tenant splits follow the same arc, regardless of which tool runs the actual data transfer:

1. Stand up the target tenant. New Microsoft 365 tenant, temporary .onmicrosoft.com domain, baseline security configuration (Conditional Access policies, admin roles), and provisioned user accounts.
2. Seed the data while the source stays live. Connect your migration tool to both tenants and run an initial pass. This is where the bulk of mail, files, and calendar history gets copied across, and it can run in the background while the source mailboxes are still being used normally by the people who haven't cut over yet.
3. Run a final delta pass at cutover. Once you're ready to flip the switch, lock down sign-in for the affected users on the source side, run one more pass to catch anything created since the initial seed, then update DNS (MX records) so new mail starts routing to the target tenant.
4. Move the domain. Remove the custom domain from the source tenant, let Microsoft release it, then add and verify it on the target tenant, attaching it to the migrated users' UPNs and primary SMTP addresses.

The detail that catches people out is step four. Microsoft doesn't release a removed domain instantly. There's a real-world gap, sometimes minutes, sometimes a few hours, between deleting it from the source and being able to verify it on the target. Scheduling that step for a low-traffic window, and routing inbound mail through a queuing service during the gap, avoids losing anything sent while the domain is in limbo.

Where Tenant Splits Tend to Go Sideways

A few issues show up often enough across real-world projects to be worth planning for explicitly, rather than discovering them mid-migration.

Devices managed by Intune don't migrate with the data. A laptop hybrid-joined or Intune-managed in the source tenant is tied to that tenant's Entra ID. It has to be unenrolled from the old tenant and re-enrolled in the new one; there's no way to carry the device-level management across as part of the data migration itself. This is also why browser sync data, things like Edge favorites and saved passwords, doesn't follow the user automatically. It's tied to the same per-tenant identity as device management, so a fresh sign-in starts with an empty profile until the user exports and reimports manually.

Outlook can keep routing mail to the wrong place. Even after a profile is rebuilt against the new tenant, Outlook's autocomplete cache can hold onto a legacy routing address from the old environment, which causes authentication errors or misdirected replies. Clearing the cached autocomplete entries, or rebuilding the profile from scratch rather than just re-pointing an existing one, usually resolves it.

Teams 1:1 chat history is awkward to move. Personal Teams chats live in hidden folders inside the user's Exchange mailbox rather than in a clean, exportable format, which is why chat continuity is one of the more fragile parts of a split. If retaining that history is a hard requirement, for legal hold or general continuity, it's worth confirming your migration tool explicitly supports Teams chat and channel migration before you commit to a cutover date, since not every mailbox migration tool covers it.

Shared links break. Anything shared externally from SharePoint or OneDrive in the source tenant won't resolve once the site or file has moved, so those links need to be regenerated and resent from the target tenant after cutover rather than assumed to keep working.

Shared mailbox licensing gets overlooked. Shared mailboxes under a certain size don't require a paid license in most configurations, but project teams sometimes assign full licenses to every migrated mailbox out of caution, then wonder why the new tenant's licensing bill looks heavier than expected. Worth checking against current Microsoft 365 licensing rules before cutover, not after the first invoice.

Distribution groups split awkwardly. A distribution list with members on both sides of the divestiture has no clean default outcome; somebody has to decide whether it gets duplicated, retired, or rebuilt as two separate lists, and that decision tends to get made too late if it isn't flagged during planning.

A Practical Post-Cutover Checklist

Once the domain has moved and people are logging into the new tenant, a short, deliberate follow-up list saves a lot of ad hoc troubleshooting in week one:

• Have users re-register MFA and Authenticator apps against the new tenant.
• Re-share anything that was shared externally from OneDrive or SharePoint before migration, since the old links won't resolve.
• Ask external partners with guest access to remove the old guest account and accept a fresh invite from the new tenant.
• Confirm shared and resource mailboxes are reachable and correctly permissioned.
• Spot-check a sample of migrated mailboxes for folder structure and item counts against the source, rather than assuming a clean migration report means every mailbox looks right.
• Verify Teams channels, files tabs, and any connected apps still resolve correctly for users who've been cut over.

Choosing a Migration Tool for the Data Move

The planning and sequencing above apply no matter what moves the actual data, but the tool you pick determines how much of the heavy lifting is automated versus manual, and how much visibility you have into what's actually happened.

EdbMails Office 365 Migration Software is built specifically around this kind of cross-tenant work, and its Tenant to Tenant Migration capability covers the parts of a divestiture-driven split that tend to eat the most admin time:

• Automatic target mailbox creation and license assignment

  Mailboxes on the new tenant get created and licensed automatically instead of being set up one by one, which matters a lot once you're past a couple dozen users.

• Automatic mailbox mapping

  Source and target mailboxes are matched by display name, username, and email address, with CSV-based custom mapping available for cases that don't fit the default pattern, such as users whose addresses are changing as part of the split.

• Incremental (delta) migration

  Once the initial pass is done, subsequent runs transfer only new or changed items, so a final pre-cutover sync doesn't mean re-copying everything from scratch.

• Built-in throttling management

  Migration jobs pause and automatically resume when Microsoft 365's service-side throttling kicks in, rather than failing outright and needing a manual restart.

• Coverage beyond the inbox, under the Office 365 Migration License

  Shared mailboxes, archive mailboxes, and public folders (with full hierarchy and permissions intact) are all covered alongside primary mailboxes under the same Office 365 Migration License, so the core email-side data doesn't need a separate purchase.

• SharePoint, OneDrive, and Teams, under a separate license

  Moving SharePoint Online sites, OneDrive for Business content, and Microsoft Teams data (including chats and channels) runs through the same EdbMails platform, but sits under its own SharePoint + OneDrive + Teams Migration License rather than the Office 365 Migration License. Worth budgeting for both up front if your divestiture scope includes Teams or file data, not just mailboxes.

• Concurrent mailbox migration

  Multiple mailboxes move in parallel rather than one at a time, which matters when you're working against a fixed legal closing date that won't extend for IT's sake.

• Secure OAuth 2.0 authentication

  Sign-in happens through Microsoft's own login page; the tool doesn't store tenant credentials anywhere.

How a Tenant Split Typically Runs With EdbMails

In practice, running the data side of a tenant split with EdbMails Office 365 Migration follows a fairly predictable sequence:

1. Connect to the source tenant with an account that has the necessary administrative permissions, and load the list of mailboxes in scope for the split, either by browsing the directory directly or importing a CSV of the divested user population.
2. Connect to the target tenant the same way, and let the tool create and license the destination mailboxes automatically rather than provisioning them by hand first.
3. Review and adjust mailbox mapping. The automatic mapping handles the majority of cases; anywhere a user's email address or username is changing as part of the divestiture, the CSV mapping option covers it.
4. Set filters if needed, for example excluding Junk Email and Deleted Items, or limiting the first pass to a date range, then kick off the initial migration. This is the long-running bulk pass and can happen well ahead of the actual cutover date.
5. Run the incremental pass close to cutover, which only moves what's changed since the initial run, keeping the final pre-go-live sync short.
6. Review the migration report for mailbox and item counts before declaring the data side complete, then move on to the DNS, domain, and device steps covered earlier in this guide.

For organizations that also need Teams, SharePoint, or OneDrive data carried over as part of the same project, those workloads run through the same EdbMails platform rather than requiring a second piece of software entirely, which keeps the project from sprawling across multiple vendors and multiple sets of credentials to manage. Just account for the licensing split when scoping the project: mailbox, public folder, and archive mailbox migration fall under the Office 365 Migration License, while SharePoint, OneDrive, and Teams (chats and channels included) fall under the separate SharePoint + OneDrive + Teams Migration License.

Common Mistakes That Quietly Extend the Timeline

A handful of avoidable missteps come up repeatedly across tenant split projects:

• Treating the domain cutover as instant. As covered above, it isn't, and not budgeting for the release delay is one of the most common causes of an unplanned outage window.
• Forgetting devices entirely. Data migration plans frequently cover mailboxes and files in detail and leave device re-enrollment as an afterthought, which then becomes a frantic last step right before go-live.
• Assuming one migration pass is enough. Without an incremental or delta capability, teams either accept stale data at cutover or re-run a full migration that takes just as long as the first pass.
• Underestimating SharePoint and Teams complexity. Mailbox migration is the part everyone plans for; file and chat data is where unplanned delays usually come from.
• Not testing the cutover sequence on a small group first. A pilot batch of a handful of users, run through the entire sequence end to end before the full population, surfaces most of the issues above while the stakes are still low.

Final Note

Splitting a Microsoft 365 tenant after a divestiture is rarely difficult in any single step; it's difficult because there are a lot of steps, several of which depend on timing outside your direct control, like domain release delays or a fixed legal closing date. Getting the planning right up front, and choosing a migration tool that handles the data transfer with minimal manual intervention, turns what could be a chaotic few weeks into a project that's merely demanding rather than genuinely risky.