If you’re involved in the world of SAP, and specifically in SAP S/4HANA—you’ve likely heard of the greenfield and brownfield implementation types. But what is selective data transition?
This blog post will introduce you to the concept of the selective data transition approach. As that name suggests, a selective data transition provides a “selective” approach to migrate the best of both worlds—data and processes—to a new SAP S/4HANA environment.
In this alternative approach to greenfield or brownfield implementations, a customer can choose to reuse current processes as well as redesign some existing processes. For example, a customer may want to reuse the logistics processes from their existing SAP ERP solution while redesigning the finance processes or vice versa. Furthermore, the customer can choose to selectively—all or time chunk—migrate company code-specific data to the new environment.
Let’s consider an example. The figure below shows an aspect of a selective data transition from a real-life project in which the customer wants to consolidate two of their instances and use selective data from both instances. In this case, the team created a shell copy of the first instance and carried out the system conversion of the copied instance. In the final step, the team uses the selective data transition approach to migrate the agreed-upon data, which is based on the customer’s functional or regulatory requirements, from all the instances and merge the configurations and the development work.
After creation of the SAP S/4HANA enterprise, instance A and instance B should be decommissioned. Now, from here, the SAP S/4HANA innovation journey starts.
The following are the scenarios for which you should consider a selective data transition:
- Phased go-live approach (in our example, the organization went live for instance A first and then for instance B after the configuration and development merger)
- To de-risk the big-bang approach
- When there’s no need for a large chunk of legacy data
- When merging or splitting the existing SAP ERP instances.
Overview
The figure below summarizes the key activities carried out by the team in the selective data transition approach. In the discover phase of the project, the team accesses the trial system to understand the innovations and the functionalities of the SAP S/4HANA system. In the prepare phase, apart from project kick-off and other project management activities, the team completes the setup and enablement activities (more info on this here), performs custom code analysis to identify any changes, retires unused code, modifies incompatible code, and provides high-level estimates of the changes. In the explore phase, the team sets up the sandbox environment from the current production (PROD) environment, carries out the fit-gap analysis, and prepares the product backlog based on the delta design workshops. In the realize phase, the team completes the implementation, tests the converted solution and the data migration in the quality assurance (QA) environment, and migrates the selective data. During this phase, the team also creates the new PROD environment. Finally, in the deploy phase, the team rehearses the production conversion, and carries out the production conversion, data migration, go-live, and hypercare. At the end of the deploy phase, the build team hands over the solution to the operate team to commence the run phase of the project.
Note: In the new implementation transition path for SAP S/4HANA, the team configures and tests, while in system conversion and selective data transition paths, the team adjusts the custom code.
Approaches
A selective data transition uses Data Management and Landscape Transformation (DMLT) services to move “selective” data from the current SAP ERP system to the new SAP S/4HANA environment.
You may get a question asking about the tool that you can use in the selective data transition path. You can use Data Management and Landscape Transformation (DMLT)—formerly known as SAP Landscape Transformation—for either of the target platforms.
You can select the following data for the transition:
Shell Conversion
In this approach, the team creates a copy of the existing PROD environment without master and transactional data but includes the ABAP Repository and configuration (Customizing).
Client Transfer
In this case, you select a client and the underlying master and transactional data with the configuration (Customizing) to transition to the target SAP S/4HANA environment.
Company Code Transfer
In this approach, you can select a company code from the current setup to create a single client on the new SAP S/4HANA system. You can select the master or transactional data from the client to transition to the new environment. Alternatively, you can select the configuration (Customizing) with or without the master data to move over to the target environment.
System Merge
In the process of system merge, you can merge business data from two or more clients to create an empty instance of SAP S/4HANA. These clients can be from the same or multiple SAP ERP systems.
There are two approaches for the target system creation:
Mix-and-Match Approach
In this approach, the project team creates a new SAP S/4HANA installation and then transports or manually transfers the ABAP Repository and configurations (Customizing) to the target environment.
Shell Conversion
In this approach, the team creates a shell copy of the current PROD environment that includes the ABAP Repository and the configuration (Customizing) without any master or transactional data. The project team, using system conversion, converts this shell copy to an SAP S/4HANA instance. In the absence of master and the transactional data, the conversion process is simpler and faster. Furthermore, the team can easily adjust the simplification list items without the business data.
Note: In the selective data transition path, you’re doing the following: Migrating a selection of data and reusing some of the current functionalities and redesigning some of the functionalities.
Landscape
The next figure shows the lifecycle of the existing environments in the selective data transition approach.
Note the following callouts in the figure:
- The discover phase of the project starts with the trial system access to review the innovations and the fitment of current business requirements. The team then builds the sandbox environment by shell copying the existing PROD environment. The team will use the sandbox system to drive the delta design workshops in the explore phase of the project.
- In the second step, during the explore phase, you need to shell copy the sandbox environment to the SAP S/4HANA development (DEV) environment. The project team will continue the configuration work based on the product backlog.
- In the next step, the project team creates the QA environment by shell copying from the DEV environment.
- In the QA system, the team completes all the testing activities, including selective data migrations.
- The team should fix any bugs in the SAP S/4HANA DEV environment and transport the fixes to the QA system for further testing.
- After successful completion of user acceptance testing (UAT), the team will shell copy the solution from the QA system to the PROD system and then perform the selective data migration, as shown above, from the existing PROD environment to the new PROD environment.
However, for the mix-and-match approach, the DEV, QA, and PROD environment are built using a fresh install. In the final step of the approach, the team completes the selective data migration from the existing PROD environment to the new PROD environment.
Benefits of a selective data transition
Following are some of the benefits of the selective data transition approach:
- Customers can consolidate multiple SAP ERP systems into one SAP S/4HANA system.
- Applications can be reused and redesigned.
- Phased go-live lowers the risks of the big-bang approach.
Comparison
The figure below shows the differences between system conversions (brownfield) and selective data transitions. The prime difference between the two approaches is the use of tools; while you use Software Update Manager (SUM) for the system conversion and convert the data, you use DMLT for selective data transition and migrate the data. The selective data transition approach requires data migration of limited master and transactional data due to the consolidation of several systems or splitting into several systems.
Below shows the comparisons among the new implementation, selective data transition, and system conversion approaches.
Let’s review each characteristic in detail:
Process Redesign
In new implementations, you can redesign and reengineer all processes, including the change in the organizational structure, whereas with system conversion, you can’t redesign the processes. However, if you consume further innovations, you can redesign those processes after system conversion.
Selective data transition is in between the two approaches whereby you can redesign the processes to a great extent, including the possibility of the organizational structural change in the mix-and-match approach while the shell conversion presents limited possibility of process redesign.
Process Reuse
This is the exact opposite of process redesign. For new implementations, you can’t (and should not) reuse the existing processes, whereas you can fully reuse the existing processes in the case of system conversion. The mix-and-match approach of the selective data transition presents a limited possibility to reuse existing processes, whereas shell conversion presents the possibility to reuse the existing processes to a certain extent.
Master/Transactional Data Migration
For greenfield projects, it’s highly recommended to migrate only the master data and limited transactional data to the new environment. In the selective data transition approach, you can migrate the data selectively, so the indicator is set at “possible to a great extent.” On the other side of the spectrum, for brownfield projects, you can migrate all the data from the current environment to the target system.it
Data Transformation
In new implementations, with the new processes, the new data is transformed fully. In a system conversion, on the other hand, you use the same data with the change in data model. Both the options of selective data transition approaches present a great possibility of data transformation.
Data Cleansing
In new implementations, with the new processes, you get cleaned data. However, in system conversion, the team can archive and cleanse the data prior to the implementation project. The selective data transition also presents a great possibility of cleansed data.
Target SAP S/4HANA System
A customer can choose any platform—on-premise SAP S/4HANA; SAP S/4HANA Cloud, extended edition; or SAP S/4HANA Cloud, essentials edition—for greenfield projects. However, in brownfield projects, SAP S/4HANA is the only target platform. You can select either SAP S/4HANA Cloud, extended edition, or SAP S/4HANA Cloud as the target platform for both the approaches of selective data transition projects.
You may get a question about the target solutions for the selective data transition path. Remember that you can move to SAP S/4HANA or SAP S/4HANA Cloud, extended edition (previously known as the single-tenant edition).
Phased Go-Live
A new implementation for both approaches of a selective data transition can decide to go for a phased approach that isn’t possible for system conversion projects.
System Split/Consolidation
New implementations don’t allow you to merge/spilt the existing instances, whereas the rest of the approaches do provide that flexibility.
Conclusion
When it comes time to make the move from SAP ERP to SAP S/4HANA, there are a number of ways to get your business up and running. While the greenfield (new implementation) and brownfield (system conversion) approaches are well known, the selective data transition project approach is less so. This blog post introduced you to the concept of a selective data transition migration and how it differs from the other options.
More on brownfield migrations here.
Editor’s note: This post has been adapted from a section of the book SAP Activate Project Management Certification Guide: Certified Associate Exam by Aditya Lal.
Comments