The date on the term sheet is not the date that matters
Every carve-out runs on three clocks, and teams that miss the schedule almost always mistook the first one for the last. Signing starts the planning window. Close is Day 1, when the divested business becomes a separate legal entity that has to invoice customers, pay employees, and answer a phone. Neither of those is separation. Separation happens at the end of the transition services agreement, when the seller stops running systems for a company it no longer owns. Day 1 is a legal event a well-written TSA can carry. TSA exit is an engineering event no amount of legal drafting can carry, and it is where the work lives.
The failure pattern follows from that. A team spends the pre-close period building Day 1 readiness, hits Day 1 cleanly, then discovers in month five that the TSA bought twelve months of running room and nine of them are gone. The remaining work now compresses into a window that also contains a fiscal year end, a vendor negotiation nobody started, and a legal hold nobody checked.
There is a fourth clock the buyer never sees. TSA revenue stops on the exit date but the seller's cost does not. Headcount, licenses, and capacity sized for two companies stay sized for two companies until somebody decommissions them. That stranded cost is the seller's real motive for pushing exit dates in, and it is why extension requests get expensive.
What tends to gate the TSA exit date, ranked by how often it is the binding constraint
Editorial ranking from vendor documentation and practitioner reading. Illustrative ordering, not a measured statistic.
The entanglement inventory, and why the CMDB will not give it to you
The first deliverable is not a migration plan. It is an honest map of where the two businesses touch. Four kinds of entanglement show up, and each needs a different remedy, so grouping them together is how plans go wrong.
Shared instance. One ERP client, one directory forest, one data warehouse, both businesses inside it. The remedy is a split or a rebuild, the expensive one.
Shared reference data. Customer master, vendor master, material master, chart of accounts. You can copy these. You cannot un-share them, because a single record often served both businesses and both sides will keep changing their copy.
Shared integration. An interface both sides depend on and neither side owns. These are the ones that break three weeks after cutover, because the team that wrote them left in a reorganization two years ago.
Shared contract. One enterprise agreement, one support contract, one cloud commitment covering both populations. That remedy is commercial, and it runs on the vendor's calendar rather than yours.
Configuration databases are the natural place to start and the wrong place to start. A CMDB records what someone entered when a system was commissioned. It rarely records what was retired, and it almost never records the small integrations carrying real business traffic. Two ledgers are more accurate because money keeps them current. The accounts payable ledger names every system somebody is still paying for, which is a better application inventory than the one IT maintains. The cost allocation schedule shows which entity has been absorbing the cost, which is the argument you are about to have about who owns what.
Count integrations, not applications. The application count is comforting and nearly useless for scheduling. The integration count, every point where data crosses between the two businesses, is the schedule. A 400-application estate with 60 cross-boundary interfaces separates faster than a 120-application estate with 300 of them.
Identity is the root dependency
Almost nothing else can move until identity moves. Single sign-on, email, file access, remote access, device management, and every SaaS application provisioned through the directory hang off it. A plan that sequences identity late has sequenced everything late, and the discovery usually comes in month three when the first migration stalls waiting for accounts that do not exist yet.
Two strategies are in play. Coexistence keeps users on the seller's identity through part of the TSA period, with cross-tenant access letting divested users reach their new systems. It is gentler on users and defers the hardest cutover, which also defers the learning. Day 1 identity gives the divested business its own directory and login names at close, making every later migration a move into a home that already exists. The second is more work up front and shorter overall, and the right default when the TSA runs under a year.
Email domains force part of the decision. A verified domain lives in one tenant at a time, so whoever keeps the parent domain decides whose users change address. Settle it in the first month, because customer-facing addresses, marketing automation, certificates, and every service account that sends mail inherit that choice.
Read the migration tooling's documented limits before you promise a date
Microsoft publishes what its cross-tenant tooling does and does not do. Several of the constraints are hard blocks rather than performance considerations.
Holds block migration outright. Microsoft's cross-tenant mailbox migration documentation states that mailboxes on any type of hold are not migrated and the move for those mailboxes is blocked. OneDrive is the same: accounts with a hold policy applied are blocked, and the documented remedy is to remove the hold, migrate, then reapply it on the target. Removing a legal hold to hit a migration date is a decision for counsel, and asking that question in month nine is how a cutover slips a quarter.
Mailbox migration is lossy by design and irreversible. Microsoft states that only user-visible content is migrated, meaning email, contacts, calendar, tasks, and notes, and that after a successful migration the source mailbox is deleted so it is not available, discoverable, or accessible in the source tenant. Anything needed for e-discovery is preserved before the move, not after.
OneDrive moves are one-and-done. The documentation is explicit that incremental and delta migration passes cannot be performed. That makes the cutover a genuine cutover rather than a sync-then-switch, so freeze windows are mandatory and the batching plan has to be right the first time. Up to 4,000 accounts can be queued at once, each capped at 5 TB or one million items, and the full path is limited to 400 characters, which quietly fails migrations when a long target URL meets a deep source folder structure.
Target-side provisioning breaks the move. If a user signs into the target tenant and their OneDrive site gets created before the migration, the migration fails and the existing site cannot be overwritten. Restricting site creation in the target tenant is a prerequisite, not a cleanup step. Purview Customer Key service encryption on the source also causes the migration to fail.
Licensing is a gate. Cross-tenant user data migration requires a per-user add-on license, assignable on either the source or target object, and Microsoft states plainly that migrations fail without it and no exceptions are offered. That is a procurement line item that has to exist before the technical work starts.
Government cloud changes the plan entirely. Cross-tenant OneDrive migration is documented as not supported for GCC, GCC High, or DoD, and cross-cloud tenant-to-tenant migration, such as worldwide to a government cloud, is not supported either. If the carved-out business runs in a government cloud, the native path does not exist and the design has to start from that fact rather than discover it.
Sequencing follows from the dependencies Microsoft documents. Teams content depends on Exchange mailboxes, so mailboxes move before or alongside Teams. OneDrive and SharePoint share a permissions model and move together. Any phased approach also owes users mail routing between tenants, calendar free/busy sharing, and Teams federation, each of which has to be built and then torn down.
Five separation patterns, and where each one wins
Every system gets one pattern. Making that assignment system by system, with a named owner and a stated reason, is most of the planning value. Applying one pattern to the whole estate is the most common design error.
| Pattern | How it works | Where it wins | Where it fails |
|---|---|---|---|
| Clone and cleanse | Copy the whole system, point it at the new entity, delete the records that belong to the seller | Heavily customized systems where the process is the asset and re-implementation would take longer than the TSA | Deletion is never complete. Residual data creates a privacy and confidentiality exposure that has to be proven closed |
| Greenfield plus data migration | Stand up a clean instance sized for the divested business, migrate master data and an agreed history window | When the divested unit is much smaller than the parent, or the parent's configuration carries obligations the buyer does not want | Underestimating history. The buyer wants years of transactions and the design assumed months |
| Lift the instance | The system moves with the business because the business is effectively its only user | Unit-specific applications, plant systems, product engineering environments | Licenses, hosting contracts, and support agreements do not move as easily as the software does |
| Extended TSA, then rebuild | Seller keeps running it, buyer builds a replacement on its own schedule | Systems where the buyer intends a different product anyway, so migrating twice is waste | The rebuild competes with everything else the new IT organization is doing, and extension pricing escalates |
| Reverse separation | The divested unit keeps the system and the seller migrates off it | When the carved-out business is the historical system owner | Seller-side program governance rarely expects to be the one migrating, so it gets funded late |
Data: what goes, what stays, and what both sides need
The first two buckets are easy to execute. The third generates disputes for years, and it is a records problem wearing a technology costume.
Start by naming, per data domain, who is the controller after close, who answers a regulator, and who honors a deletion or access request from an individual. A TSA in which the seller keeps operating a system holding the buyer's personal data makes the seller a processor for that data. Under GDPR Article 28, processing by a processor has to be governed by a binding contract, and Article 28(3)(g) requires the processor, at the controller's choice, to delete or return all the personal data at the end of the provision of services and to delete existing copies unless law requires storage. That is exactly the TSA exit obligation, so the processor terms and the exit criteria should be written as one thing rather than two documents that disagree.
Legal holds outlive the deal. A record under hold cannot be deleted from the source because the TSA ended, and the hold may attach to custodians who now work for the other company. Inventory holds at signing, map them to the systems in scope, and put the disposition of held data into the purchase agreement schedules rather than leaving it to the migration team.
History is a negotiation, not a technical parameter. The buyer's finance team wants enough transaction history to run comparatives, close the first year, and defend an audit. The seller's counsel wants to hand over the minimum defensible set. If engineering is not in that room, it gets settled at a number that turns out to be unbuildable or unnecessary.
Contracts and licenses set the schedule, not the servers
Enterprise software and cloud agreements commonly restrict assignment and carry change-of-control terms. The practical consequence is that a divested business usually cannot inherit a license because the deal happened. Every material agreement resolves into one of three outcomes, and each has a different lead time.
Assign. The contract moves to the new entity with the vendor's consent. Cheapest when it works, and entirely dependent on a counterparty with no deadline of its own.
Split. The vendor writes a new agreement for the divested volume. This is a price event, not a paperwork event. A unit that consumed fifteen percent of an enterprise agreement does not get fifteen percent of the enterprise discount as a standalone buyer, and the new run rate belongs in the standalone cost model before close.
Replace. A different vendor entirely, which means a selection, an implementation, and a migration inside the TSA window.
The sequencing rule that saves the most time: open the vendor consent workstream at signing, before the technical design is finished, because the answers change the design. And do not start a strategic vendor negotiation in the final quarter of the TSA. The transaction is public, the exit date is inferable, and a vendor that can read your deadline prices accordingly. Approach the vendors that matter while you still have the option of walking to a competitor.
Writing a TSA that can actually be exited
A TSA is an operating document engineers have to work from for a year or more. Most of them are written by people who will not be operating them.
Define services at the system level. One line item called "IT services" cannot be exited, because there is no observable state in which it is done. Each service needs a name, an owner on each side, a unit of consumption, a price, and an exit test.
Write exit criteria as observations, not adjectives. "Identity separated" is unfalsifiable. "All buyer users authenticate against the buyer's identity provider, and the seller has revoked buyer access to the source tenant" is a state two people can confirm on a call.
Price extensions on an escalating schedule. Flat extension pricing makes staying cheaper than leaving, and the buyer's other priorities win every time. An escalator funds the seller's stranded cost and creates the shared urgency flat pricing removes.
Do not forget the reverse TSA. The seller frequently needs things from the divested business: a plant system, a support function, historical lookups, a specialist who went with the unit. The deal narrative runs one direction, so these get discovered late and priced badly.
Name people, and fund backfill. The constraint on TSA delivery is seller-side staff who already have full-time jobs. A schedule that assumes their availability without funding it is built on volunteering. Name individuals in the service definitions and pay for the coverage behind them.
Separation sequence, and what has to be true before the next step starts
When the business touches federal contracts or export-controlled work
A carve-out that includes government contracts adds approvals that run on the government's clock. They are mechanical, documented, and unforgiving about sequence.
Novation. Under FAR 42.1204, and the anti-assignment statute at 41 U.S.C. 6305, the government may recognize a successor in interest when a third party's interest arises from the transfer of all the contractor's assets, or the entire portion of the assets involved in performing the contract. A novation is not needed when ownership changes through a stock purchase with no legal change in the contracting party, which is why deal structure drives the workload here. The sentence that should govern the schedule is FAR 42.1204(c): if the government does not recognize the transfer, the original contractor remains under contractual obligation and the contract may be terminated for default.
The package is a data extraction problem. FAR 42.1204(e) requires three signed copies of the proposed novation agreement plus the transaction document, a list of all affected government contracts showing contract numbers, contracting offices, total values, and unpaid balances, and evidence of the transferee's capability to perform, along with authenticated transfer instruments, corporate resolutions, an opinion of counsel, and balance sheets. That contract list comes out of the same financial systems being separated. If the ERP split breaks the link between contract number and unbilled receivable, the novation package is late for a reason that started as an IT design choice. Under FAR 42.1203 the contracting officer also notifies affected offices and requests comments, typically on a 30-day cycle.
Registrations are per entity. A newly formed entity needs its own SAM registration and its own unique entity identifier. FAR 4.1102 requires offerors and quoters to be registered in SAM at the time an offer or quotation is submitted, with narrow exceptions, so any bid the divested business plans for its first quarter depends on a registration started well before Day 1.
Export control has short fuses. Under 22 CFR 122.4, a registrant must notify the Directorate of Defense Trade Controls within five days of changes including name, address, legal organization, ownership or control, the establishment or acquisition of subsidiaries, and the composition of the board or senior officers. Any intended sale or transfer to a foreign person of ownership or control requires notice by registered mail at least 60 days in advance. Registration is per entity, filed on the DS-2032 and signed by a senior officer, and 22 CFR 122.2 states that registrants may not establish new entities to reduce registration fees.
The CUI boundary changes on Day 1. A shared enclave becomes two enclaves, or one enclave inside a tenant the divested business no longer controls. Assessment results are entity-specific, so the boundary and the score are re-established rather than inherited. DFARS subpart 204.75 requires a contractor to hold the CMMC status specified in the solicitation at time of award and maintain it through performance, via clauses 252.204-7021 and 252.204-7025. Through November 9, 2028 it applies where the program office or requiring activity determines a specific level is required; from November 10, 2028 it applies wherever contractor information systems process, store, or transmit federal contract information or controlled unclassified information. One live wrinkle: 32 CFR 170.14 sets CMMC Level 2 requirements identical to NIST SP 800-171 Revision 2, while the current NIST publication is Revision 3, issued May 2024. Scope against the revision the contract cites.
The Day 1 minimum, and the second wave nobody plans
Day 1 does not require a finished IT estate. It requires a short list of things that must work because their absence is visible outside the company.
- Employees can log in, get paid, and be reached at an address customers can use.
- The company can invoice, receive cash, and pay suppliers through banking connectivity registered to the new legal entity.
- The books can be closed for the first period under the new entity, with an audit trail that starts on Day 1.
- Orders can be taken and product can ship, including any trading-partner interfaces with their own onboarding lead times.
- Security operations have coverage, with a named party monitoring, an incident process, and a defined escalation path across both companies.
- Regulatory identifiers exist: tax registrations, entity registrations, and any licenses required to operate on Day 1 rather than in month three.
The second wave arrives around month four and it is always the same list. Reports that quietly queried the seller's warehouse. Interfaces allow-listed against the seller's IP ranges. Service accounts, API keys, and certificates issued in the parent's name that no application team knew it depended on. Scheduled jobs owned by a departed employee. Trading-partner identifiers and bank connectivity that need the counterparty to act on their own timeline, discovered when a payment fails. Machine identity is the long tail of every separation, and the way to shorten it is to inventory non-human credentials before close, while one team still sees both sides.
Bottom line
A carve-out separation is a sequencing problem with a legal deadline attached. The order that works is stable: map the entanglements from the ledgers rather than the CMDB, move identity first, assign a pattern per system with a named owner, open vendor consents at signing, write TSA services with exit tests you can observe, and treat records, holds, and registrations as engineering inputs rather than legal afterthoughts. The tooling constraints are published and specific, and reading them before committing to a date is cheaper than meeting them inside a freeze window. Day 1 is the easy milestone. Build for the exit.
Frequently asked questions
Day 1 is the close, when the divested business becomes a separate legal entity and has to operate. Most of that can be carried by the seller under a transition services agreement, so Day 1 is achievable without much having been separated. TSA exit is when the seller stops providing those services, which requires the divested business to be running on its own systems. Day 1 is the legal milestone; TSA exit is the engineering milestone that sets the program's real schedule.
It depends on structure. FAR 42.1204 allows the government to recognize a successor in interest when the transfer covers all of the contractor's assets, or the entire portion of assets involved in performing the contract. A novation is unnecessary when the change is a stock purchase with no legal change in the contracting party. Where one is required and the government declines to recognize the transfer, FAR 42.1204(c) leaves the original contractor obligated and the contract subject to termination for default.
Holds. Microsoft documents that mailboxes on any type of hold are not migrated and the move is blocked, and that OneDrive accounts with a hold policy are also blocked. Other documented hard stops: missing cross-tenant user data migration licenses, a pre-existing OneDrive site in the target tenant, Purview Customer Key encryption on the source, the 400-character path limit, and the 5 TB or one million item cap per account. Cross-cloud moves are not supported.
Clone and cleanse is a legitimate pattern and often the fastest route for a heavily customized system. The obligation it creates is proof. Deletion in a large ERP is rarely complete on the first pass, because data lives in archives, attachments, reporting layers, and backups. Treat residual data as a confidentiality exposure with a documented closure test, and agree in the purchase agreement who pays for remediation if residue is found later.
On an escalating schedule. The seller's cost base does not fall when a service ends, so flat pricing makes staying cheaper than leaving and the migration loses to whatever else the new IT organization is doing. An escalator gives both sides a reason to hit the date. Pair it with per-service exit tests written as observable states, so an extension is a decision about one named service rather than a blanket slip.