The transaction is signed. The transition services agreement (TSA) has an end date. And you own the part nobody negotiated in detail: how one Microsoft 365 tenant becomes two without either business stopping. The buyers and lawyers settled the deal. The separation of identities, data, and workloads landed on IT, with a contractual clock already running.

Most carve-out separations do not fail because the migration is slow. They fail because an undocumented dependency surfaces after the clock has run out: a shared mailbox nobody claimed, a line-of-business integration wired to the parent tenant, a retention hold that spans both companies. This page lays out how a Microsoft 365 carve-out migration is sequenced so those dependencies surface early, while you can still do something about them.

Quick Answer

A carve-out migration is sequenced by dependency, not by data volume. Establish what legally transfers, stand up the destination tenant and identity first, then move mail, files, and line-of-business integrations in the order that keeps the divested unit able to operate. Close the transition services agreement only when the receiving side can run without the parent. The failure mode is not slow migration. It is discovering an undocumented dependency after the clock has run out.

What a Transition Services Agreement Actually Obligates IT To Do

A transition services agreement is the contract that keeps the divested unit running on the parent’s systems for a fixed period after close, while the separation happens underneath it. For IT, the TSA is not a legal document to interpret. It is a scope of work with a deadline attached. Reading it as an engineer means answering three questions: what services must the parent keep providing, to whom, and until when.

Translate each obligation into an IT task. “The seller will provide email services to the divested business” becomes a mailbox inventory, a routing plan, and a cutover date. “The seller will maintain access to shared document repositories” becomes a permissions map and a data-transfer sequence. Every clause that mentions a system the divested unit touches is a dependency you now have to trace, migrate, and prove severed.

Cost drivers, not figures, are what set the price of a TSA period. The longer the parent has to keep running services for a business it no longer owns, the more the arrangement costs both sides, and the more operational risk sits in the seam between two organizations. Scope of what transfers, the depth of shared dependencies, and the length of the contractual window are the levers that move that cost. i3 does not publish TSA figures, and no honest one exists, because they vary entirely by deal.

The practical takeaway: read the TSA as a punch list, date every obligation, and work backward from the exit date. The agreement defines “done.” Your sequence has to reach it before the clock does. This page describes what such agreements typically obligate; it is not legal advice, and contract interpretation belongs with your counsel.

Deciding What Transfers: Data Ownership, Retention, and Records

Before a single mailbox moves, the separation needs a defensible answer to a harder question: what actually belongs to the divested unit. In a shared tenant, entitlement is rarely clean. Documents were co-authored across divisions. Distribution lists mix people who are leaving with people who are staying. Retention policies and legal holds were written for the combined company and do not know a divestiture is happening.

Three forces collide here, and they have to be reconciled deliberately rather than in the rush of a cutover:

  • Entitlement. Which data the divested unit is contractually entitled to take, versus data that references the parent and must stay or be redacted.
  • Retention and legal holds. Records the combined entity is obligated to preserve. A hold that spans both organizations does not dissolve because ownership changed, and copying held data to a new tenant without preserving its status can break the obligation.
  • Shared history. Threads, files, and sites with mixed authorship, where a clean split is a judgment call rather than a query.

Document the decision, not just the result. For each contested data set, record who decided, on what basis, and what was moved, retained, or excluded. That provenance is what makes the separation defensible if either side is questioned later, and it is the artifact that lets you prove the boundary held.

Identity First: Why the Separation Sequence Starts With Accounts

Identity is the foundation everything else stands on, which is why it moves first. Mail, files, and applications all resolve back to accounts. If the divested unit’s users cannot authenticate in the destination tenant, nothing you migrate afterward is usable to them. So the sequence starts with directory, authentication, licensing, and access, engineered so the divested unit’s people can sign in and work on day one.

That means standing up the destination tenant’s directory, deciding how identities are created there, mapping licensing so the right people have the right Microsoft 365 plans at cutover, and re-establishing access to the resources that follow. Get this wrong and the visible symptom is not a migration error. It is a person who cannot log in on the morning the TSA expected them to be working.

People move in a divestiture, and the identity workstream is where that shows up for IT. Keep the scope strictly to accounts, authentication, and access: who needs an identity in the new tenant, what they can reach, and when their access to the parent is removed. Questions about employment, headcount, or HR treatment sit outside this scope and belong with the people who own them. IT’s job is that the right accounts exist, resolve, and are cut over on schedule, and that access to the parent ends cleanly when it should.

Moving the Workloads Without Stopping Either Business

With identity established, the workloads move in dependency order: mail, files, sites, and the integrations that quietly bind the two organizations together. Volume is a scheduling detail. Dependency is what dictates sequence. A small line-of-business integration wired to the parent tenant can strand a whole department if it is cut before its replacement is ready, while a large but self-contained mailbox archive can move late without consequence.

The integrations are where carve-outs get dangerous, because they are the least documented and the most load-bearing. A SharePoint site that feeds a reporting tool. A Power Platform flow that reads from a shared list. A connector that authenticates against the parent’s directory. Each is a thread running between the two organizations, and each has to be found, re-pointed at the destination tenant, and verified before the corresponding TSA service is switched off. The ones you do not find are the ones that fail on exit day.

