Beyond the Retrofit: The 90-Day Sprint to a Clean-Core for a Risk-Free S/4HANA Migration

Posted on November 17, 2025
SAP BTP
By Sam Rathod
465 Views

Your SAP S/4HANA® transformation is stalled. The project plan is bleeding red, the budget is frozen, and the steering committee is demanding answers. You’ve been told for years that the S/4HANA move is a complex but manageable technical upgrade. So, what went wrong?

The answer isn't S/4HANA. The problem isn’t the new data model, the Fiori front end, or the business process re-engineering.

The problem is your 20-year-old custom code. It’s the millions of lines of ABAP—the Z- objects, the in-core modifications, and the clones of standard programs—that have been quietly accumulating technical debt for decades. In the move to S/4HANA, that debt has just been called due.

This custom code is the single biggest point of failure in any SAP transformation. But the solution isn't a 24-month manual "retrofit" project. The solution is a strategic, surgical, and rapid modernization. At ROI E-Solutions, we call it the 90-Day Clean-Core Sprint, a proven methodology that shifts your logic, retires your risk, and gets your upgrade back on track.

The Real Villain: The "Dirty Core" and Retrofit Hell

For decades, the unwritten rule in the SAP world was "when in doubt, customize." If a standard transaction didn't meet 100% of a unique business requirement, we modified it. We built custom Z-reports that did direct reads on tables like MSEG and BKPF. We embedded custom logic deep inside standard programs.

This "dirty core" was fragile but functional in the static world of ECC 6.0.

In S/4HANA, this entire model shatters.

The Data Model Changed: Your custom report that directly reads MSEG is now broken. S/4HANA uses the $MATDOC$ (Material Document) table. Your finance mods that hit BKPF and BSEG are now obsolete, replaced by the Universal Journal ($ACDOCA$). Every single piece of custom code that touches these tables will fail.

The "Retrofit" Nightmare: The traditional answer to this is a "retrofit." This is a manual, line-by-line analysis of thousands of custom objects. It’s a soul-crushing process where developers guess the original intent of a program written 15 years ago and try to make it work in S/4. This is where your project stalls. The "retrofit" task on your project plan, estimated at 3,000 hours, quickly balloons to 15,000. Your best developers are now just glorified code janitors, and your innovation pipeline grinds to a halt.

This is the failure point. But it's 100% avoidable by shifting your entire mindset.

The Paradigm Shift: From "In-Core" to "Clean-Core"

The future of SAP is Clean-Core. The concept is simple, but its implications are profound: You never, ever modify the standard SAP core again.

You treat the S/4HANA core as a pristine, inviolable engine. All your customizations, all your unique business logic, and all your competitive differentiators are built outside this core, connected only through stable, upgrade-proof APIs.

When you adopt this model, future SAP upgrades become non-events. They are seamless updates to the core engine that do not break your custom functionality.

The question is, how do you get your 20 years of "dirty core" code to this new, clean state without a multi-year project?

This is where the new ABAP development model comes in.

The Clean-Core Toolkit: ABAP Cloud, RAP, and BTP

SAP has provided a powerful new set of tools to achieve a clean core. This isn't just theory; it's the new standard.

On-Stack Extensions with ABAP Cloud & RAP:

Think of this as: Building a "guest house" on your property. It’s on your S/4HANA system (the "stack"), but it’s completely separate from your "main house" (the core). It has its own plumbing and doesn't touch the core’s foundation.

The Technology: This is ABAP Cloud. It’s a modern, cloud-optimized version of ABAP that forces you to be "clean." It does not allow you to call old, unreleased function modules or do direct table reads. You can only interact with the core through Released APIs—stable, whitelisted interfaces that SAP guarantees will not change.

The Framework: The ABAP RESTful Application Programming Model (RAP) is the framework for building your new applications and Fiori UIs using ABAP Cloud. It’s the modern, efficient way to write ABAP code that is inherently clean and API-driven.

Side-by-Side Extensions with SAP BTP:

Think of this as: Building a "factory" across the street. For heavy-duty, complex applications, or for apps that need to integrate with non-SAP systems, you build them entirely off-platform on the SAP Business Technology Platform (BTP).

The Technology: This "factory" is connected to your S/4HANA "main house" via a secure, public bridge—again, using those same Released APIs. This gives you total separation and flexibility. Your factory can run on its own innovation cycle without ever touching the core ERP.

Your goal is to move every single piece of custom logic to one of these two models. The problem is the sheer volume. That's why you don't treat it as a marathon. You treat it as a sprint.

The 90-Day Clean-Core Fix: Our Sprint Methodology

At ROI E-Solutions, we've operationalized this shift. The 90-Day Clean-Core Sprint is not about fixing 100% of your code. It's about de-risking 100% of your project by retiring the obsolete, refactoring the critical, and creating a "factory" model to handle the rest.

Here is what the 90 days look like:

Phase 1: Triage & Analyze (Weeks 1-3)

We don't start by rewriting code. We start with data. Using tools like the SAP Readiness Check and the ABAP Test Cockpit (ATC), we scan your entire custom code repository.

We triage every single Z-object into four buckets:

Retire (The Quick Win): This is the code no one has used in 12-24 months. You will be shocked at how much of your "critical" custom code is actually just digital dust.

Keep (Simple Fit/Gap): Simple reports or basic BAdI implementations that are already S/4-compliant or require only minor tweaks.

Refactor (On-Stack): High-priority custom logic that directly reads core tables or uses obsolete functions. This is the prime candidate for conversion to ABAP Cloud/RAP using released APIs.

Rebuild (Side-by-Side): Highly complex, monolithic Z-programs that are deeply embedded in the core. These are too risky to refactor and must be completely re-designed as BTP side-by-side applications.

Phase 2: Retire the Risk (Weeks 4-7)

This is the most satisfying phase. We execute the "Retire" list. By simply deleting 30-40% of your obsolete custom code, we've already dramatically reduced the project scope. We're not migrating junk. This single act slashes your retrofit ticket backlog and builds massive momentum.

Phase 3: Refactor the Factory (Weeks 8-12)

We don't try to fix everything. We establish a "modernization factory." We select the top 10-15 most critical "Refactor" objects (the ones your business actually runs on).

Our team works with yours to convert this first batch to the new ABAP Cloud and RAP model.

We prove the methodology, establish the patterns, and train your developers on the new way of thinking.

For the "Rebuild" candidates, we deliver a final architectural design and proof-of-concept on BTP.

The Result: An Un-Stalled Project and a Future-Proof Core

At the end of 90 days, your S/4HANA project is in a completely different place.

Your retrofit backlog is cut by 40-60%, dominated by "Retire" and "Keep" tickets.

Your project risk is contained. The monolithic, "scary" programs have a clear "Rebuild" path.

Your team is enabled. They are no longer "ABAP janitors" but "ABAP Cloud developers."

Your upgrade is un-stalled. You now have a predictable, repeatable factory model for handling the remaining code, which can run in parallel with the main project, not as a blocker.

Stop blaming S/4HANA for your upgrade stalls. The problem is your past, and the only way out is to embrace a new development model. The "big bang" retrofit is a myth. The future is a rapid, surgical, 90-day sprint to a Clean-Core.