The Most Common Mistakes After an S/4HANA Migration

The technical migration is complete, the system is running — and now the real problems begin. This is not the exception; it is the rule. Anyone who has accompanied S/4HANA projects knows the pattern: in the first weeks after go-live, support requests pile up, user frustration rises, and it sometimes becomes clear that decisions made during the project phase are now proving costly. This article shows where the most common mistakes occur — and what can be learned from them.

1. Change & Adoption: the underestimated success factor

The most visible symptom after go-live is usually the interface: users struggle with SAP Fiori. But Fiori is not the actual problem — it is the visible result of a deeper oversight: insufficient change management.

An S/4HANA migration does not only change the system. It changes workflows, roles, responsibilities, and the way people interact with their tools every day. Organisations that fail to actively communicate, accompany, and train for this change should not be surprised when adoption falls short. The Fiori problems that surface after go-live are often simply the expression of a deeper disorientation:

• The interaction concept has fundamentally changed — not just visually.
• Business processes have been simplified or restructured, which is initially perceived as an obstacle rather than an improvement.
• What used to be handled in a single transaction is now spread across several apps — and in some cases the reverse is true.
• Many systems run a mixture of modern Fiori apps and embedded classic GUI transactions. This creates inconsistency and disorientation for users.
• Reporting works differently — reports are built, filtered, and exported in new ways that require adjustment.
• The Fiori interface has lower contrast than the classic GUI, which is a genuine usability issue for older users or in environments with unfavourable screen settings.

2. Data Quality: the real migration deciding factor

Data quality is one of the most important success factors in an S/4HANA migration — and at the same time one of the most frequently underestimated. It is not the technology, the system integrator, or the project budget that determines whether a migration goes smoothly. Data quality does.

Poor master data from ECC migrates into S/4HANA uncleansed. Duplicate vendors, outdated customer master records, inconsistent asset data, incorrect cost centre structures — none of this is cleaned up by the migration itself. It is carried over. And in the new system, with its new processes and data architecture, these weaknesses become more visible than ever before.

Organisations that take data quality seriously begin the cleansing process well before the migration — and treat it as a separate workstream with clear accountability in the business.

3. Training Strategy: trained too early, followed up too late

The pattern is almost identical across S/4HANA projects: end users receive their training four to six weeks before go-live. Those weeks then pass with system testing, data migration, and final configuration work. By the time go-live arrives, much of the training content has already faded — and the problems start precisely when the system goes live and real postings are expected.

The reason lies in the nature of learning: knowledge is retained through application. A user who works with the production system for the first time four weeks after training will often face the same questions they had on the first day of the course.

For decision-makers, this means: the training budget should not be fully committed before go-live. A dedicated follow-up training allocation for the first weeks after go-live is not an additional cost — it is an investment in project success.

4. Clean Core: carrying custom developments forward instead of reconsidering them

In established SAP landscapes, every organisation has them: custom developments, commonly referred to as Z-programmes. They were built because the SAP standard could not cover a requirement at the time — or because a consultant recommended it. Some of them remain indispensable. Many of them are no longer necessary.

A common mistake in migration projects is carrying these custom developments into S/4HANA without questioning them. This increases migration effort, raises complexity in the new system, and prevents exactly what S/4HANA is designed to enable: lean, standard-close processes.

This is not a technical question — it is a strategic one. And it belongs on the agenda of decision-makers and project managers, not just developers.

5. Hypercare: go-live is not the end of the project

In many projects, go-live is treated as the finish line. The project team disbands, external consultants leave the organisation, and the business departments are largely left to manage the new system on their own. This is one of the most consequential mistakes in S/4HANA projects.

Go-live is not an ending — it is the beginning of the most critical phase. In the first weeks that follow, most problems surface: processes that worked in testing fail in live operations due to edge cases. Key users are overloaded, simultaneously managing their day-to-day responsibilities and serving as the first point of contact for all user questions. A functioning support organisation is often not yet in place.

For HR leaders, this is particularly relevant: key user roles must be genuinely relieved during the hypercare phase — through temporary capacity support, clear prioritisation, or external assistance. Expecting key users to manage this phase alongside their regular workload means neither day-to-day operations nor user support will function well.

The five risk areas at a glance

What these mistakes have in common

All five risk areas share a common cause: they do not originate in the system — they originate in project planning. Change management problems result from underestimated communication around change. Data quality problems result from cleansing that starts too late. Training problems arise from a concept that is timed incorrectly. Unnecessary custom developments survive because no one actively decided to question them. And hypercare problems occur because go-live is understood as a destination rather than a transition.

S/4HANA projects rarely fail because of the technology. They fail because of inadequate preparation and insufficient follow-through. Both are within the sphere of influence of decision-makers, key users, and project managers — long before the first user opens the new system, and for weeks afterwards.