Last updated: March 3 2021
In this blog, I describe how existing SAP customers can move from their existing SAP ERP solution to SAP S/4HANA using the “Selective Data Transition” approach. This is one of three possible approaches:
- System Conversion
- New Implementation
- Selective Data Transition
If you are new to the topic, read my other blog first on moving to SAP S/4HANA. This provides some background and detail on the other two approaches. https://blogs.sap.com/2019/10/30/how-to-move-to-sap-s4hana/
Selective Data Transition is an alternative to the New Implementation approach (also called greenfield) or System Conversion approach (also called brownfield). It is relevant for customers moving from an existing SAP ERP solution to SAP S/4HANA on-premise or SAP S/4HANA cloud, private edition. For details on S/4HANA deployment options, see my blog: https://blogs.sap.com/2019/08/22/sap-s4hana-cloud-and-on-premise-deployment-options/#
As its name implies, this approach involves transferring data from one or more existing ERP solutions to a new S/4HANA solution. The transfer is done by SAP or partners that provide specialized tools and services. The data selectively transferred can include:
- ABAP repository of objects and developments
- Configuration (customizing) data
- Master data
- Transaction data (open items and a time-slice of historical closed items e.g. 2 years)
There are two common approaches to create a target system with Selective Data Transition: Shell Conversion and Mix and Match. In Shell Conversion, a shell copy of a production system is made without master and transaction data and this is converted to SAP S/4HANA. In Mix and Match, a new S/4HANA install is created and then elements of the existing configuration and ABAP repository are transported or manually transferred. Both scenarios require data migration to follow including master data, balances and open items.
Selective Data Transition allows you to selectively re-use parts of your existing ERP solution while re-designing others parts. Typically this is done by application area. For example you may re-use the ERP logistics solution but re-design the finance solution. Or you may re-design procurement and asset management whilst re-using the existing sales and finance processes.
As shown in the diagram above, Shell Conversion is used when most of the solution and processes are being re-used. Mix and Match is used when a majority of the solution is being re-designed. A comparison of the approaches is shown below.
The data is moved using SAP Data Management and Landscape Transformation (DMLT) software and related services. SAP DMLT used to be called SAP System Landscape Optimization (SLO). For over 15 years, SAP DMLT have provided well established solutions and services for organizational changes, acquisitions, divestitures, or harmonization of SAP landscapes. The software provides highly automated processes that move large amounts of data between SAP instances quickly. The SAP DMLT services team deliver projects globally.
Similar software and services are provided by third party vendors for S/4HANA on-premise. More detail on these later.
Selective Data Transition should be considered when organizations need to:
- Go live in phases (e.g. by country or business unit).
- Reduce re-implementation effort by re-using some application areas e.g. logistics while re-designing others e.g. finance.
- Reduce risk of a big bang go live.
- Split or merge existing SAP ERP instances. (For example, you may choose to carve-out application areas or companies and implement them on a separate instance or in the cloud).
- Leave behind large amounts of old data e.g. to reduce the duration of conversions and cutovers. (This is an alternative to doing a large data archiving project followed by a system conversion).
The split and consolidation of ERP instances is a large topic in its own right and is not covered in detail here. Instead, I focus on how Selective Data Transition can be used to phase go-lives. This may be required in ERP solutions with large data volumes or with many users in multiple countries.
As stated earlier, the starting point is to create a parallel SAP S/4HANA sandbox or development system. A new clean install of SAP S/4HANA can be used (Mix and Match approach). Alternatively, use SAP DMLT to create a “shell” copy of an existing ERP system (Shell Conversion). The shell contains the ABAP repository and configuration data without master data or transaction data. A system conversion is done to turn this into an S/4HANA instance. The conversion process is simpler and faster without the master and transaction data and certain S/4HANA Simplification Items can be more easily implemented without business data.
For selective data migration of master and transaction data, SAP DMLT tools are used. If no historical transactions are required and only open transaction items are needed, the SAP S/4HANA Migration Cockpit (direct transfer scenario) may be simpler. SAP DMLT allows a time slice of historical transaction data to be migrated.
An example project scenario using Shell Conversion is described below. This assumes a two stage project. The first stage is a technical transition followed by a second stage to implement business transformation innovations. The first technical transition stage is outlined below:
- Engage SAP DMLT or a partner to advise on the approach. This may lead to preparation work in the existing ERP system.
- Analyze DMLT source system functionality e.g. using Business Process Improvement within Solution Manager.
- Analyze existing landscape using SAP Readiness Check and SAP Business Scenario Recommendations (BSR).
- Execute S/4HANA preparation activities in the existing ERP solution. This might include archiving data to reduce the data footprint although data reduction can be achieved when data is transferred to S/4HANA with DMLT tools. You may remove unwanted unused custom code and configuration. You may also perform Customer Vendor Integration (CVI) to make business partner the lead object.
- Create a new S/4HANA sandbox system. Create a shell copy using a recent copy of a production ERP instance
- Perform an S/4HANA system conversion of the shell system.
- Make configuration changes required to execute Fit-to-Standard workshops.
- Analyze custom code and make decisions about what to adapt during the Realize phase.
- Conduct Fit-to-Standard analysis and design focusing on mandatory S/4HANA Simplification Items.
- Set up data migration tools and environment.
- Create a new S/4HANA development system using a shell copy of the sandbox system.
- Set up a production support track for on-going maintenance of the live solution.
- Make configuration changes required for SAP S/4HANA Simplification Items.
- Adapt ABAP code for SAP S/4HANA
- Implement any changes required for integration and analytics solutions.
- Execute multiple data migration test cycles using SAP DMLT in the sandbox.
- Set up a quality assurance system and production system with a copy of the S/4HANA development shell without master and transaction data.
- Test selective migration of master and transaction data in the Quality Assurance system. A time-slice of transaction data is used e.g. move 2 years of historic transactions leaving 8 years behind.
- Set up SAP Information Lifecycle Management (ILM) and a retention warehouse to move old data onto a low-cost infrastructure.
- Run integration and User Acceptance tests.
- Rehearse the cutover.
- Migrate master data and, if required, historical transaction data into the Production system.
- Cutover to the production. Migrate transaction item data and master data that has changed since the last migration cycle.
Once the technical transition stage is complete, a second project stage can be kicked off to implement business transformation innovations e.g. to adopt SAP Fiori apps. The first stage is led by a technical team and the second stage is led by the business.
This approach may be flexed. For example:
- First go-live could include business transformation scope in addition to the technical conversion.
- S/4HANA preparation activities in the prepare phase could be done in the sandbox rather than the existing ERP solution.
- In the Explore phase, you might jump straight to a development system instead of using a Sandbox. (The Sandbox is still required later to do the test cycles of data migration).
- During the technical transition, configuration and ABAP code adaption could be done in the sandbox system and then moved to a development system. This can reduce the duration of the production support track.
- Multiple sequential go-lives could occur with master and transaction data migrated as required e.g. by country and company code.
- Selectively transfer business and master data from multiple source ERP systems. A pre-requisite for working with multiple source systems, is that the ABAP repository and configuration of the source systems are compatible. Harmonization work is required in the Prepare phase.
- Only use the S/4HANA Migration Cockpit for data migration (excluding historic transactions). This provides a more application focused approach when compared to the technical migration involved in DMLT services. Less harmonization work may be required.
- The old production system may be de-commissioned to a dormant status to access historic data and archived data.
For more information about using SAP Data Management and Landscape Transformation (DMLT) services including FAQs see this page:
There is Knowledge Based Article (KBA) which is regularly updated with latest information: https://launchpad.support.sap.com/#/notes/3018442
Or see https://www.sap.com/services/implementation/data-mgmt-landscape-transformation.html or read the solution brief and the SAPPI Success Story. You can contact the global SAP DMLT team by email mailto:firstname.lastname@example.org. They provides services for Selective Data Transition, New Implementation and System Conversion that can also be delivered remotely.
There are four partners that provide software, tools and services for selective data transition:
These are alternatives to using SAP DMLT services for SAP S/4HANA on-premise projects. These organizations are part of a global expert community. SAP has not certified any of the partners toolsets and SAP support agreements do not cover fixes for inconsistencies that could occur using their tools. You can get more details of their offerings at these links:
I hope you found this blog informative.
Enterprise Architect at SAP Services UK