Why S/4HANA migrations fail – and what almost no one talks about

The move to SAP S/4HANA is one of the biggest technological transformations of our time. Companies allocate budgets, build project teams, analyze processes – and yet they experience the same pattern over and over again: timelines start to slip, budgets get out of control, and even after a successful go‑live, the new system often feels surprisingly unchanged.

Why does this happen? And why does it affect large enterprises just as much as mid-sized companies? The usual answer is: “SAP is complex.” But that explanation falls short. The real causes run deeper – and they don’t start with SAP, but within the organization itself.

Migration Is Treated as a Technical Project – Even Though It Is a Transformation Project

Many projects begin with the assumption that it is essentially an upgrade: analyze the system, convert it, test it, migrate it. Done.

But S/4HANA forces companies to make decisions that are rarely technical. They touch fundamental questions such as:

• Which of our processes still reflect our current reality?
• Which custom developments have grown historically but are now outdated?
• Which data do we actually need for the future?
• What role should ERP play in our future architecture?

Ignoring this perspective leads to a trap: You transfer the past instead of shaping the future. And this is where the risk of many migrations begins.

Historically Grown System Landscapes Are the Real Risk

Almost every SAP system reflects the company’s history: 10, 20, often 25 years of accumulated processes, workarounds, custom logic, and data.

All of this was introduced for pragmatic and seemingly valid reasons – but rarely cleaned up afterward. This leads to three major pitfalls:

 1. Too much legacy logic in the system

Custom Z‑developments, special rules, point‑to‑point integrations. They were once an advantage – today they are a migration risk.

2. Data that was never cleaned up

Millions of transactional records, old documents, outdated archives. Every object slows migration, increases risk, and amplifies testing efforts.

3.  An architecture no one fully understands anymore

After years of incremental adjustments, very few people still know the full logic behind it.

The result:

Complexity is not reduced but transferred 1:1 – with all dependencies and pitfalls.

The Clean Core Concept Sounds Simple – but Is Hard to Implement

“Keep the core clean” is widely known, but rarely practiced. Because:

• Removing modifications impacts established processes.
• Business units cling to familiar solutions.
• Custom developments are often business‑critical.

Clean Core requires a radical look at your own reality.

Without this, you end up with a system that is outdated on day one – and this happens far more often than one might think.

Business Units Are Involved Too Late – or Not at All

IT and external partners work for months before business departments even realize that key processes need to be redefined.

The consequences:

• Requirements are submitted too late
• “Indispensable” workarounds reappear
• Clean Core decisions get reversed
• Testing phases explode because processes aren’t understood
• Resistance grows – along with the pressure to bring old logic along

A successful S/4HANA migration only happens when the organization migrates and not just IT.

After the Migration, the System Often Doesn’t Feel “Modern” – and There Are Reasons

Many companies expect after the migration:

• leaner processes
• better performance
• a modern user experience
• more automation

But if legacy complexity is copied over, a different picture emerges:

• Processes remain confusing
• Analytics still rely on outdated structures
• Extensions behave just like before
• Users work in the same patterns as always

In other words: A lot is invested, but little truly changes.

What Almost No One Says: The Biggest Risk Is Not the Migration, But the Past

Most problems don’t arise because S/4 is difficult. S/4 is modern, powerful, stable, and built to encourage standardization.

The real stumbling blocks lie in legacy logic, outdated processes, uncleaned data, and decades-old decisions. And that’s why S/4HANA projects don’t fail because of SAP. They fail because companies try to carry the past into the future – unfiltered and unreflected.

How Companies Can Do Better

See migration as a decision path – not a copy and paste project

The key question is not “How do we migrate?” but “What do we actually want to take with us – and what not?”

Analyze data instead of copying it

Not every document, record, or dataset belongs in the new system.

Challenge custom developments

What is truly business‑critical – and what isn’t?

Involve business units early

There is no Clean Core without business change.

Reduce complexity before migrating

Because later clean‑up is expensive, risky and rarely consistent.

Conclusion: S/4HANA Isn’t the Problem – the Mindset Is

S/4HANA migrations rarely fail because of technology. They fail because companies avoid uncomfortable but necessary decisions:

• designing processes in line with the standard
• radically cleaning up data
• letting go of legacy logic
• reducing complexity
• involving business units
• seeing migration as an opportunity – not as a copying effort

Those who adopt this perspective aren’t just migrating a system.
They’re shaping the foundation of an agile, maintainable, and future‑proof enterprise.

In short: Less past. More future.