ECC to S/4HANA migration: Greenfield vs Brownfield from integration perspective

It’s Friday. The sun is shining and the coffee is in the cup. You sit at the desk of your home office and remember the times when you spent 2 hours per day just to get to your box in a huge office complex and couldn’t wait for lunchtime so you could get out of the box for a little bit. You pinch yourself to check if you haven’t fallen asleep on the bus and the pinch brings you back to reality – your IT director was asking for a rundown of your next big project: S/4HANA migration.

The greenfield vs brownfield approaches have been discussed many times and any decent SAP implementation partner will help you select the best one according to your needs. In this article, we will look at both approaches, but from an integration point of view. A quick summary of what to keep in mind as such a huge event as S/4HANA migration will leave very noticeable marks on your overall IT infrastructure.

Why greenfield? 

The Greenfield approach means an entirely new implementation of S/4HANA. This facilitates full process redesign and system reengineering. Companies often choose not to take this path to secure previous investments and/or to avoid endless discussions on “how the new approach is not even close to the old approach (even if the old approach used to be the worst thing ever)”. The Greenfield approach is not simply “something that SAP made us do and pay for it”. If you have to do it anyway, why not get the most out of the project and come out with something that will support your business for years to come?

How is the API platform easing the pain here? 

1. Once the API platform is included in the initial architecture it facilitates a smooth transition for all systems. You can integrate all your systems with the new S/4HANA in a very natural way.
2. Decrease lead-time and dependency from S/4HANA deployments for surrounding systems: Instead of teams idling while some parts of S/4HANA are completed/deployed/process changed/etc, surrounding systems can build integrations to the central integration/API platform and start testing these integrations. Once respective functionality is ready, it is a question for integrations and S/4HANA teams to align, not to align with everyone that might be involved
3. The landscape will change with the new process. More often than not the surrounding systems wait their turn for the 2nd phase. Instead of spending resources integrating systems that will be replaced, you can simply integrate S/4HANA with API platform and any future changes will have noticeably less impact on your instance
4. Support for API economy and simple SaaS onboarding from Day 1.

Why brownfield? 

Brownfield approach is like a software update – you get to keep some or all of your legacy systems, but you still have to adjust and implement some of the business processes to allow new S/4HANA to work as intended. The downside with this approach is that you have to fully rebuild all previous integrations between Legacy and ECC to S/4HANA. 

In both Brownfield/Greenfield approaches you will have to invest a lot in adjusting the integrations. The difference is that with Greenfield you are building integrations according to your new process while in Brownfield you are trying to adjust them to the existing landscape. API platform does the heavy lifting to decrease the overall time/cost of this activity. 

Brownfield approach allows you to save on data migration as mostly the data remains the same and doesn’t need to undergo heavy transformations. The same goes for surrounding systems – companies with strict uptime requirements often decide to postpone any other major upgrades until S/4HANA migration is done.

How is API platform easing the pain here? 

While the thought of rebuilding all your integrations for fresh S/4HANA installation seems as bad as rebuilding all your integrations for ECC->S/4HANA migration and then doing a “BIG BANG” seems equally painful, the brownfield approach does deliver some benefits in terms of business continuity and save of investment. And even in this case, you can think of API platform from this point of view: “If I need to rebuild all my integrations anyway, if I need to spend all the resources no matter what, why shouldn’t I get something out of it, like modern landscape that will guarantee the business continuity for years after”. 

In conclusion

ECC to S/4HANA migration is a major step that companies using ECC will have to take. It is a huge and costly exercise and should be executed only after a clear roadmap has been created, presented, and agreed on. Furthermore, a very detailed and precise analysis of current and future states should be created and discussed as mistakes, especially in later stages will cost a lot of resources and time to fix. During the analysis process, you have to consider each decision not only short term but how it will impact your business in the long term. 

1. Will my new landscape support my business in 1, 5, or 10 years?
2. How S/4HANA work with legacy systems?
3. How will it work in various environments at once (on-premises, private cloud, public cloud, hybrid cloud)?
4. How easy is it to onboard new APIs, SaaS, other data sources, etc.?
5. Is the business being supported (not only do they get the latest and coolest S/4HANA, but they can actually use all of the IT stack to reach the business goals)?
6. Are my new processes supporting our new business processes?
7. How long it will take to rebuild all my integrations? Can it be done better/faster/smoother?
8. Will my integrations have all the functionality to support my business (monitoring, control, flexibility, etc.)

To answer these questions and any others that you might have regarding API platforms and how they can help with your migration struggles, get in touch and we will be more than happy to help!