Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
chris_drake
Explorer
An SAP S/4HANA migration comes with risks. The most significant risk is dual maintenance between legacy systems and the new SAP S/4HANA environment. Unless you adopt a greenfield approach to your S/4HANA, you must maintain your legacy SAP systems until the cutover.

The objective of dual maintenance is to keep your legacy system and your SAP S/4HANA systems in sync to avoid change freezes and unscheduled downtime. An automated retrofit approach to your SAP S/4HANA migration significantly reduces the time, effort, and risk to ensure SAP changes are synchronized in parallel across the dual system landscapes.

A proper retrofit of SAP changes significantly increases the likelihood of a successful SAP S/4HANA go-live. Improper dual landscape synchronization and change adaptation could lead to system downgrades and disastrous results.

In this blog, you will learn:

  • Why an automated retrofit approach is critical until you switch on your S/4HANA system

  • How to automate your retrofit process and accelerate your SAP S/4HANA migration

  • What you need to consider when retrofitting SAP changes



Keeping your legacy and SAP S/4HANA environments in sync helps to avoid costly downtime 


Why retrofit automation is the key to a successful SAP S/4HANA migration


The question is, “How do you maintain your legacy system while shifting your focus to migrating to SAP S/4HANA?” The short answer is automated change synchronization. When faced with the challenge of supporting an ECC system and building the new SAP S/4HANA environment, anything that can be automated should be automated. That includes how to retrofit your SAP changes to ensure dual maintenance while navigating your SAP S/4HANA journey.

System downgrades commonly occur when introducing changes or new functionality to the legacy system during an SAP S/4HANA migration. Transitioning is not a simple lift and shift.

The complexity of your ERP landscape and the collaboration between the teams involved can impact how quickly and safely you make the cutover. Industry experts predict at least 2-6 months through to 24+ months for organizations taking a measured approach to their SAP S/4HANA migration.

Whether you adopt a big bang approach or take it slow and steady, BAU changes and functional updates will inevitably be introduced into legacy systems. The types of changes and updates include:

  • Functional Upgrade -- introducing new functionality available on SAP BTP as part of your scope

  • Technical Upgrade -- make the minimum changes and introduce recent functional changes post go-live


You must include these changes, or at the least consider them for inclusion in the new environment to avoid functional downgrades after the cutover. The best practice is an automated dual maintenance approach (or digital synchronization of SAP changes).

Get on the fast track to an automated retrofit approach to change synchronization


Automating the retrofit of SAP changes helps lower the risk, breaks down siloes, and accelerates your migration project. Using the right tool allows you to effortlessly keep legacy and new systems updated and in sync while the transition progresses. A more advanced SAP change management solution will have built-in features that automate dual maintenance.

It is critical to consider your custom code when transitioning to SAP S/4HANA. Will it be compatible with the new system or present a hurdle that could lead to costly downtime?

Consider two scenarios:

  1. SAP S/4HANA compatible custom code


When you move to SAP S/4HANA, all changes that progress across your ECC should be run through ABAP Test Cockpit (ATC) to ensure it is suitable for use in the new environment.

Utilizing an appropriate automated change management tool will send any changes introduced into production during the digital transformation project for review and automatic reapplication into SAP S/4HANA. Retrofitting becomes a simple accept/reject exercise, minimizing the effort and significantly reducing the risks to the SAP S/4HANA upgrade project.

2. Custom code incompatible with SAP S/4HANA

However, not all custom code is compatible with an SAP S/4HANA system, which is where it becomes tricky. In this instance, an automated reapplication process is ruled out. It’s a challenge, yet it doesn’t have to harm your new environment.

With a suitable change automation tool, you can generate work orders to avoid losing functionality and ensure the incompatible code is reviewed for manual adjustment in the SAP S/4HANA system.

Dual maintenance and automated retrofit: Other Considerations


Whether you adopt a Bluefield or Brownfield approach to SAP S/4HANA, you must identify which ECC changes are candidates for reapplication into the new system.

When assessing changes to reapply to SAP S/4HANA, you have three options:

  • No, I don't need this change

  • Yes, this change needs to go to production, and we can use the original ECC change

  • I need this, but I can't use the ECC change. I'm going to apply the change manually


For reapplication to the SAP S/4HANA system, having a link back to the original ECC change is crucial. You need to understand how the change was implemented and its rationale.

Mapping an ECC change to the future implementation in SAP S/4HANA ensures a link to the original request. A good change management tool will synchronize these so that they remain intact.

While checking your custom code for compatibility when migrating to SAP S/4HANA is crucial, there are instances when you need to bypass the process. A flexible change management workflow process is of real value in these scenarios.

It enables SAP IT teams to cater for anomalies and variations that don’t allow for checks for compatibility and consistent reapplication to your new SAP S/4HANA system. For example, these are two instances when you would bypass safety checks and code suitability analysis:

  1. Emergency Changes: These changes are needed in production immediately, so you don't have time to run an SAP S/4HANA readiness check

  2. Configuration changes for Brownfield SAP S/4HANA transformation: These changes cannot be assessed for suitability in the target system and should be excluded for a speedy change process to production


What about SAP BTP?


Undoubtedly, some businesses will leverage SAP BTP to keep their core clean in their SAP S/4HANA environment. Keeping the core clean in this context means keeping the core SAP S/4HANA system free of customization. A clean core is essential for ensuring stable and reliable operations during the SAP S/4HANA build and post go-live.

Instead of retrofitting ECC changes with your SAP S/4HANA system, you would use native BTP capability for the requirement.

While this is a possibility now, custom code is anticipated to be primarily deployed to SAP S/4HANA instead of BTP. Code is likely more compatible between ECC and SAP S/4HANA than BTP, which will, in all probability, use alternative technologies to ABAP.

The Bottom Line: Automatically retrofit SAP changes for a successful shift to SAP S/4HANA


For most organizations, an SAP S/4HANA migration involves maintaining your legacy ECC system for a period while focusing on building the new environment. Dual maintenance between your ECC and SAP S/4HANA systems minimizes costly unplanned downtime and helps keep your project on schedule. The foundation of dual maintenance is dual synchronization (or retrofit).

With automation, retrofitting SAP changes to keep dual landscapes in sync becomes more practical. There’s less risk of costly mistakes, and required changes are delivered seamlessly across the two technology platforms.

In the next and final post in the series, “How automated change management smooths your transition to SAP S/4HANA”, I will look at the challenges of SAP S/4HANA migration and how it can impact time, resources, budgets, and business continuity.

 
Labels in this area