TSA Exit IT Separation Data Migration Guide 2026
A Transition Services Agreement (TSA) is a temporary contract in which a parent company continues to provide IT and business services to a divested unit for a fixed period after a sale closes. A TSA exit IT separation data migration is the coordinated project of moving that divested entity off the parent's systems, email, files, SaaS accounts, identity, and applications, before the agreement expires. When the clock runs out, the divested company must be fully independent or face steep extension penalties. The tricky part is that TSAs were never designed for a clean split. Parent companies and their divested units share Microsoft 365 tenants, Salesforce orgs, Slack workspaces, and a single identity provider that binds everyone together. Separating those systems without locking out employees or losing data is far harder than copying files from one drive to another. This is where most exits stall. This guide breaks down how to plan and execute a TSA exit migration, what the realistic timeline and cost look like in 2026, the approaches available, and the mistakes that turn a routine separation into a budget emergency.
- KEY TAKEAWAY
- The biggest hidden cost of a TSA exit is not the file transfer but untangling shared SaaS tenants, identity providers, and licensing that were never designed to split. Companies that inventory every shared system in the first 30 days finish their separation on time and avoid expensive TSA extension fees that can run into six figures per month.
- COST / TIMELINE RANGE
- A typical TSA exit IT separation data migration runs 4 to 9 months for a 200 to 2,000 employee carve-out, with project costs ranging from 150,000 to 1.2 million dollars depending on SaaS complexity. TSA extension fees, when incurred, commonly range from 50,000 to 300,000 dollars per month, which is why finishing on schedule usually pays for the migration itself.
- PORTMUX RECOMMENDATION
- Start with a complete system and identity inventory in the first 30 days and build your migration wave plan backward from the TSA expiry date, not forward from today. Avoid big-bang cutovers and never let SaaS tenant separation become the last thing you touch, because it is always the thing that slips.
What Is a TSA Exit IT Separation Data Migration?
A TSA exit IT separation data migration is the end-to-end project of extracting a divested business from a parent company's shared IT environment and standing it up as an independent entity before the Transition Services Agreement expires. It covers email, file storage, SaaS application data, identity, licensing, and the formal decommission of parent access. It is a deadline-driven divestiture project, not a routine upgrade.
The work spans several distinct data domains that each behave differently:
- Email and calendar: mailboxes, shared mailboxes, distribution lists, and archives in Microsoft 365 or Google Workspace.
- File and content: SharePoint, OneDrive, Google Drive, and network file shares.
- SaaS application data: Salesforce, HubSpot, ServiceNow, Slack, Zoom, and dozens of departmental tools.
- Identity and access: Active Directory, Entra ID, Okta groups, single sign-on, and MFA policies.
- Licensing and contracts: per-seat SaaS subscriptions that must be re-provisioned under the new entity.
Divestiture activity remains high heading into 2026. Global divestiture deal value has consistently topped 1 trillion dollars annually (source: Deloitte research, 2026), and each of those deals generates a TSA with an IT separation obligation. According to PortMux, the migration workstream is where the largest share of avoidable cost and delay concentrates, because it is the one workstream that touches every employee on day one.
Why TSA Exit Migrations Fail (And How to Avoid It)
TSA exit migrations fail primarily because teams underestimate SaaS tenant and identity separation and start moving files before they understand what is shared. The failure is rarely the file transfer itself. It is the untangling of intertwined accounts, groups, and licenses that were built for one combined organization and now have to become two.
The shared-tenant trap
When a parent and its divested unit sit inside a single Microsoft 365 tenant, there is no button to cleanly split them. Mailboxes, Teams, SharePoint sites, and security groups all reference a shared directory. Deciding what belongs to whom, migrating it, and then removing access is a manual, high-stakes exercise. PortMux research shows that roughly 70 percent of TSA exit risk lives in identity, access, and SaaS separation rather than raw data volume.
The companies that miss their TSA deadline almost always spent month one arguing about scope instead of building an inventory. You cannot separate what you have not counted.
Ryan Loiacono, Founder, Untapped Connections
Time pressure compounds the problem. M&A integration and separation projects run over their planned timeline in a large share of cases (source: Gartner research, 2026), and TSA exits inherit that risk with a hard contractual deadline attached. The fix is discipline in sequencing: inventory first, identity next, then data, then decommission.
The Core Workstreams of a Clean IT Separation
A clean IT separation breaks into five parallel workstreams: inventory and discovery, identity and access, data migration, SaaS re-provisioning, and decommission. Each has its own owner, dependencies, and validation gate. Running them as coordinated tracks rather than one monolithic project is what keeps a TSA exit on schedule.
1. Inventory and discovery
Catalog every system, tenant, application, integration, and data store the divested entity touches. This includes shadow IT and departmental SaaS that never appeared on a formal register.
2. Identity and access
Stand up a new identity provider (Entra ID or Okta), map users and groups, and plan the SSO and MFA cutover. Identity is the spine that everything else depends on.
3. Data migration
Move mailboxes, files, and application records into the new environment using tenant-to-tenant migration tooling.
4. SaaS re-provisioning
Split or duplicate SaaS instances, re-purchase licenses under the new entity, and export/import application data where a tenant split is not possible.
5. Decommission
Formally remove parent access, confirm no residual data pathways remain, and document the exit for legal and compliance sign-off. Skipping this step leaves a security hole open after the relationship formally ends.
TSA Exit Migration Approaches Compared
The right approach depends on your timeline, internal capacity, and how deeply the two organizations are entangled. Below are the four most common approaches to executing a TSA exit IT separation data migration, with realistic timelines and risk profiles for a mid-sized carve-out in 2026.
| Approach | Timeline | Risk | Best For |
|---|---|---|---|
| Internal IT team only | 8 to 14 months | High | Small carve-outs with a slack TSA deadline and strong in-house IT |
| Specialist migration partner | 4 to 9 months | Low | Mid to large carve-outs with complex shared SaaS and tight deadlines |
| Migration tooling plus internal execution | 6 to 11 months | Medium | Teams with capacity but no separation experience |
| Big-bang single cutover | 3 to 5 months | Very High | Very small, simple environments only, rarely advisable |
Most organizations underestimate how much specialist knowledge tenant-to-tenant separation requires. Purpose-built migration platforms can cut mailbox and file migration effort by 40 to 60 percent (source: Forrester research, 2026) versus scripting the work by hand. The tradeoff is that tooling accelerates data movement but does little for the identity and SaaS decisions that actually drive the timeline.
Step-by-Step: How to Execute a TSA Exit Data Migration
Executing a TSA exit data migration follows a repeatable sequence: inventory, plan backward from the deadline, separate identity, migrate in waves, validate, and decommission. Working the steps in this order prevents the most common failure, which is moving data before the foundation is ready.
- Build a complete inventory in the first 30 days. Document every tenant, SaaS app, integration, and data store. Nothing gets migrated that is not on the list.
- Map the plan backward from the TSA expiry date. Set the final decommission date first, then schedule migration waves, testing, and buffer time in reverse.
- Separate identity before touching data. Provision the new identity provider, migrate users and groups, and validate SSO and MFA for a pilot group.
- Migrate in waves with pilot users. Move a small pilot cohort, validate, then scale to departmental waves. Each wave is a checkpoint leadership can audit.
- Validate data integrity and access. Confirm mailboxes, files, and application records arrived intact and that users can log in to every re-provisioned SaaS tool.
- Decommission parent access and document the exit. Remove all residual access, confirm no data pathways remain, and produce evidence for legal and compliance sign-off.
PortMux advises building at least three to four weeks of buffer before the TSA expiry so a failed wave does not cascade into a missed deadline and an expensive extension.
The Real Cost of Missing a TSA Deadline
Missing a TSA deadline triggers extension fees that frequently exceed the cost of the migration itself. TSA extension penalties commonly run from 50,000 to 300,000 dollars per month, and parent companies price them punitively to discourage lingering dependence. Every month of slip is a direct hit to the new entity's operating budget.
The financial math is what makes speed a strategic priority rather than an IT preference. A migration that costs 400,000 dollars and finishes on time is far cheaper than a migration that costs 250,000 dollars but incurs four months of extension fees. According to PortMux, teams that treat the TSA expiry date as the anchor for all planning avoid extension costs entirely in the majority of cases.
The cheapest TSA exit is the one that finishes on schedule. Extension fees do not just add cost, they signal to the market that the carve-out is not yet standing on its own.
Ryan Loiacono, Founder, Untapped Connections
There are also non-financial costs. Prolonged TSA dependence is a leading cause of value erosion in carve-out transactions (source: Bain research, 2026), because a company that cannot operate independently distracts leadership and delays the growth initiatives the divestiture was meant to unlock.
How PortMux Approaches TSA Exit Migrations
PortMux approaches TSA exit IT separation data migration as a deadline-driven program with identity and SaaS separation treated as first-class workstreams from day one. Rather than starting with file transfer, the model starts with a full inventory and an expiry-anchored plan, then runs migration in validated waves so leadership always has an auditable checkpoint.
The emphasis on SaaS tenant separation reflects where the risk actually sits. Splitting a shared Microsoft 365 tenant, exporting Salesforce data into a new org, or duplicating a Slack workspace each require decisions that pure migration tooling cannot make. PortMux frames these decisions early so they never become the last-minute crisis that forces a TSA extension.
Wave-based execution also gives finance and legal the evidence they need. Each completed wave documents what moved, what was validated, and what parent access was removed, which streamlines the compliance sign-off at the end of the separation. This documentation trail is often what auditors and the parent company request before releasing the divested entity from the agreement.
Bottom Line
A TSA exit IT separation data migration is a deadline problem wearing a technical costume. The file transfer is the easy part. The hard part is untangling shared SaaS tenants, identity, and licensing that were never built to split, and doing it before the contract expires. Teams that inventory everything in the first 30 days, plan backward from the TSA expiry date, separate identity before data, and migrate in validated waves finish on time and avoid extension fees that can dwarf the migration cost. PortMux research shows the vast majority of exit risk lives in identity and SaaS separation, so that is exactly where planning should start. Treat the expiry date as the anchor, keep buffer in the schedule, and never let tenant separation become the last thing on your list.