Mapping software dependencies before a carve out.

Mapping software dependencies before a carve out is the discipline of recording every license, identity, data flow, integration and shared platform the unit being sold relies on, before a single contract is signed, so the separation plan rests on evidence rather than assumption. A carved out application is almost never self contained. It draws on the parent directory for identity, the parent finance system for postings, a shared data warehouse for reporting and a web of integrations that make it useful. Miss one of those threads and the separation stalls at cutover, when the application keeps running but the flows around it break.

Why mapping software dependencies before a carve out matters

The cost of a carve out is driven less by the headline applications than by the dependencies between them. A finance system can be transferred in principle, but if it posts to a general ledger that stays with the parent, the interface has to be rebuilt before the new entity can close a period. An application can be re licensed, but if its users authenticate through the parent directory, every account has to be migrated to a new tenant before access can be cut over. These dependencies are invisible on a contract list and only appear when someone traces the actual data and identity flows. Mapping them first is what turns a separation from a series of surprises into a sequenced plan.

Dependencies also drive the transition services agreement. Every service the parent has to provide after close exists because a dependency could not be severed by day one. The longer the dependency list, the longer and more expensive the TSA, and the more exposure the new entity carries while it relies on the parent. A thorough dependency map is therefore the foundation of both the separation timeline and the TSA scope, and getting it wrong inflates both.

What a complete dependency map captures

A useful map records five dependency types for the carved out estate. License and contract dependencies capture who owns each entitlement, the metric it is counted on and whether an assignment or change of control clause gates a transfer. Identity and access dependencies capture the directory, single sign on and service accounts every application relies on. Data flow dependencies capture each interface by source, destination, frequency and owner. Infrastructure dependencies capture hosting, network and shared platforms. Operational dependencies capture the support contracts, run teams and runbooks that keep the estate alive. The table below sets these out with the separation impact of each, which is what converts the map into a work plan.

The diagram makes the shape of the problem visible. The carved out application at the centre is connected to identity, finance, the data warehouse, the integration bus and shared infrastructure. Each of those connections is a thread that has to be cut and re tied to the new entity, and the order in which they are cut determines whether the separation holds. Identity and data flows usually carry the longest lead time, which is why they sit early on the software critical path.

Turning the map into a separation plan

A dependency map is only valuable if it drives the plan. Once the threads are recorded, each one becomes a workstream with an owner, a lead time and a place in the sequence. Contracts with assignment clauses move first, because publisher consent is outside the buyer control and can hold everything behind it. Identity migration follows, because access has to exist before data and applications can cut over. Data interfaces are rebuilt against the new entity systems, infrastructure is migrated or stood up fresh, and operational knowledge is transferred before the TSA ends. This sequencing is the backbone of carve out day one software readiness and the TSA exit timeline and software critical path.

The map is also where audit and cost exposure first becomes visible. A dependency on a parent enterprise agreement that does not transfer is both a licensing gap and a future audit risk, the same exposure described in separating shared software licenses. Mapping is part of our carve out and TSA separation service and the wider carve out and TSA software playbook.

Common dependencies buyers miss

Certain dependencies are missed again and again. Service accounts and machine identities rarely appear on any inventory yet hold integrations together, and they fail silently when the directory changes. Reporting pipelines that feed a shared data warehouse are forgotten until month end, when the new entity cannot produce its first standalone accounts. Embedded third party components inside an application carry their own licenses that may not transfer with the host. And shared platform agreements, where one contract covers many applications, hide the fact that pulling one application out leaves the rest on a contract sized for a business that no longer exists. A disciplined map surfaces all of these before they become day one failures, which is exactly why the mapping work comes first.

How to build the dependency map in practice

Building the map is a structured exercise, not a one off interview. Start from authoritative sources rather than memory. Configuration management databases, discovery and inventory tooling, network flow logs and integration platform catalogs reveal connections that no single person remembers. Pair that machine evidence with structured conversations with application owners, who know the business context the tooling cannot see, such as which interface feeds the regulatory report or which batch job has to finish before the warehouse opens. The combination of automated discovery and owner knowledge is what produces a map that is both complete and meaningful.

Record each dependency in a single register with a consistent structure, so the map can be filtered, sorted and turned into a plan. For every entry capture the source system, the target system, the dependency type, the owner on each side, the lead time to sever it and the place it sits in the sequence. A register built this way doubles as the master tracker for the separation, because each row becomes a task with an owner and a date. Keeping the map and the plan in one artifact prevents the common failure where a dependency is mapped, then forgotten because it lived in a document no one revisited.

Validate the map before relying on it. The fastest validation is to trace a few critical business processes end to end, following an order from entry to cash or a hire from onboarding to first pay, and checking that every system and interface the process touches appears on the map. Gaps found in that trace are gaps that would otherwise have surfaced at cutover. A short validation pass is cheap insurance against the most expensive kind of separation failure, the one discovered when the business tries to transact on day one and a flow no one mapped quietly breaks.