How SAP Projects Quietly Lose Their Upgradeability

No SAP programme loses its upgradeability in one meeting. Nobody stands up in a steering committee and says, “Let’s make the next upgrade impossible.” It happens in hundreds of smaller decisions instead: a report rebuilt the old way because that’s how legacy did it, a data cleanse pushed to “phase two” or “a go-live date treated as the finish line”.

By the time an organisation notices its system has become unupgradeable, nobody can point to the moment it happened. That’s precisely the problem. Upgradeability isn’t lost; it’s eroded, and erosion is much harder to spot than a single bad decision.

A platform that isn’t upgradeable becomes more expensive to maintain, slower to evolve, and less capable of supporting new technologies. Every future transformation becomes more difficult because the last one left behind unnecessary complexity.

Why upgradeability is a business capability

When executives hear the word upgradeability, it’s easy to assume it’s something the SAP Basis team worries about every few years.

It isn’t.

Upgradeability is really a measure of how easily your business can adapt to change.

Every new acquisition, regulatory requirement, AI initiative or business process improvement depends on your ability to modify the platform safely and predictably. If every change requires months of testing, extensive rework or specialist knowledge just to avoid breaking existing customisations, the platform gradually becomes less of an enabler and more of a constraint.

That’s why organisations with poor upgradeability often find themselves spending more on maintaining yesterday’s solutions than building tomorrow’s.

The irony is that nobody deliberately sets out to create that situation.

It happens gradually.

Rebuilding the old system inside the new one

The most common reason is that developers recreate legacy processes inside S/4HANA rather than asking whether the standard functionality already covers the requirement. It’s an old habit. The old system did it a certain way, so the new one gets built to match, custom code and all, without anyone checking if that customisation is still needed.

The scale of this is bigger than most executives assume. Industry estimates put between 40% and 60% of custom code in an average SAP system as technically unused. That dead code still increases the scope and complexity of every future migration or upgrade. That’s roughly half a system’s custom logic sitting there doing nothing except making the next upgrade slower, riskier and more expensive to test.

Master data as an afterthought

The second pattern is data governance treated as a formality rather than a foundation. Teams focus their energy on configuring and testing the happy path, then discover after go-live that nobody stress-tested what happens when a user types their bank details wrong, or when two customer records for the same company have quietly diverged for years.

Gartner puts the average cost of poor data quality at $12.9 million a year for the enterprises carrying it. That figure doesn’t show up on a project plan. It shows up eighteen months after go-live, as a dozen small operational fires that nobody can trace back to a single root cause, because the root cause was never one thing. It was a master data cleanse that got deprioritised under deadline pressure.

Timelines that assume go-live is the finish line

The third pattern is the most human one. Programmes get scoped, budgeted and staffed as if the system goes live, and the work is done. It isn’t. More than 60% of SAP migrations exceed budget, only 8% complete on schedule, and 65% of organisations that reach go-live report significant quality deficiencies on the other side of it.

It’s what happens when go-live is treated as a deadline instead of a milestone. The stabilisation work after go-live, the bug fixes, the process refinements, and the second and third rounds of user feedback are where a system either gets steered back toward clean core principles or drifts further from them because nobody budgeted time to do it properly.

The governance gap behind all of it

Underneath these three patterns sits one structural issue: most organisations don’t actually govern their customisations. They approve them project by project, ticket by ticket, without anyone asking whether the last fifty exceptions still make sense together. Technical debt doesn’t accumulate because people are careless. It accumulates because nobody owns the decision to say no.

The organisations getting this right are the ones that adopted BTP extensions early. As per industry research, they’re now running faster upgrade cycles and spending 30 to 40% less on annual system maintenance than SAP customers still carrying deep modifications inside the core.

What successful organisations do differently

The organisations that protect upgradeability don’t necessarily write less custom code. They make better decisions about where customisation belongs.

More importantly, they treat platform governance as an ongoing business capability rather than a project deliverable.

That usually means:

• establishing clear architectural principles before development begins
• requiring design reviews for exceptions rather than approving them by default
• encouraging developers to use released APIs and modern extension models
• measuring technical debt alongside delivery metrics
• keeping experienced architects involved after go-live instead of treating governance as a project activity

These practices make it easier to innovate because the platform remains predictable, maintainable and easier to extend.

Suggested Reading: Why SAP Architecture Reviews Should Happen Before Implementation

Questions every executive should ask

If you’re accountable for an SAP estate, the question worth asking is whether anyone in your organisation can currently tell you (with evidence rather than instinct) how many of your customisations are Level A and how many are the kind that will make your next upgrade a nightmare.

• Are new developments using released APIs by default?
• What percentage of our extensions still rely on direct core modifications?
• If SAP released a major update tomorrow, how confident are we that we could adopt it without launching another transformation programme?

If those questions don’t have clear answers, it’s worth looking beyond the technology.

The issue is often governance.

Final thoughts

One of the biggest misconceptions in enterprise technology is that upgradeability matters only when it’s time to upgrade.

In reality, it’s shaped every day. Every enhancement, every integration, every architectural exception, and every decision to prioritise short-term convenience over long-term maintainability.

Together, they determine whether your SAP platform becomes easier to evolve or gradually turns into another legacy system.

The organisations getting the most value from SAP are the ones protecting the foundations that allow modern SAP technologies to be adopted in the first place.

Because upgradeability is all about preserving your organisation’s ability to change.

At AvoTechs, we help organisations establish the governance, architecture and Clean Core practices that keep SAP landscapes upgradeable long after go-live. If you’re planning an S/4HANA programme or want an independent architecture review, we’d be happy to have a conversation.