Using SLO Tools to Implement Divestitures and Carve Outs in SAP Landscapes

datavard carve out slo

In my last blog post I presented an overview of System Landscape Optimization (SLO) and how it supports business transformation. I walked through some of opportunities and potential benefits of using SAP LT (Landscape Transformation) including flexible golive dates, conserving the integrity of SAP data, and minimizing the impact of a transformation on ongoing business.

For this post, I wanted to take a deeper dive into the topic of divestitures. In these scenarios, a portion of the business is sold to another company. From the perspective of business transformation in SAP, the goal is usually to provide the acquiring company with the data belonging to part of the business they acquired. Sometimes, a clean-up in the SAP systems of the selling company can be included in the carve out project, for example by deleting the data of the sold-off part of the business.

Different scenarios can occur when divesting a business unit:

  1. The part of the business that is sold off is implemented as one or several company codes in SAP, which can be sold completely
  2. The sold off portion of the business can be implemented as one or more plants that can be sold completely
  3. The carve out affects a product line, or a part of the business that is co-mingled with data and is not sold off.

In looking at these scenarios, the complexity and the difficulty of a carve out of complete company codes is lower than of plants, or of completely co-mingled data. Basically, there are two ways to implement a carve out from a SAP system landscape for each of the three scenarios: clone and delete, or a data migration based approach. It is important to carefully pick and choose the correct approach and tools (e.g. include masking and scrambling tools for co-mingled data).

The Clone and Delete Approach

In the clone and delete approach, the complete SAP system is copied and undesired data is deleted. For the carve out of complete company codes from an existing, productive SAP system landscape the clone and delete approach is the fastest and easiest way. For ERP systems, this approach is covered by tools such as SAP LT out of the box. For satellite systems such as BW, or other solutions such as CRM or SCM, the clone and delete approach can be implemented by experienced service providers such as Datavard.

For such deletions, SAP LT derives all data which belongs to selected company codes across the complete ERP system, and then generates deletion programs for all relevant database tables. The resulting system will appear as if the deleted company codes had never even existed. This is because SAP LT purges data from all areas including customizing, master data, transactional date, open and closed business processes.

The figures below show an example organization structure in SAP before the company code deletion.

SLO organization structure in SAP


In this example, only company code 2010 is supposed to remain in the system. The result of a deletion based on SAP LT looks like this:

slo sap datavard

The Data Migration Approach

Now let’s look at the migration approach where a new SAP system is set up. This can be done by either creating a new system and performing a client copy of type customizing (which involves a fair degree of manual work), or a shell creation process such as Datavard’s Lean System Copy (LSC). With LSC, an empty system copy of an existing SAP system can be created. Empty means that only customizing, custom developed programs, and SAP users are included in the new system. Data is then selectively migrated into this empty system copy to bring in the data for the carved out business unit.

In comparing these two approaches, it’s apparent that clone and delete has a number of downsides:

  1. The complete system must be copied before SAP LT can be used to delete data. This can be a lengthy and costly procedure, especially when the ERP system is running on SAP HANA, and only a minor part of the system is to be handed over to the buying company
  2. The clone and delete approach works “out of the box” only for complete company codes.
  3. The data deletion step can be lengthy (20 to 40 hours), especially for large systems. To overcome this, downtime minimization tools such as Datavard’s Company Code Obfuscation can be used to shorten the SAP system lock (downtime) during the cutover significantly.

For the carve out of plants using clone and delete, a plant reallocation would be required as a first step, which increases the complexity of the project to some degree. This plant reallocation is used to move all deletion relevant plants into a separate company code, which is then removed using the out of the box functionality provided by SAP LT.

Depending on the nature of cross-plant business processes and how they are implemented in SAP, this may be a significant effort driver. Therefore, when a carve out is to be done on plant level, the migration approach may win over the clone and delete approach. SAP LT supports such migrations, however some of the required scenarios in SAP LT are “restricted,” meaning they are not available to customers without expert consulting services from SAP’s own SLO team, or in close cooperation with experienced service partners such as Datavard.

For completely co-mingled data, the clone and delete approach is extremely difficult to implement, and the migration approach is more appealing. SAP LT includes data migration scenarios for “object based” migrations —  migrations of business objects, executed directly on the database instead of performing postings. Such object based migrations include historical business data such as data of closed fiscal years or periods where postings cannot be performed any more. Masking and scrambling tools can help a lot to fine tune the data transformation and hide sensitive data in divestiture scenarios. Datavard offers extensions to SAP LT which cover exactly this aspect of transformation projects. These extensions are also very useful in the context of GDPR.

SLO Webinar Series

In addition to these blog posts, we are also launching a 5-part webinar series covering everything from why SLO is so important, to harmonization and M&A best practices and more. The series started on Sept. 5 and continues through the end of October. Don’t miss this opportunity to learn about SLO from the experts. Go to our landing page today to sign up.



6 comments on “Using SLO Tools to Implement Divestitures and Carve Outs in SAP Landscapes

  1. Rishma on

    And what if the data will not be deleted in the SAP system but the divested company code data will have to remain in the system and the new buyer still wants to access the data in a readable format? The new company will have a new ERP ( no SAP) and will not migrate all data to the new system.
    I copying the company code data to a new environment and grant read only rights the best solution?

    • Goetz Lessmann on

      Hi Rishma,

      in such a case the buying company will still need the full history (minimum Finance, but probaly more). There are legal requirements to keep data for auditing purposes for +/- 10 years (depending on region and local legislation). What I would recommend is to provide them with a SAP system, or access to a SAP system which you run for them, which only contains their own data. This can be done using the “clone and delete” approach.

      I would not recommend giving them access to a full copy, where you implement ring-fencing with authorizations only for several reasons (data volume, data protection, security, etc.).

      Hope this helps,

  2. Priyadarshan on

    Nice explanation.
    Just need one clarification. How SLO tool will work in case few profit centers will be deleted from one Co Code & remaining will be intact ?

    Is there any way to deal with this type of scenario in SLO ?


Leave a Reply

Your email address will not be published. Required fields are marked *