This article looks at the various approaches available to migrate your SAP or legacy system to S/4HANA. This assumes you have already decided that S/4HANA is for you. If you’re still weighing up S/4HANA or would like to know more then please check out our previous article – getting to grips with S/4HANA in 3 easy steps.
What is S/4HANA?
By way of a short overview, S/4HANA (S4) is SAP's flagship in-memory ERP solution (SAP S4 site). S4 allows you to be more strategic in your business decisions and gives you the tactical ability to quickly respond to opportunities and threats. Big Data, Simplified process, and Mobile integration.
S/4HANA Migration Approaches – The Basics
There are several approaches to implementing S4. They all fall broadly into the following four main options:
- SAP New Implementation (Greenfield)
Least complex option, essentially starting from scratch. Data load is something to keep in mind, it can take a long time with SAP tools. - SAP System Conversion (Brownfield)
Update your current system. The more bespoke it is, the more effort this approach will take. - SAP Landscape Transformation
Appropriate if you’re looking to consolidate or carve out systems/geographies. - 3rd Party Approaches (e.g. SNP's Bluefield)
Allow for more selective data migration and tailored service.
S/4HANA Migration Approaches – The Detail
Now you’ve got a high-level view of these, let's drill down into the detail. In the next few sections I’ll look at each approach, specifically:
- What is it?
- When to use it?
- The pros and cons.
Approach 1 - SAP New Implementation (Greenfield)
What is it?
It’s best to think of this as a brand-new SAP implementation, even if you’ve been running SAP for years. This approach will ignore your current system and while you may model your existing processes in S4, you won’t be leveraging any of your existing config or custom code.
When would you use it?
- When you’re migrating to leverage new functionality (e.g. mobile integration).
- When you’re migrating from a non-SAP legacy system.
- When you’re migrating from a complex SAP system.
- When you’re implementing S4 as part of a business change initiative.
What are the pros?
- You get the benefit of all S4 has to offer - Big Data, Simplified process, and Mobile integration.
- Wipe the slate clean - More often than not, SAP implementations go live with a compromised solution that is very difficult to correct or undo. This could be due to the functionality available, the original project timescales, the sheer effort required to implement your ideal processes, the defects that were supposed to be fixed in live… you get the picture. This approach allows you to at least aim for best practices.
What are the cons?
- Let’s not pull any punches, you’re implementing SAP! This will be time-consuming and require significant buy-in from both business sponsors and end-users. It is highly likely that this approach will fundamentally change the daily working habits of your employees.
- Copying data from your current ERP system will be time-consuming and will create a lot of work for your data team. “But my data is in great shape, we’ve got experience with complex ETL procedures and our DBAs are amazing” – This might be true, but even with all of that, you need to budget a lot of time and effort from your already busy data team.
- Realistically it is going to take 12 – 18 months.
- Your existing regression test assets will no longer be applicable and will have to be rebuilt from scratch.
Approach 2 - SAP System Conversion (Brownfield)
What is it?
At its simplest, this is a technical upgrade of your current SAP ERP solution. It uses the SAP standard SUM DMO tool (Software Update Manager – Database Migration Option). Once you’ve made this step, you can proceed to edge towards full S4 at your own pace. According to SAP analysis, this is the most common approach with over 50% of customers choosing a Brownfield implementation.
When would you use it?
- When your organization has the appetite to move to S4 eventually but doesn’t have the time, budget, resources, or business case to undergo a greenfield migration.
- When you’re not looking, or not able to change any business processes but want the benefits of the HANA DB (Big Data).
What are the pros?
- Protects investments made in your existing system. This includes all of your config and custom development that you’ve spent the last few years sorting out and have finally got working.
- End-users see little to no disruption – this should never be underestimated!
- A step-by-step approach toward S4 allows you to proceed at your own pace.
What are the cons?
- If you’re at EhP 0 – 6 you will need to upgrade to at least EhP 7.
- You will need to convert to Unicode if you’re not already.
- You won’t get the process/functional benefits – I have heard this described as ‘All of the pain, none of the gain’. I don’t fully subscribe to that view, but it does help frame this approach
- If your data quality is poor then this approach will be more time-consuming.
Approach 3 - SAP Landscape Transformation
What is it?
Carving out or consolidating. This approach takes multiple SAP and/or Legacy systems and brings them together into a single S4 instance… or it can take a single SAP or Legacy system and carve out an area of that solution into an S4 instance, leaving the rest of the previous system intact. Generally, a ‘vanilla’ S4 instance will be created and then you’ll migrate your data into that system as required.
When would you use it?
- If you are divesting business units or subsidiaries.
- If you have made mergers or acquisitions and want to consolidate disparate systems.
- If there are specific business units that you want to move to S4.
What are the pros?
- Potentially increase the operational efficiency and value of units you are aiming to divest.
- Allows a phased/trial approach to migrating.
- Limits the impact to areas of your business you are not migrating.
What are the cons?
- A lot of effort and complexity, especially around data.
- Requires specialist SAP resources and tools.
Approach 4 - 3rd Party Hybrid Approaches (Bluefield)
What is it?
An approach offered by a number of 3rd parties including SNP, CBS, Natuvion, and Datavard. They’ll spin you up a basic S4 shell, ETL any data you want to keep from your original system, lift and shift your config and custom code and then make it all work together.
When would you use it?
- When there are some useful data and code in your current system, you want to cherry-pick elements and clear out any redundant items.
- When you want to minimize downtime.
What are the pros?
- You get the benefit of all S4 has to offer - Big Data, Simplified process, and Mobile integration.
- Protects your investment in any key customizations.
- Gives you a clean S4 system, free from any unnecessary data, code, or config.
What are the cons?
- There will be parallel running of multiple systems during the project; you will have to ensure relevant changes are updated in both systems.
- Requires specialized and very expensive tooling.
- A very high effort for both ETL and code/configuration migration.
Conclusion
As we’ve seen there are 4 main approaches to an S4 migration. The vast majority of migrations will fall into these categories and each is appropriate for very distinct scenarios, with their own pros and cons.
Hopefully, this article gives you some ammo when dealing with internal stakeholders or wannabe external providers. Ask your stakeholders, what are the main drivers? What do you want to get from S4? Ask potential providers about your data, config, and custom code and how they would approach a migration.