Beyond ChaRM: The Future of SAP Change. Find out how we can help!

This article is also available in

Migrating to SAP S/4HANA presents many challenges, but one stands out above the rest: dual maintenance between legacy SAP ECC systems and the new SAP S/4HANA environment.

Unless you adopt a Greenfield approach to your S/4HANA, legacy systems must remain operational until the final cutover.

Why dual maintenance is critical during an SAP S/4HANA migration

The objective of dual maintenance is to keep your legacy system and your SAP S/4HANA systems synchronized, avoiding:

  • Change freezes
  • Unscheduled downtime
  • Function downgrades
  • Transport conflicts

An automated retrofit approach to SAP S/4HANA migration significantly reduces time, effort, and risk to ensure SAP changes are synchronized in parallel across the dual system landscapes. 

Without proper dual landscape synchronization, organizations risk introducing changes in ECC that are never re-applied to S/4HANA, leading to missing functionality or system regressions after go-live.

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

Supporting an ECC system while migrating to S/4HANA is one of the most challenging aspects of a digital transformation.

The short answer to overcoming the challenge is automated change synchronization.

When supporting an ECC system and building the new SAP S/4HANA environment, anything you can automate, you should – including the retrofit of SAP changes.

System downgrades commonly occur when ECC changes or new functionality are introduced during an SAP S/4HANA migration but are not correctly assessed, adapted, and re-applied to S/4HANA. The transition is not a simple lift and shift.

The complexity of your landscape and the degree of collaboration between teams involved impact how quickly and safely you make the cutover. Industry experts predict migration timelines to stretch from 2-6 months through to 24+ months for organizations with a measured approach to their S/4HANA migration.

Managing BAU changes during an 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 the BTP
  • Technical upgrade – make the minimum changes and introduce recent functional changes post go-live

Each change must be evaluated for inclusion in the S/4HANA environment to avoid functional loss after the cutover.  

The recommended approach is automated dual maintenance, also known as digital synchronization of SAP changes. 

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

How Rev-Trac automates dual maintenance and retrofit

When one or multiple SAP development tracks run in parallel, every Production change must be re-applied to each parallel track. Automatic retrofitting reduces risk, breaks down siloes, and accelerates your migration.

Rev-Trac enables organizations to:

  • Automatically clone SAP changes and updates
  • Evaluate cloned changes for re-application (retrofit) into parallel development tracks
  • Keep ECC and S/4HANA systems in sync until final cutover

Handling custom code during S/4HANA migration

Migration to SAP S/4HANA presents challenges when it comes to dual synchronization. Will it be compatible with the new system or present a hurdle that could lead to costly downtime?

Custom code plays a critical role in determining how retrofitting is applied.

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.   

Rev-Trac integrates with the ATC for S/4HANA Readiness Checks. This check helps determine the suitability of the cloned change for retrofit. If the code is S/4HANA compatible, retrofitting becomes a simple accept/reject exercise, minimizing the effort and significantly reducing the risks to the transformation project.

Where possible, we advise you to use the S/4HANA Readiness Check in the ECC DEV system to allow developers to fix the change before releasing the transports.

Custom code incompatible with SAP S/4HANA:   

Not all custom code is S/4HANA compatible, which is where it becomes tricky.

In these cases, an automated reapplication process is ruled out.

Rev-Trac:

  • Queues work orders from the ECC as outstanding items
  • Ensures incompatible code is reviewed for manual adjustment in the S/4HANA system

Dual maintenance and retrofit for Hybrid and Brownfield approaches

Whether adopting a Hybrid (Bluefield) or Brownfield approach to S/4HANA, you must identify which ECC changes should be reapplied to the new system.

Each change typically falls into one of three categories:

  • No longer required
  • Reapply as is
  • Required but change must be manually adapted in the S/4HANA system

Maintaining a link to the original ECC change is crucial for reapplication. You need to understand what the rationale for the change was and how it was implemented. With Rev-Trac, every SAP change is tied to a Rev-Trac Request, which groups transports, related documentation, approvals, and audit history.

Mapping an ECC change to the future implementation in S/4HANA ensures a link to the original request. Rev-Trac synchronizes these so that they remain intact.

When to bypass custom code compatibility checks

There are instances when you need to bypass checks for compatibility to cater for anomalies and variations.

A flexible SAP change management workflow is critical for handling exceptions, including:

  • Emergency changes are required in Production immediately, so there is no time to run S/4HANA Readiness checks
  • Configuration changes for Brownfield transformation that can’t be accessed for S/4HANA suitability and should be excluded for a speedy change process to Production

What about SAP BTP and clean core?

Many organizations adopt SAP BTP to support a clean core, keeping the core S/4HANA system free from customization. A clean core is essential for ensuring stable and reliable operations during the S/4HANA build and post go-live.

Instead of retrofitting ECC changes, functionality can be delivered using native SAP BTP capability, supporting a clean core. While you can do this today, it’s expected that most custom code will be deployed to S/HANA rather than BTP.

FAQ: SAP S/4HANA dual maintenance and automatic retrofit

What is dual maintenance in an S/4HANA migration?

Dual maintenance refers to keeping your legacy ECC system and the new S/4HANA system in sync until final cutover.

Why is automated retrofit important for S/4HANA migrations?

Automated retrofit eliminates manual, error-prone, and time-consuming tasks required to reapply relevant ECC legacy system changes to the S/4HANA environment. It reduces risk, unscheduled downtime and post go-live regressions while accelerating your migration.

How does Rev-Trac support dual maintenance?

Rev-Trac automatically clones Production changes and re-applies compatible changes to S/4HANA landscape, keeping both landscapes synchronized as the migration progresses.

Can Rev-Trac prevent functional regressions after S/4HANA cutover?

Yes. Rev-Trac ensures ECC changes are evaluated and selectively retrofitted to S/4HANA. This helps prevent missing functionality, overwrites and regressions after S/4HANA go-live.

The Bottom Line: automate retrofit to de-risk your SAP S/4HANA migration

Most SAP S4/HANA migrations require supporting ECC systems for an extended period until the cutover. Dual synchronization (or retrofit) is critical to maintaining your legacy system while building the new environment.

Rev-Trac automates the retrofit process by selectively re-applying automatically cloned changes to the parallel S/4HANA track. This helps organizations to:

  • Minimize downtime
  • Avoid missing functionality
  • Accelerate S/4HANA migration

Discover how Rev-Trac simplifies dual maintenance and retrofit. Contact one of our SAP change management experts.