Retrofit in SAP is one of the most under-discussed topics in SAP transformations. When I gave a keynote at the SAP ALM Summit APAC, in front of more than 700 people, their response confirmed this.
But the most telling moment came after I stepped off-stage. The booth quickly filled with people asking the same question: Can you retrofit while you are transforming to the Cloud?
And the answer is yes, with Rev-Trac. But the bigger surprise was how many teams didn’t yet realise there’s more than one way to do it.
There are two types of retrofit in SAP
During my keynote, I discussed the two different types of retrofits.
Technical retrofit: this is the scenario that most SAP teams are familiar with. When two environments hare the same underlying codebases, a change can usually be transferred from one to the other with high reliability.
Functional retrofit: the second type of retrofit is what Rev-Trac has coined a functional retrofit. A functional retrofit becomes essential during a RISE Migration, when an organization is moving from ECC to S/4HANA. Here a technical retrofit won’t work, because the codebases are different. Simply moving the original transport into the S/4HANA project environment could introduce incompatible code, unnecessary customization, technical debt. What needs to carry over isn’t the code, it’s the business requirement behind it.
How this plays out in practice
Rev-Trac has a built-in solution for handling a functional retrofit. It’s done through a capability called cloning. It clones the business requirement itself and places it into the S/4HANA project landscape. Incompatible transports are removed and the delivery strategy is dynamically updated to align with the project’s delivery approach.
This gives the S/4HANA project team a controlled way to deliver the requirement without automatically recreating unsuitable ECC custom code. The business requirement is carried forward, without assuming the original technical implementation should be carried forward with it.
Why retrofit is a business safeguard, not a technical checkbox
Most large enterprises aren’t moving to the Cloud overnight. They’re running ECC and S/4HANA in parallel, often for years. During that time, the live environment doesn’t stand still. Changes continue to come through. New requirements emerge. Regulatory updates must be delivered. Business-critical fixes can’t wait for the transformation to finish.
That’s exactly the gap retrofit in SAP closes. At its simplest, it’s how you keep parallel landscapes aligned, so a change made in one environment is carried across to the other. Without it, the gap may not become visible until go-live, when the organization discovers that an important capability, regulatory update, or process change was never carried forward. In a regulated world, that isn’t an inconvenience. It’s a serious problem.
Retrofit isn’t a technical afterthought. It’s a business safeguard. Sometimes that means transferring the technical change as is. Sometimes it means cloning the business requirement and delivering it differently in the S/4HANA environment. Either way, the goal is the same: nothing important disappears between the landscape you are running today and the one you’re building for tomorrow.
The conversation needs to change
My biggest takeaway from the SAP ALM Summit APAC was simple: people understand that retrofit in SAP matters, but many still don’t realize that there is more than one way to do it.
If your organization is running ECC and S/4HANA in parallel, retrofit isn’t a side task, it’s a critical piece of your transformation strategy.
Talk to us about how getting retrofit right can safeguard your business, starting now.
