TSA exit timeline and the software critical path.

The TSA exit timeline and the software critical path together decide when a carved out business can truly stand alone, because software, not facilities or payroll mechanics, is almost always the longest pole in a separation. Identity, ERP and the contracts that govern them take more lead time than any other workstream, and if they slip the whole exit slips with them.

Why the TSA exit timeline and the software critical path move together

A transition services agreement exists to keep the carved out business running while it builds the capabilities it does not yet have. Most TSA schedules are written around services such as payroll processing, IT support and finance operations. What they understate is that nearly every one of those services depends on software the new entity does not yet license in its own name. The new finance team cannot close the books without an ERP it controls. No one can log in without an identity platform that belongs to the new entity. These dependencies make software the critical path, the sequence of tasks that sets the earliest possible exit date.

Treating the TSA as a fixed runway is the common mistake. The runway is only as long as the time needed to inventory the estate, secure publisher consent, sign standalone contracts, migrate data and cut over, in that order, with identity and ERP leading. Miss the sequencing and the new entity reaches the TSA end date without the contracts or the systems to run independently, which forces an expensive extension on the parent terms.

The workstreams that sit on the critical path

Five workstreams dominate the software critical path, and each has a lead time driver outside the new entity full control. Identity and directory come first, because no access to any system is possible without it. ERP and finance follow, gated by data migration, testing and the need to align with a period end. Publisher consent runs alongside, paced by vendor response times that the new entity cannot compress. Standalone contracting depends on negotiation and procurement approval cycles. Data and integration cutover closes the path, gated by interface rebuilds and parallel running. The table shows what slips if each one is delayed.

Sequencing these workstreams is the core of our carve out and TSA separation service, and it sits inside the broader carve out and TSA software playbook. The contract side draws on re licensing the carved out business from scratch.

The dependencies that make software the long pole

Software sits on the critical path because of how its tasks chain together. Identity has to exist before any other system can be accessed, so it cannot start late. ERP cannot cut over in the middle of a financial period, so its migration window is fixed to a quarter or year end, which removes the flexibility to compress it. Publisher consent has to be granted before a contract can be signed, and the vendor controls the clock. Standalone contracting has to complete before the new entity has any legal right to keep running. Data and integration cutover has to follow contracting, because there is no point migrating into a system the entity is not yet licensed to use. Each link depends on the one before, so a delay anywhere ripples to the exit date.

A short composite illustrates the trap. A buyer separating a distribution business treated the TSA as a flat twelve month runway and planned the software workstreams in parallel, assuming they could all finish together near the end. The identity migration slipped two months waiting on data cleansing, which delayed application cutover, which collided with the only available ERP period end window. The result was a forced TSA extension for two systems at the parent price, a cost that a backward planned timeline would have flagged in the first month.

This is why software, not the more visible services like payroll or facilities, is usually the binding constraint on when a carve out can stand alone. The services depend on the software, and the software depends on a chain of tasks with little slack. Naming software as the critical path early, and resourcing it accordingly, is the single decision that most reliably protects the exit date.

Building a timeline that holds

A reliable TSA exit timeline is built backwards from the exit date through the critical path, not forwards from close. Start with the date the new entity must be independent, then work back through cutover, migration, contracting and consent to find the latest safe start for each. Where the math does not fit the TSA length, the choice is clear early: compress scope, add resource, or negotiate a longer TSA before the deadline turns into a crisis. The publisher consent step is the one most often underestimated, because vendor response times are outside the buyer control and a single delayed consent can hold up an entire cutover.

A timeline only holds if it is owned and reviewed. Each workstream on the critical path needs a named owner, a status reported against the backward planned dates, and an escalation route the moment a date is at risk. Float should be tracked deliberately, because the slack that looks comfortable at close evaporates as consent and migration dependencies compound. The discipline is not complicated, but it is unforgiving. A software separation planned forward from close, without a named critical path and without weekly visibility, tends to discover its problems in the final month, when the only remaining options are the expensive ones.

The same critical path discipline protects against the cost traps covered in stranded software costs in a carve out and the clean TSA exit on software. A timeline with owners and dates is also the document that keeps the seller honest on its TSA obligations.

Continue with carve out day one software readiness and standing up the new entity software estate.