SAP S/4HANA Migration: What No One Tells You Before You Start

Most SAP S/4HANA migration conversations start with the same question: brownfield or greenfield. It is a reasonable question. It is also the wrong place to start.

After leading and reviewing dozens of S/4HANA migrations, the honest pattern is this: the technical conversion is not what determines whether your program succeeds. The technical work is roughly 30 percent of the actual challenge. The remaining 70 percent — data, custom code, business process change, and adoption — is where programs are lost or won.

The first uncomfortable truth: your custom code is the problem

Every SAP customer of any maturity is carrying years of accumulated custom code. User exits, BAdIs, Z-programs, modifications to standard objects, and entire shadow modules that were built when standard SAP did not yet meet a particular need.

Much of that code is no longer needed. Standard S/4HANA now covers many gaps that custom code was filling in ECC. But almost every customer underestimates how much custom code exists, how interconnected it is, and how much of it nobody currently understands.

A serious S/4HANA program starts with a custom code analysis — typically using SAP Readiness Check, ABAP Test Cockpit, and Custom Code Migration Worklist tools. The output is rarely comfortable. It is also the most important diagnostic in the entire program.

The second truth: data is harder than the demo suggests

S/4HANA imposes stricter data models, more validation, and consolidated entities (Business Partner replacing Customer/Vendor being the obvious example). Data that worked perfectly well in ECC frequently breaks under S/4HANA validation rules.

Most teams discover this in the second mock conversion. The first mock cycle is treated as a technical exercise. The second cycle is when the data team realizes the cleanup required is significant — sometimes affecting millions of records.

Plan the data work as a primary workstream with its own lead, its own timeline, and its own budget. Treating data migration as a side activity of the technical team is one of the most common — and most expensive — mistakes.

The third truth: greenfield is not always braver

A common consulting narrative positions greenfield as the 'bolder' choice — the chance to reimagine your processes, escape legacy debt, and embrace SAP standard. Sometimes this is true. Often it is not.

Greenfield means rebuilding integrations, re-cutting master data, re-training users on a new process model, and absorbing all of that change at once. For a stable, well-running ECC environment with limited customization, brownfield may be both lower risk and faster to value.

Selective data transition — the middle path — is increasingly the right answer for organizations that want to modernize selectively without a full rebuild. It is also the option that gets less marketing attention because it is harder to package neatly.

The fourth truth: business adoption is where most programs slip

Even a technically perfect S/4HANA cutover fails if the business has not been prepared for the change. New UIs (Fiori), changed transaction codes, new master data structures, and modified business processes all show up at the user's desk on day one.

Change management cannot be a workstream that activates in month nine. It needs to be part of the program from the first weeks — communication architecture, role-impact analysis, training design, and super-user development. Programs that under-invest here are visible within days of go-live: support tickets spike, productivity drops, and trust in the new system erodes quickly.

The fifth truth: hypercare is not the finish line

A common pattern: go-live, four to eight weeks of hypercare, ramp-down of the program team, declaration of success. Six months later, the business has accumulated workarounds, the integrations have started failing in odd ways, and nobody is empowered to fix any of it.

S/4HANA is a six-month-release platform. Twice a year, something will change. A clear post-go-live operating model — release management, regression testing, governance for change requests, ongoing optimization — is essential and rarely planned for in advance.

What this means for planning your migration

If you are early in your S/4HANA planning, three pieces of practical advice:

• Run the readiness diagnostics before committing to an approach. Custom code analysis, simplification item review, and data quality assessment should drive your brownfield/greenfield decision — not a vendor's preferred model.
• Resource the data and change management workstreams as primary. Not as side activities of the technical team. They need their own leads, their own budget, and their own visibility at steering committee level.
• Design the post-go-live operating model up front. Who owns enhancements, how releases are managed, how new business requests are triaged. These decisions are easier to make calmly before go-live than reactively after it.

S/4HANA is a worthwhile destination. It is not, however, a simple migration — and the organizations that succeed are the ones that go in clear-eyed about what the program actually involves.