M&A and transitions
A divestiture is not complete when the systems move.
Separations are tracked through technical milestones. They succeed or fail on whether the separated business can actually operate on its own.
· 3 min read
Carve-outs and divestitures generate enormous amounts of technical work: tenant separations, application migrations, data extracts, network cutovers, new ERP and HR platforms. It is natural for leadership to track progress through that work. It is also one of the most common reasons separations run long, overspend on transition services, or stumble after Day One.
Moving systems is necessary. It is not the same as being ready to operate.
Where separations actually break
The failure points in a separation rarely sit inside a single workstream. They sit at the boundaries between them:
- Technology and operations. An application migrates on time, but the process that depends on it was never re-owned.
- Seller and buyer. The transition plan follows the seller's timeline, while the receiving organization lacks the capacity to absorb the change.
- Transition services and exits. TSAs are signed with end dates, but the conditions for exiting them are never defined.
- Vendors. Contracts, licenses, and support models separate on different schedules than the systems they cover.
Plan around the receiving organization
A separation plan should be designed around the organization that will run the business afterward, not around the transaction calendar. That means understanding its IT capacity, operating model, and tolerance for disruption before committing to cutover dates. When the buyer's capacity is thin, the risk concentrates there—no matter how well the seller executes.
Evidence, not assertion
The most reliable separations treat readiness as something to be proven. Each Day One or cutover decision rests on defined readiness criteria across business, operations, technology, data, security, people, and vendors—with evidence attached, owners named, and conditions and exceptions tracked to closure. Leadership should be able to show the basis for a go/no-go decision, not just make one.
TSA exits deserve the same discipline. Every transition service needs an exit condition, an owner, and a dependency map—defined early, because extending a TSA almost always costs more than planning its exit.
A divestiture is complete when the separated organization can operate independently—and can prove it.
Questions for the steering committee
- For each transition service, what are the exit conditions—and who owns them?
- Which operational processes change owner at Day One, and has each new owner accepted it?
- What evidence supports the go/no-go recommendation, and where are the exceptions?
- Does the receiving organization have the capacity to run what it is about to inherit?