Continuity through a corporate transaction is achievable when the integration surface is mapped before anything is cut. i3 built a corporate SharePoint portal for a professional services firm that had just acquired another company, integrating the new organization into a shared platform while day-to-day operations kept running throughout. That work proves continuity can be engineered through a transaction, not that separation is the same problem, so treat it as evidence for one claim only: the integrations that bind two organizations can be re-homed without stopping the business, if you find them first. You can read that professional services firm case study for how the integration was handled.

Big Bang Versus Phased Separation

The honest question is not which approach is safer in general. It is which one your deal actually allows. A single cutover, where the divested unit moves off the parent tenant in one coordinated event, genuinely wins under specific conditions:

  • The divested unit is small and self-contained, with few integrations crossing into the parent.
  • The dependency map is complete and trusted, so there is little risk of an undocumented thread surfacing mid-cut.
  • The TSA window is short or expensive enough that a long coexistence period costs more than the risk of a single event.
  • Both sides can absorb a defined downtime window for the cutover itself.

A phased separation wins when the opposite holds: a dense or poorly documented integration surface, a larger user base that cannot all cut over at once, or a TSA window long enough to sequence the move in stages and validate each before the next. Phasing buys you the ability to discover a missed dependency on a workload you have not cut yet, instead of on all of them at once.

The wrong reason to choose a big bang is a deadline that feels close. Compressing a poorly mapped separation into a single event does not remove the undocumented dependencies. It just guarantees you meet them all on the same day. Choose the single cutover because the map says you can, not because the calendar says you must.

If your situation is the reverse of a carve-out, two companies combining rather than one separating out, the sequence and the coexistence mechanics are different. See managing dual-tenant Microsoft complexity after a merger or acquisition for that scenario.

Exiting the Agreement: What Done Looks Like

The transition services agreement ends on its date whether or not you are ready, which is why “done” has to be defined as evidence, not as a feeling that the migration is mostly finished. Exit criteria are the checklist that proves the receiving side can run without the parent, and every item on it should be something you can demonstrate.

Concretely, exit readiness means: every user authenticates in the destination tenant and no longer depends on the parent’s directory; mail, files, and sites the divested unit is entitled to are moved with their provenance intact; every integration that crossed between the organizations is re-homed and verified; retention and hold obligations are preserved in their new location; and access to the parent’s systems is removed on schedule so nothing is quietly still running on the seller’s dime or inside the seller’s compliance boundary.

The dependencies people forget until the parent switches them off are almost always the same shape: a service account, a shared mailbox, a scheduled job, or an integration that was never on anyone’s inventory because it just worked. The exit checklist is where those surface, if you built it from the dependency map rather than from optimism. When every criterion is evidenced, the agreement can close cleanly, and the divested unit stands on its own.

Key Takeaways

  • A carve-out migration is sequenced by dependency, not by data volume. The order that keeps the divested unit operating is the order that matters.
  • Read the transition services agreement as a dated IT punch list and work backward from its exit date.
  • Decide what transfers before you move anything, and record who decided and why so the separation is defensible.
  • Identity moves first, because everything else resolves back to accounts. Users must authenticate in the destination tenant on day one.
  • Undocumented integrations are the real failure mode. Find and re-home every thread between the two organizations before the matching TSA service is switched off.
  • Choose a single cutover only when the dependency map says you can, never because the deadline feels close.
  • Define “done” as evidenced exit criteria, so the agreement closes cleanly and nothing keeps running on the parent’s dime or inside its compliance boundary.

Frequently Asked Questions

What is a transition service agreement?

A transition services agreement (TSA) is the contract that keeps a divested business running on the seller’s systems, including its Microsoft 365 services, for a fixed period after the deal closes. It gives IT time to separate identities, data, and workloads into a destination tenant while the divested unit keeps operating. For IT it functions as a scope of work with a hard end date: a list of services the parent must keep providing, and to whom, until the separation is complete.

What does TSA mean in divestiture?

In a divestiture, TSA stands for transition services agreement, not the airport agency of the same acronym. It is the mechanism that prevents the divested business from going dark the moment the deal closes. The seller continues to provide agreed services, such as email, file access, and identity, for a defined window, and the divested unit uses that window to stand up its own environment and move off. The agreement defines both what continues and when it must stop.

What is separation in M&A?

Separation is the operational work of pulling a divested business unit out of the parent organization so it can run independently. In a Microsoft 365 context that means untangling shared identities, data, sites, and integrations from a single tenant and re-establishing them in a destination tenant the divested unit controls. It is the opposite of integration: instead of combining two estates, you are proving that one can operate with no dependency on the other by the time the transition services agreement ends.

What happens to contracts when a business is sold?

From an IT separation standpoint, the contracts that matter are the ones that govern systems and data. Software licensing, service agreements, and the transition services agreement itself determine what the divested unit is entitled to take, what must be re-provisioned under new agreements, and what access to the parent’s systems ends and when. The transition services agreement is the bridge that keeps services running while those arrangements are re-established. Interpreting the terms of any specific contract is a matter for legal counsel, not IT.

How long does a divestiture take?

It varies by deal, and any single duration stated as fact would be misleading. What sets the timeline is not a standard schedule but the specifics of your separation: the scope of what transfers, the depth of shared dependencies between the two organizations, and the contractual end date in the transition services agreement. A small, self-contained unit with a clean dependency map separates far faster than a large business with dense, poorly documented integrations. The honest answer is that the TSA end date sets the ceiling, and the dependency depth sets how much of that window you actually need.

Request a Microsoft 365 Consultation to scope your carve-out separation before the transition services clock runs down.