The Rebuild Myth.

Why modernizing operational work on SAP ECC today does not mean building it twice.

Ask an SAP team still running ECC why they are not building new operational applications, and you will usually get a version of the same sentence:

“We would only have to build it again on S/4HANA.”

It is the most reasonable objection in the room. It is also one of the most expensive assumptions in enterprise SAP right now, because it quietly converts a two or three year migration timeline into a two or three year freeze on operational improvement. Inspections stay on paper. Stock counts stay on clipboards. Approvals stay in email. None of that looks like a decision. All of it is one.

The assumption is worth examining closely, because it is built on something real.

Where the myth comes from

Anyone who has lived through an SAP upgrade understands exactly why this fear exists.

To let customers adapt SAP to their business, SAP left open doors: enhancement points and user exits woven through its own ABAP code, where you were invited to add your own validations, calculations, and process logic. That code runs as though it were part of SAP itself. Most of the time, it works.

Then a new version, enhancement package, or upgrade arrives, and the standard code around those doors has changed. Transactions like SPDD and SPAU hand you a list of every standard object that has changed, and each one has to be assessed against your customizations. Can SAP’s new standard replace it? Should it stay? Must it be rewritten? Large systems carry hundreds, sometimes thousands, of these decisions. And because development, QA, and production can each hold different objects and versions, the same painful choices get worked through again in every system.

That is the upgrade tax, and it is one of the main reasons organizations put off SAP upgrades for years. Anyone who has paid it once is right to be cautious about creating more of it.

But it is worth noticing what is actually being taxed.

What lands in migration scope, and what does not

The expensive part of a migration is custom logic sitting inside the standard core. That is the code that gets reviewed, rewritten, and retested, because the ground underneath it moved.

Applications built outside that core are a different case. An application that runs alongside the standard core and calls supported SAP interfaces is not modifying anything SAP ships. When the core is upgraded or converted, there is nothing for SPAU to hand you about it. The application keeps calling the same interfaces. The same app runs on ECC today and on S/4HANA later.

This is not a clever workaround. It is the architecture SAP itself has been asking customers to move toward. Clean core is not a rule invented to slow innovation down. It is the fix for precisely the pain described above: keep the standard core untouched, and upgrades get easier, new capabilities arrive with less risk, and the upgrade tax shrinks.

Which leads to a slightly awkward conclusion. The rebuild myth is not evidence that clean core prevents innovation. It is evidence that clean core is right, applied to the wrong category of code. The organizations most nervous about building something now are often the ones with the most modification-heavy history, which is to say the ones with the most to gain from building the new way.

The question is not whether you build. It is where.

91% of SAP customers run significant custom code. For most enterprises, a clean core is a destination rather than a starting point, and the journey takes years. If operational improvement waits for arrival, it waits a very long time.

So the more useful question is not “should we build before we migrate?” It is “where do we build so that this survives the migration?”

Three questions decide the answer:

Does it modify standard SAP objects? If it does, it enters migration scope. If it does not, it stays out of it.

Does it use supported interfaces? Applications calling supported, documented interfaces are insulated from changes in the code behind them.

Is the existing logic reusable? Business logic you already own, in ABAP your team already wrote, can often be exposed and reused rather than rewritten. Work already done stays done.

Answer those three honestly and the rebuild question largely answers itself.

What this looks like in practice

Saint-Gobain’s Mobility Business Unit was still on ECC when it took on a problem that could not wait for S/4HANA. Critical planning and forecasting ran manually across spreadsheets and email, which slowed collaboration and made the data hard to trust. Working with Neptune, they digitized those workflows and connected them directly to SAP.

Planning cycles dropped from two weeks to two days. Manual effort fell, data quality improved, and so did visibility across the supply chain. Because it was built clean-core aligned, what they created can be retained and adapted as part of the S/4HANA journey rather than rebuilt from nothing.

That is the pattern worth copying. Not a bet against the migration, and not an argument for delaying it. Operational improvement now, with the migration path left intact.

Modernize while you operate

Migration timelines get set by budget, capacity, regulation, skills, and risk appetite. Those are real constraints and they deserve respect.

What deserves challenging is the belief that everything else has to stand still until the migration is finished. It does not. Applications built outside the standard core, on supported interfaces, are not the thing that makes a migration expensive. They are the thing that makes the years before it productive.

Modernize while you operate. Migrate on your terms. Those two were never in conflict.