IT carve-out: separating systems from the group.

An IT carve-out is the separation of part of the IT out of a larger group, so that it runs without the former parent company. Over the years, units inside a group come to share systems, databases, contracts and operations teams. What was practical day to day becomes the problem the moment one part is meant to go its own way.

A carve-out is more than a migration. In a migration a system moves from one place to another. In a carve-out, what has grown together has to be cleanly separated first, before anything can move at all. First you cut, then you build, then you operate. That is exactly the order we work in, and the same team stays on it from the separation through into operations.

A carve-out is rarely at the start of a plan. Usually it is the technical consequence of a commercial decision that was taken long before. The most common triggers are:

• The sale of a business unit that has to arrive at the buyer without the old group systems.
• The spin-out of a unit meant to carry on as an independent company.
• A succession in which part of the company passes into new hands.
• Separation from a parent company whose infrastructure can no longer, or should no longer, be used.

In every one of these cases a clock is running. There is often a time-limited transitional agreement, a transition service agreement in the trade, under which the former parent keeps the systems running for a while. That period is the real deadline. By then the separated part has to run on its own.

How long that period turns out to be depends on how entangled the systems are. Deloitte puts the duration of IT transitional service agreements in practice at eight to twelve months and notes that a complex separation of systems can push it out further. That is usable as a planning figure, not as a promise. What applies in your case sits in your contract and nowhere else.

It starts with a clear picture of the current state, because what is unknown cannot be cut cleanly. If you want a rough overview first, the system audit self-check is a place to start. Four areas then get separated:

• The data belonging to the separated part, cleanly bounded off from everything that stays with the former owner.
• The interfaces to systems that are not coming along, replaced by your own connections or transitional solutions.
• The contracts with vendors, licences and services that have to be newly concluded, transferred or replaced.
• Operations itself, meaning access, responsibilities and the knowledge that keeps the running service alive.

Each of these areas has its pitfalls. Data often hangs on shared databases whose separation takes time. Interfaces are rarely documented in full. And operations lives on people who may no longer be available after the cut.

Contracts deserve their own mention, because their pitfall is a legal one. Where a unit is spun out as a whole, the carve-out route under § 123(3) of the German Transformation Act applies and the allocated legal relationships move with it. Where things are transferred individually, which is the usual case, every assumption of debt depends under § 415 of the German Civil Code on the creditor's consent. Put plainly: your vendor can say no. That is why the contract list belongs at the start and not at the end.

The biggest risks in a carve-out are known, and they are manageable if named early:

• Data loss or incomplete transfer, when the boundary is drawn too coarsely.
• Interruption to operations, when an interface turns out to still be needed on cut-over day.
• Forgotten dependencies on the former parent that only surface after the transitional agreement expires.
• Licence and contract gaps that leave continued operations legally exposed.
• New security gaps in the freshly built environment, which belong evidenced before go-live.

The third and the fifth risk yield to the same remedy: a rehearsed recovery before the cut-over day rather than after it. How far that can be taken is set out by the German Federal Office for Information Security in its Standard 200-4 on business continuity management. For a carve-out the small version usually suffices, which is to shut everything down and bring it back up once before it counts.

Getting out of the transitional agreement early is not an end in itself either. Deloitte points out that an early exit removes the dependency on the other side, and that one-off penalties for early termination tend to be given undue weight against the overall value of the agreement.

That is why we test the new environment before go-live and evidence that it holds, on request with a dedicated penetration test. We support the carve-out in the carve-out and migration position, from the separation through building the new environment to the first independent day of operations. Responsibility does not stop there. On request we carry on running operations under a service agreement, so the new part does not start without backing.

In closing

A carve-out is manageable when it is approached in the right order: first the clear picture, then the separation of data, interfaces, contracts and operations, then the independent start under rehearsed conditions. The time pressure usually comes from a time-limited transitional agreement, which is why starting early pays. Further answers on contracts and where data is held sit under Knowledge. For a concrete plan, a first call is the right first step.