Options for your SAP S/4HANA Transition
Approach for this Blog
A change in the financial model from an accounts model to a ledger model is now available within an SDT approach. The introduction of a document split approach is also possible within an SDT approach.
In this blog you will learn the following:
- get an overview about the different transition options to SAP S/4HANA
- understand, when to choose the selective data transition to SAP S/4HANA instead of a brownfield or greenfield approach.
I am a principal consultant and architect in the DMLT / SLO consulting department. I want to share some of my learnings during the planning of SAP S/4HANA transition projects.
Structure of this blog
This blog is structured using the following chapters:
- Options to move to SAP S/4HANA
- New Implementation aka “Greenfield Approach”
- The Selective Data Transition to SAP S/4HANA Approach (SDT)
- Shell Creation
- Use cases for Shell Creation
- Time-Slice Scenario
- Selective Company Code Transfer
- Adaption and Selection Scenario
- Mix and Match
- System Decommissioning / System Retention
Options to move to SAP S/4HANA
If you want to migrate to SAP S/4HANA on Premise you do have the following three options:
- System Conversion (aka “Brownfield-Approach”)
- New Implementation (aka “Greenfield-Approach”)
- Selective Data Transition to SAP S/4HANA
First I will recap shortly the brownfield and greenfield approach to motivate the need for the selective data transition to SAP S/4HANA approach.
The picture below summarises the different approaches on a very high level:
If you want to keep all data and want to reuse your current processes, you will likely go for a System Conversion approach, while a new Implementation will be the right approach, if a process redesign is necessary. However in this case you can not migrate your historic data.
As often customers need more options, than the two ones just outlined, the selective data transition to SAP S/4HANA has been developed. This option allows the question about the process reuse to be answered not for the entire system, but for the different solution / application areas separately.
There is already a blog from Amin Hoque about the selective data transition to SAP S/4HANA.
While the Blog of Amin covers mostly the various steps of the project procedure I want to dive a little bit deeper into the technical and practical aspects of the selective data transition to SAP S/4HANA. I will outline the different sub-options of the selective data transition to SAP S/4HANA approach and will show some options to give some more flexibility to the brownfield approach.
System Conversion aka “Brownfield-Approach”
The basic Idea of the brownfield approach is, that you start your new SAP S/4HANA-system as much as possible based on the settings of your current SAP ERP-System.
In the Brownfield Approach you convert your existing system towards an SAP S/4HANA-system using the Software Update Manager within an in-place conversion. You can combine this approach with a database migration to SAP HANA in case your current system is still not on SAP HANA. (In the very early days of SAP S/4HANA it was recommended to split the DB migration to SAP HANA and the conversion to SAP S/4HANA in two different steps/projects – but this advice is outdated since several years now).
There is a blog describing the steps & details of the system conversion approach here:
In case of tough requirements regarding the downtime and huge databases you can combine the system conversion with a NZDT-approach, see e.g. the following blogs about this topic:
Though the basic idea of the system conversion to SAP S/4HANA is to build your new system based on your existing solution due to the simplifications and the code enhancements you will need to rework some parts.
One side-remark: One of the most reasons for a project to fail or to overrun the budget, is a missing clear scope. The big advantage of a brownfield approach is, that you get a clear scope from your existing SAP ERP-solution:
You will take the settings of your existing SAP ERP-solution as a baseline and you will just change your solution in those areas, where the readiness checks highlights, that some rework needs to be performed.
The SAP Readiness Check will outline the minimum changes you have to cover within your project. Therefore, in most cases the brownfield approach is the quickest and most economical way to bring you to a solution based on SAP S/4HANA.
However, there is one downside:
You are limited in the changes, that you can accomplish within a brownfield approach: It is e.g. not possible to change your system from a parallel accounts model to a parallel ledger model or to change certain currency settings in parallel to the system conversion.
Of course, there are many more changes you can think of.
These limitations guide many customers towards a reimplementation of the complete solution using a greenfield approach, even if this may not be necessary.
My advice for these cases is the following:
- Clearly list all changes, which you would like to reimplement – this will help to keep a clear scope and focus.
- Check, which of these changes cannot be implemented together within a system conversion approach
- Check, whether these changes need to be performed in parallel to the project or whether they might be addressed as well in prior or consecutive projects.
Check with DMLT/SLO, whether these changes can be covered within special conversion packages from DMLT / SLO, that can be applied either before or after the system conversion in an own project.
(I had a customer who started a big greenfield project for SAP S/4HANA with a big partner. After he realised the tremendous costs of a complete reimplementation, he turned to us for advice. Reviewing the main customer requirements for changes we quickly understood, that all of these changes could be realised within a “small” 9 month project prior to the system conversion. Using this stepwise approach, the customer could spare the huge amount, he would have needed for a greenfield solution and replace it with a small fraction of this cost he needed for the DMLT/SLO project.
You can directly contact the DMLT colleagues in order to find out, whether the changes, that you are intending can be covered within an SLO conversion contacting the following Email: email@example.com
As the greenfield approach is well known to most of our customers, I will be very brief and highlight only one aspect of the data-migration procedure for this scenario. I will need this later for the description and motivation of the selective data transition to SAP S/4HANA approach.
Different to the system conversion approach within a greenfield approach only open items and master data can be migrated. Why?
The answer is simple: All data will be migrated to the new SAP S/4HANA system not directly at table level but only using interfaces of the target SAP S/4HANA-system. The interfaces will guarantee the system integrity of the target system. If you migrate e.g. an open purchase order the system will not only update automatically all the different logistics tables, but will create the related financial, controlling and other documents as well by creating the relevant entries in the different tables.
The big advantage of SAP ERP and SAP S/4HANA is the integration between the different application areas. But this comes for a price: A high complexity of the relationships between all the different objects. SAP takes care of this by providing the right interfaces to insert or update business objects. However these interfaces are only provided for open documents but not for historic or also called closed documents.
If you want to migrate historic documents, you need to migrate “at table level” taking care of the integrations between the different tables and objects on your own instead of giving this task to an interface provided by SAP. You will need deep experience and special tooling to cover these integrations. Otherwise you may create an inconsistent system which may not work properly and in the worst case, will report wrong and inconsistent numbers – but don’t worry too much, the Wirecard example shows, that the auditors may not find it – sorry, but a small joke must be allowed :-).
DMLT aka SLO has developed special migration tooling, that can take care of this highly tricky tasks – but even though this toolset has been developed since about 25 years, there are some limitations. In a nutshell the situation is like this: the more differences that we do find between the source and the target system the more difficult or even impossible it will get to migrate as well historic data. More on this will be outlined in the chapter about the selective data transition to SAP S/4HANA.
I just want to conclude by outlining the different tooling, which can be used for migrations to SAP S/4HANA within a greenfield approach.
The Migration Cockpit is a new tool created especially for the migration towards SAP S/4HANA. It is the only tool, that can be used as well for the migration towards SAP S/4HANA Cloud ES (essentials edition). More on this solution and the supported objects can be found in the following links:
The available migration objects can be found using the following link:
Please check the right version for your target system and change it if required on the top of the page to understand all available objects for your release.
Other solutions to support the migration are data services and the accelerated database migration provided by Syniti.
Last not least I have seen some customers, who had people experienced with LSMW, who used this tool for some specific data-objects.
Please check the following note if you consider as well to use the LSMW:
For more details on the available solutions please check the following blog from Corrie Brague and the related links in this blog:
More details on the migration cockpit can be found in the blogs of Jacek Klatt and Zunaid Hingora:
The Selective Data Transition to SAP S/4HANA Approach (SDT)
From the previous discussions we take the following key points:
A Greenfield Approach will often turn out to be the most complex alternative for a transition to SAP S/4HANA. As well with this approach no historic data can be migrated.
A System Conversion is a far more straightforward project, but you will lose the flexibility for the redesign of your processes.
Therefore, as an alternative, the Selective Data Transition to SAP S/4HANA has been developed. The Selective Data Transition comprises two sub-scenarios:
- Shell Creation and Conversion
- Mix and Match
I will outline both scenarios in the following:
Shell Creation and Conversion
The basic idea behind the Selective Data Transition is to start your new SAP S/4HANA solution from your existing SAP ERP-solution but to allow more flexibility for changes compared to a system conversion.
How do you achieve this?
The fundamentals of this solution are straightforward:
We start with a shell-creation of your current SAP ERP-solution, which leaves you with an empty system just containing the configuration, but all transaction and master data are stripped (step 1 in the below diagram). Configuration means: This system holds customising and repository objects but nothing else. This system will be converted to SAP S/4HANA using a normal system conversion (step 2).
As there are no data within this system you can apply any changes to the configuration of your new empty SAP S/4HANA system, that you will need. E.g. you can adapt your financial model or your controlling settings towards your future requirements. By this you will define your new golden system as a starting point for your SAP S/4HANA solution (step 3).
You will take a copy of this system to build up your new target system (step 4).
The next step will be the data-migration (step 5). For all areas, where you didn’t apply fundamental changes it will be possible to migrate as well historic data and change them on the fly towards the new SAP S/4HANA structures. For these areas data will be migrated on table level and the on the fly changes necessary for SAP S/4HANA will be executed in special afterburner programs – these will be the same or similar to those programs, that are executed during a normal system conversion for SAP S/4HANA.
For those areas, where you need fundamental changes, other migration methods will be used, that populate the data in a secure way using the interfaces of the system – therefore for these data no historic documents can be posted. However, if e.g. you need only few changes in logistics but fundamental changes in finance, it will be possible to migrate historic data in logistics but not in Finance.
In this case it will still be possible to connect a logistics document with a related open finance document.
Use cases for Shell Creation and Conversion
Let’s get some examples or use cases for the Shell-Creation and Conversion Approach:
This is one of the most used scenarios. Suppose you have 10 years of data within your system but for your current processes you may need only the last two years. Therefore you would like to have the older data completely stripped off during the migration to SAP S/4HANA. The Selective Data Transition to SAP S/4HANA is the perfect solution to achieve this! You do not need to redesign your existing solution – but you can just use the flexibility of the Selective Data Transition approach to strip of the old data. If you want to make your old data available for auditors you may consider to use SAP Information Lifecycle Management for these purposes.
Selective Company Code Transfer:
In case you do not move with your complete company codes to SAP S/4HANA at once but only with one or some company codes, you will go for this scenario. Of course, this scenario can also be combined with a time-slice scenario.
The Selective Company Code transfer is used e.g. in M&A scenarios or as well for large cooperation’s, who do want to use this scenario to slice the overall transition to SAP S/4HANA in several pieces. Within such a slicing scenario you should not underestimate the workload to set up temporary interfaces, if parts of the companies are already on SAP S/4HANA while others still remain on the SAP ERP-solution.
Of course in real life things can get more complicated and you need a combination of the time-slice and selective scenario. As well selection criteria for organizational units might be more sophisticated than just using complete company codes.
For this purpose the data-scope engine has been developed as a part of the SDT approach. There is a really nice blog, which by my colleague Matthias Stegmüller, which goes into more details of this:
Adaption and Selection Scenario
This is the most used scenario within the SDT-Approach. In this scenario you require changes for certain areas of your system, that cannot be accomplished during a system conversion.
For example, I have seen a number of customers who are still using a classic general ledger with a parallel accounts model and want to change to a parallel ledger solution and, for example, implement a document split solution. In the logistics area, however, only minor changes to the existing solution are required.
We can now offer two solutions for this approach:
- We can migrate the financial data from the old classic accounts model to a ledger model and also take over the history.
- Hybrid approach:
The logistics data can be fully migrated including historical data, but for the financial area only open items and master data are migrated.
The first scenario is often combined with a time-slice approach where we only migrate the last two or three years of history. The following requirements must be met:
- No archived FI documents exist in the relevant time slice.
The time slice always starts at the beginning of a fiscal year.
The balance carry forward can be repeated for all relevant fiscal years in the target system.
FI transaction data in the source system is reconciled.
The objective of this approach is to replace the accounts approach with the ledger approach for parallel accounting. Other scenarios are not covered, e.g. no FI-SL, PCA or other ledgers are migrated to standard ledgers as part of this solution.
All open item managed accounts are deemed relevant to all ledgers.
If the above requirements cannot be met, or if the history of the financial data is not required, the hybrid approach is used:
The logistics data can be fully migrated including historical data, but for the financial area only open items and master data are migrated.
Unfortunately, there is no standard solution for moving from a parallel accounting model to a parallel ledger once you are in SAP S/4HANA, such as the NewGl migration in S/4. However, SAP can provide a specific service for this.
My recommendation is that if you want to change your financial model, you should do it together with the migration to S/4HANA or even before in ECC using the NewGL Migration.
Mix and Match
While the SDT-Approach is a way to make a system conversion approach more flexible, the Mix and Match Approach is an option to enhance a Greenfield Approach so that you can retain and safe those parts of your configuration, that do not need any change.
Compared to a Shell Creation Approach this approach is used much less. However my observation will be a bit biased here, I will explain later why.
The basic idea of the mix and match scenario is to start with a greenfield approach but to retain your old solution for specific solution areas, where your current SAP ERP-solution has proved to fit as well your future demands.
As you want to retain some parts of your current solution, you will first identify and fix these parts. (Remember: still today in the days of Agile one of the biggest reasons for project to overrun budget or to fail completely is unclear or permanently creeping scope).
After the identification of those solution areas, that you want to bring over to your new SAP S/4HANA Hana system you have to decide, how you want to perform this:
There are two possibilities:
- You manually add the configuration to the new SAP S/4HANA Hana solution
- You will migrate / transport the solution by means of some tooling
Details on option 1:
You you will need experienced consultants who configure the solution manually in the target system.
Details on option 2:
Option a): If there are no or minor changes between SAP ERP and SAP S/4HANA you may transport the customizing directly from SAP ERP to SAP S/4HANA and rework the customizing manually in the target system.
Option b): If there are bigger changes between SAP ERP and SAP S/4HANA, you may perform a Shell-Creation of your SAP ERP-System, and convert this to SAP S/4HANA.
Now you have the basis, from where you can transport the solution to your new SAP S/4HANA solution.
Also in this case you will manually rework and fit the transported elements within your SAP S/4HANA solution.
There is a special option available to cherry-pick customising entries and transport them using a special toolset. The transports can be done both from an SAP ERP-system or / and a SAP S/4HANA-system as a starting point. However, this is a semi-automated solution as you will need to manually check, whether the transported items really fit and integrate into the target solution. In case you are interested in a service, that contains this solution, please turn to firstname.lastname@example.org. The Basis of this solution is the MCDelta-Solution, which is also used for system-comparison and in the area of central finance.
This service requires specialists for this specific solution, which need to be scheduled specifically, therefore this service is only available for limited customers. It is currently not planned to make this service available for all customers.
Last not least in both cases, final tests have to be performed to guarantee, that the transported customising fits seamlessly into your new SAP S/4HANA Hana solution.
Also for option 2 there are manual steps involved that will require experienced consultants. Therefore, in those project discussions, where I have been involved, after looking into the details, always option 1 was chosen.
And of course, for this solution no special tooling is needed. Now we see, why my judgement on the Mix- and Match approach may be biased:
In most cases, no special tooling is needed for this option but only experienced consultants. Therefore, customers with need for this approach will not turn to DMLT and we have no understanding of how often this approach is really chosen.
Or to put it differently:
The Mix- and Match-Approach is differently to the Shell-Creation-Approach a conceptional approach, that does not require any specific tooling.
What happens to historical data not migrated?
I see quite a few customers planning to keep their old ECC system running for some time – to be able to audit old processes or to keep it for other audit processes. However, this is not a long-term solution, and SAP’s strategic solution for decommissioning legacy systems is SAP ILM (Information Lifecycle Management).
With this system decommissioning solution, you can preserve all the data from your legacy systems – it doesn’t even have to be an SAP ECC system.
If you want to learn more about this, I recommend you read our blog on system decommissioning:
Testing is always a major concern in S/4HANA migration projects. Therefore, we have developed the Validation Framework to reduce the testing effort. If you are interested in more details, please have a look at the following blog:
For those customers, who can not convert their system using the SAP S/4HANA system conversion approach, but who do at least want to take over some of their configuration to the new SAP S/4HANA Solution, the The Selective Data Transition to SAP S/4HANA will be the right approach. If you want to take over most of your current configuration, the Shell Creation and Conversion option will be the right one, otherwise the Mix and Match Option is more appropriate.
If you have further questions please ask them in a comment. As well if you need more information about the SDT approach please check the following link and the related information:
If you want advice or support within you SAP S/4HANA Hana migration project you may also reach out to the following email: mailto:email@example.com.
If you liked this blog I’m thankful if you share this post in your network and/or if you make use of the like-button ;-).
How is the shell creation for big systems are managed
Thanks for this article @heinrich.stroetmann
I referred to Amin's this article too regarding the shell creation. The suggested approaches are to use DMLT or reach out to partners such as CBS, Natuvion,SNP and Datavard.
Since the shell systems exclude only transaction and master data and hold system relevant data and customizing data only, this can be achieved by system installation followed by client copy (customizing). I want to know how will the shell system build this way differ from the ones created by the assistance of partners?
Shell Creation is a special tool that we have developed, based on a system copy approach. Basically the system copy approach was modified to omit all transaction data and master-data tables.
with the approach of a system installation followed by a client copy(customizing) you can not achieve the result of a Shell Creation. With such an approach you will loose all repository data - however the Shell Creation approach retains the repository data.
The SDT is basically a copy of the SNP Bluefield approach.
The SDT builds on the development and project-experiences of over 20 years on migrating and merging SAP-systems performed by our SLO group (SLO = system landscape optimization) which transitioned into the SAP DMLT organisation(Data Management and Landscape Transformation). Based on the experiences our tooling was enhanced to migrate as well to S/4 Hana, it is definitely not a copy of the Bluefield approach however I have to admit that SNP has been doing more in advertising their approach than we, so that this copy-impression is generated at some people.
Hi - Really interesting and thanks for providing the fruitful artifacts about S/4H Transition, precisely in SDT.
Do we have any strategy/methodology to be considered in "Cherry Picking Customizing Transfer" under "Mix & Match" scenario?
Do we have any use case / case study ?
Update about switching from account to ledger solution in S/4HANA:
At a customer we have done an S/4HANA system conversion and then as subsequent projects
1) the introduction of 3rd currencies and
2) implementing parallel ledgers, including changing from an account-based to a ledger-based model and replacing special purpose ledgers.
Both of the subsequent projects were done with a downtime-minimized approach with technical downtime < 1 hour.
The work was done with the help of the SAP DMLT and SAP MaxAttention organizations, with very moderate efforts (the complexity will, of course, depend on the individual situation).
So these topics are no longer showstoppers for the system conversion path.
Hi Heinrich Stroetmann
What will be an ideal way, if the source system a non-unicode one. Will the shell creation and conversion support non-unicode source systems
the Shell Creation can also support non-unicode systems. For the conversion of the shell-system the standard system conversion is used. That means, if the shell-system is not a unicode system, the shell system would need to be converted to unicode before the S/4 Hana conversion.
The data-migration from the source system to the new Shell system can also be performed, if the source system is a Single-Code-Page system.
If the source system is a MDMP-system, than the migration of the data would be much more complex.