Sequencing an IT separation

In a divestment or demerger, two things are fixed before the technology team hears about the deal: the timetable, and the estate. The completion date is negotiated by people optimising for other things, and the application landscape is whatever twenty years of operation left behind. What remains under your control is sequence — the order in which separation decisions get made and executed. Most of the pain in a carve-out traces back to sequencing it wrong.

Start from the estate, not the org chart

The most common early mistake is to begin with the organisation design — who goes where — and assume systems will follow people. They will not. Applications, data and contracts have their own topology, and it rarely matches the deal perimeter. The first weeks belong to a different question: for every system, data set and vendor agreement, which side of the line does it land on, and what does it drag with it? Until that map exists, every plan is a guess with a date on it.

Day 1 is a minimum, not a destination

The second discipline is Day 1 minimalism. Day 1 is a legal event: two companies must be able to trade, pay people, bill customers, close books and operate safely under separate ownership. It is not the day the separation finishes. Teams that load target-state ambitions onto Day 1 — the new ERP, the cleansed data, the rationalised vendor list — put the deal itself at risk. The separation architect’s job is to define the smallest safe Day 1 position and defend it against improvement.

TSAs are debt — issue them deliberately

Everything deferred past Day 1 lands in a transitional service agreement: one company running systems for the other, for a fee, for a while. TSAs are genuinely useful — they are what makes Day 1 minimalism possible — but they are debt, and they behave like debt. Each one should be issued deliberately: scoped, priced, with an exit plan and an owner, and with the incentive problem faced squarely. The provider has little reason to hurry the exit, and the consumer has other priorities. TSAs without dated, funded exits do not wind down; they calcify into a permanent entanglement that both companies resent and neither is resourced to end.

The order of decisions

Sequencing, then, runs: perimeter first — what lands where, mapped against the actual estate. Day 1 position second — the minimum safe cut, and the TSA set that makes it achievable. Exit plans third, written and funded before Day 1, while the deal still has everyone’s attention. Target state last, owned by each company separately once it is genuinely standalone. Deals get into trouble by running this list backwards — designing end states while the perimeter is still moving, and leaving TSA exits as somebody’s problem for later. Later arrives, and it is expensive.