A company sells a division. The contract is signed, the separation date is set, and somebody asks: and what about SAP? That is the moment it becomes clear that the business being sold is not a folder you can copy — it is entangled with the rest of the company through fifteen years of shared master data, open documents and accounting history that no filter can separate.

This work has a name in the SAP world: SLO, system landscape optimisation — the family of operations that reorganises data inside a productive environment. Carve-out is the most visible of them, and the one that always turns up with the same characteristic: a deadline set by contract, not by project.

Why copy-and-delete does not work

The initial instinct is always the same: copy the whole system, and let each side delete what is not theirs. It sounds reasonable and it fails for four reasons.

Master data is shared. Vendors, materials, the chart of accounts and cost centres serve both sides. There is no such thing as “the material belonging to the company being sold” — there is a material used by both, with a history that belongs to both as well.

Documents do not respect boundaries. An order raised in one company with receipt in the other, goods in transit, a production order that crosses the cut-off date, a contract with partial delivery. Each of those needs an explicit decision.

Deleting is irreversible and visible. Removing data from a productive system compromises reporting, audit and record-keeping obligations. And what you delete by mistake does not come back.

Whatever remains still has to close. The company that stays has tax, accounting and corporate obligations covering the period before separation. It cannot lose the history of what was sold — it needs that history to answer for the period.

That is why the path runs the other way: you do not delete from the original; you extract into the new one, with an explicit and selective rule, keeping the source environment intact.

Defining the cut is business work

The technical question — “which company codes go?” — is the easy one. The hard ones come afterwards, and none of them is answered in IT:

• How much history goes with it? Only the balances at the cut-off date, or movements from recent years? Every extra year multiplies effort and volume.
• What happens to open documents? Orders, contracts and production orders that cross the date need a rule: close beforehand, migrate open, or recreate on the other side.
• Who keeps the master data? Both sides take a copy of the shared vendor — and from that point on they diverge, which is expected and needs to be stated.
• What is confidential between the parties? After separation, one side cannot see the other’s data. That applies to history that sat in the same system yesterday, too.
• How long does the transition period last? Almost every separation has a period in which the selling company provides services to the one sold — and that agreement defines what has to keep working between the two.

Every ambiguity left unresolved here reappears later as an incident. IT’s role at this stage is to ask the question and show the consequence of each answer — not to decide.

Map the dependencies before touching anything

Once the cut is defined, the technical work begins with an inventory of what crosses the boundary. It is the step that prevents late discoveries, and it has four fronts.

Organisational objects. Which company codes, plants, sales organisations and purchasing organisations go, and what they share.

Shared master data. How many records serve both sides. A warning applies here: if the master data is dirty, the carve-out multiplies the dirt by two. Cleansing beforehand is cheaper than cleansing twice afterwards.

Developments and integrations. Every report, interface and customisation has to be assessed: does it go to both, to one, or does it disappear? It is the same WRICEF inventory, with one extra question — whose is it?

Flows with third parties. Banks, tax authorities, customers and suppliers all need to know a new entity exists, with its own identification. Certificates, credentials and external registrations tend to have longer lead times than the project itself — which is why they should start first.

Extract, reconcile and cut over

Selective extraction uses the same family of replication and migration tools that supports an ordinary conversion — the difference is that here the selection rule is the heart of the work, and it comes from the business definition, not from the technician.

What decides success is not the load: it is the reconciliation. After every cycle, both sides have to tie out — and “tie out” means numbers that each company’s controller recognises as their own.

Three layers, in order: counts of records by object; totals the business recognises, such as balance by account, stock by storage location and open items by customer; and sampling at the edges — the document that crosses the date, the contract with partial delivery, the item with two codes. It is the same discipline as data conversion, with one extra requirement: the result has to be accepted by two parties with differing interests.

And, as in any critical cutover, the cycle repeats: one rehearsal to measure mechanics, one to measure quality, and one timed within the real window, with the same people and the same script as on the day.

Where AI helps — and where it does not belong

The extraction itself is deterministic and should stay that way. But three expensive parts of the work are reading and comparison, and there the economics change.

Mapping dependencies. Reading developments and integrations and pointing out which ones touch organisational objects on both sides — the survey that consumes weeks of manual analysis.

Explaining what each object does, so the business can decide whose it is. Without that, the decision stalls for lack of information, not for lack of will.

Reconciling divergences. When the numbers do not tie out, reading both sides and proposing where the difference lies — the same similarity-matching capability we use in reconciliation work.

Where AI does not belong: defining the cut, which is a corporate decision; signing off the reconciliation, which is done by people; and any deletion of data. A model that suggests deleting a record in a carve-out is pure risk with no upside.

What usually goes wrong

Starting the external work too late. Registration with public bodies, digital certificates and banking credentials for the new entity have lead times of their own, which do not obey the project schedule. It is the most common cause of a separation date slipping.

Underestimating the transition period. The period in which the seller provides services to the company sold is usually treated as a contractual detail and is, in practice, an architectural requirement: it defines the access, integrations and reports that have to exist on both sides for months.

Treating what remains as leftovers. All the attention goes to the new entity, and the company that stays discovers at the first close that it has lost a report, an interface or an access profile.

Confusing the accounting date with the technical date. They are different things and have to be agreed explicitly, including what happens to movements between one and the other.

What remains after the separation

The obvious deliverable is the new environment running. The ones that last are two others.

The documentation of the cut rule. Why each set went where it went. When the auditors ask — and they will, on both sides — the answer exists.

A cleaner environment on both sides. A carve-out forces you to look at master data, developments and integrations with a question that is rarely asked: whose is this, and what is it for? Much of what has no answer should not be there — and this is the opportunity to get closer to a clean core instead of duplicating the mess.

The honest limit: separating a company is a contractual deadline with legal consequences, and no tool shortens the part that depends on a corporate decision. What good technical work guarantees is that, when the decision comes, execution is not the bottleneck — and that nobody discovers at the first close that something was left out.

If the separation comes alongside a platform conversion, the two conversations intersect: see SAP practices for the overall view, and the guide to brownfield, greenfield and bluefield at Inove Academy — the selective approach is the one closest to carve-out reasoning.