Blog articles

SAP

Data separation: how SAP carve-out slicing really works

SAP Carve-Out SAP Data TSA

Martin Charle – Sep 29, 2026

In a divestiture, a business unit’s data has to leave its comfy shared SAP system and stand up on its own. Most of the technical difficulty sits in one question: what belongs to the entity being sold?

A data model with no line in it 

SAP was never purposedly built to be split by legal entity. Master data, configuration and transaction history are shared across organizational levels on purpose. That sharing is what makes a single system efficient to run, and it is exactly what makes it hard to divide.  

An SAP carve-out is the exercise of drawing a line through a data model that has no line in it. 

When the project runs against a Transition Services Agreement (TSA), the approach that fits the clock is a selective data transition: extract the data that belongs to the divested entity, and nothing else. 

Slicing starts with a selector 

The primary selector is almost always the company code, the legal entity in SAP.  

But a company code never travels alone. It brings a whole enterprise structure with it, and each element has to be examined:

  • Plants, the sites where operations physically happen, and the storage locations inside them where stock is held. 
  • Purchasing organizations, the units that negotiate with vendors. Some serve a single plant, others serve the entire group. 
  • Sales organizations and divisions, which define how the business sells and how it segments its products. 
  • The controlling area, the cost accounting perimeter. It frequently covers several company codes at once. 
  • The chart of accounts, the general ledger catalog, usually defined once for the whole corporation. 
  • The valuation area, where inventory values are calculated, and the credit control area, which governs customer credit. 
The first real deliverable of a technical assessment is a map of this structure: which elements are exclusive to the divested entity, and which are shared with the businesses staying behind. Get that map wrong and every slicing rule built on top of it inherits the error. 

 

Where the selector stops working 

Some examples of challenges come up in nearly every SAP S/4HANA carve-out … and none of them is solved by filtering on company code.  

Master data has no company code
The header tables for materials, customers and vendors carry no company code field at all. You reach them in two hops: first identify the records at the organizational level, where the plant or company code does exist (MARC for materials, KNB1 for customers, LFB1 for vendors), then pull the matching header records. Anyone who has run this exercise knows the selection logic lives in that second hop.

Orphan records
Some master records exist at header level with no organizational assignment, yet the new entity cannot operate without them. Manufacturer part references, maintenance assemblies and non-valuated materials are typical cases. No rule driven by the selector will catch them. They have to be identified deliberately, reviewed with the business, and approved explicitly by the seller.

Shared controlling
When a controlling area covers both in-scope and out-of-scope company codes, its tables cannot simply be filtered. Separating them takes object-number analysis and custom extraction logic. This is engineering work, not configuration.

Business partners
A small table, and no clean company code linkage. Two defensible answers exist: copy it in full with the seller’s written approval, or build a curated list. Which one applies is a data privacy decision, and it belongs to the seller, not to the technical team.

Every table lands in one of three buckets

At the end of the analysis, every table is either sliced, copied in full, or excluded. Customizing is generally copied in full, so the new entity keeps the processes it runs today. Master and transactional data are sliced.  

Custom Z and Y tables, along with tables delivered by third-party add-ons, default to a full copy. That default is the trap: left unexamined, it quietly carries the seller’s data into the buyer’s system. A real project rules on hundreds of these tables one by one, as a joint business and technical exercise, and that ruling sits on the critical path.

The scope is the schedule 

A carve-out project schedule is really a scoping decision made months earlier. The slicing rules described here are the scope, and they are knowable before the TSA is signed, which is when they are still worth something. 

oXya runs that assessment for sellers and buyers on both sides of a divestiture.

Frequently asked questions

What is the primary selector in an SAP carve-out?
Almost always the company code, the legal entity in SAP. It is the starting point for slicing customizing, master data and transactional data, extended by the enterprise elements attached to it: plants, purchasing organizations, sales organizations, controlling area and valuation area.

Why can’t master data be sliced by company code alone?
Because the header tables for materials, customers and vendors contain no company code field. Records are identified through organizational-level tables that do carry the company code or plant, then matched back to the headers. Records with no organizational assignment must be handled separately.

How much history should be migrated in a carve-out?
Master data and open items always move. Change documents, workflow logs and interface records are excluded by default, yet daily operations often depend on them. A time-boxed slice, commonly the last 24 months, is the usual compromise between business continuity and the size of the target system.

Martin Charle

Martin Charle

Vice President, Strategic Initiatives, Canada

With more than 10 years of experience in information technology, Martin Charle leads transformation programs and strategic initiatives at oXya Canada, with a focus on operational performance, structured execution and complex business environments.

Share it now: