Lesson 5 of 6
Carve-outs and divestitures
8 min
Listen to this lesson
Selling part of a business is harder in SAP than buying one. A buyer adds data; a seller has to take data out of a system where it is mixed with everything it keeps, hand it over completely, and prove that nothing else left with it. Market researchers and advisers agree on the hard part: co-mingled data. This lesson uses a clearly labeled what-if, because Contoso is not selling anything.
Where 1810 is entangled
A whole legal entity is the easiest unit to carve out, because SAP keys most finance data by company code. A plant inside a shared company code is much harder: it usually has to be moved into its own company code first. Toledo is a separate company code, which helps, but 1810 still shares a great deal with the rest of Contoso's system.
| Shared object | How 1810 uses it | Carve-out question |
|---|---|---|
| Business partners | Customers and suppliers extended to 1810, some also to 1710 | Which partners go, which stay, which go as copies? |
| Material masters | CMC-ALT-100 and the bracket kit CMC-BRK-500 extended to plant 1810 | Transfer plant views only, or the whole material? |
| Intercompany | 1710 sells CMC-ALT-100 to 1810 at the internal price of $200 | Settle open intercompany items; prices become third-party prices |
| In-house bank | 1810 holds an internal account with 1710 instead of its own operating bank accounts | New bank accounts and payment formats before close |
| Controlling area A000 | Cost center 18101101, profit center CMC-PARTS, allocations from shared services | Stop allocations; which cost history goes with the business? |
| Roles and users | Contoso task roles derived for 1810 | Who keeps access, and until when? |
| Interfaces | Third-party orders to Lakeside Components; EDI with customers | Rewire to the buyer's partner IDs and endpoints |
Co-mingled objects in the Toledo what-if: each needs a decision before any tool runs.
Approaches
| Approach | How it works | Strength | Risk |
|---|---|---|---|
| Clone and delete | Copy the whole system, then delete data of units not transferring (DMLT company code deletion or carve-out) | Short timeline; processes keep working | Residual data from other units |
| Empty shell plus selective migration | Copy configuration and code without data, then migrate only in-scope data | Tight control of what leaves | More build and reconciliation effort |
| Carve-in to the buyer | Migrate the unit's data into the buyer's ERP | No new landscape | Harmonization inside the buyer's live system |
| Clone and go | Hand over a full copy | Fastest | Highest data-leak risk; rarely acceptable |
| Greenfield NewCo | New SAP S/4HANA, often public edition, with master data and open items | Clean core from day one | Full process build and testing on a TSA clock |
Most carve-outs run in two steps. First comes logical separation: on Day 1 the seller keeps running the sold unit in its own system under a TSA, with access restricted so the buyer's staff see only their company code. Then comes physical separation: the data moves out, by carve-in, clone-and-delete or shell. In the Toledo what-if, Contoso would run 1810 in CMP under a TSA for up to twelve months, then deliver an extract or a cleansed copy for the buyer to load.
Licensing needs early attention. SAP licenses usually cover the licensee and its affiliates; after close, the sold business is no longer an affiliate, so hosting it under a TSA may need SAP's consent or a transitional-use clause. SAP publishes no general divestiture rule. Check your SAP agreement and, for RISE with SAP, the order form's affiliate, divestiture and change-of-control terms before signing the deal, and treat any consultancy fee estimate as an estimate.
Remove, scramble, keep
Testing a carve-out has two halves. Positive tests prove the buyer received everything it needs and that its processes work on it: it can sell, ship, invoice and close for 1810. Negative tests prove nothing else left: zero records of 1710 or 1910, no partners outside scope, no other unit's prices or employees. Both seller and buyer run them, because each has its own liability. Course sap-dmg-305 builds these tests in detail.
Access cutoff
- A user list by legal entity, with each user's roles and the planned cutoff date and time.
- Removal of 1810 derived roles from Contoso users, and of everything except 1810 from users who transfer.
- Emergency (firefighter) access for the TSA period, logged and reviewed.
- Technical connections: RFC destinations (SM59), trust relationships, single sign-on federation, VPN and e-mail domains.
- Evidence: before-and-after user and role reports, and an access review after cutoff.
What would you do?
In the Toledo what-if, the first clone-and-delete mock delivers a copy containing only company code 1810 documents. The buyer is ready to sign. Nadia notices that the business partner table still holds 1,200 partners with no 1810 data at all. What should the seller do?
- Co-mingled data is the core carve-out problem; a whole company code is easier than a plant.
- Approaches range from clone-and-delete to shell, carve-in, clone-and-go and greenfield NewCo.
- Logical separation under a TSA comes first; check SAP license terms for hosting a former affiliate.
- Every object is removed, scrambled, transferred or kept, and both sides run positive and negative tests.
Check your understanding · not graded
Lesson check
1. Why is carving out a plant inside a shared company code harder than a whole company code?
2. What is logical separation in a carve-out?
3. What does a negative carve-out test prove?
4. Before signing a deal in which the seller will host the sold unit under a TSA, what should the team check?