Six Ways an S/4HANA Migration Goes Sideways

Six Ways an S/4HANA Migration Goes
Sideways

Most migrations that struggle don’t fail on the technology. They fail on a handful of
decisions that were made late, made by default, or never made at all. Here are the six
worth catching early.

Ask people who have finished an ECC to S/4HANA project what they would change and the software
hardly comes up. They talk about the custom code nobody scanned until month five, the customer
master that turned out to be full of duplicates, the test cycle that got trimmed to hold a date. The
product mostly does what SAP says it does. The trouble sits in the choices around it.

Time matters here too. Mainstream maintenance for ECC 6.0 on EHP 6 to 8 ends on December 31,
2027, which leaves about fifteen months, and a mistake that only shows itself at go-live is one you may
not have room to fix. The six pitfalls below come up again and again in SAP’s own conversion guidance
and in what practitioners write once the dust has settled. None of them is exotic. Most are cheap to
avoid if someone raises them early enough.

Plenty of programs are set up under the CIO, staffed with technical people, and shown to the business
shortly before go-live. Panaya, which says it has been called in to rescue projects that went off track,
puts this first on its list of common mistakes: when the business is left out of key decisions, the

The fix is unglamorous. Name a business owner for each major process area on day one, and give them
real decisions to make rather than documents to sign. If the head of procurement can’t explain what

Whether you start clean (greenfield), convert what you run today (brownfield), or move selectively
(bluefield, also called selective data transition) shapes nearly everything after it: the timeline, the

because it is the easiest to explain, then find they have carried twenty years of workarounds into a new
system. Others pick greenfield for the fresh start and underestimate how much history finance and
audit will want to see. Neither choice is wrong. Choosing before you have looked at your own code,
data and appetite for change is.

SAP’s conversion guide points you to two things before anything else. One is the SAP Readiness Check,
which analyzes the configuration, data and usage of your production system. The other is the

Teams usually fail in one of two ways. Either nobody runs the scan until the build is under way, so the
effort estimate was a guess, or the scan gets run and the team dutifully fixes every finding, including
code nobody has called in years. Usage data is what separates the two. Fix what people actually run,
and put a name next to everything you are willing to retire.

pile up quietly over the years, and they stay out of sight in ECC until an S/4HANA load drags them into
view.

The clearest example is the business partner. ECC keeps customers and vendors as separate objects.
S/4HANA has one business partner model, tied to the old records through Customer-Vendor
Integration, and moving to it is not optional. It also has to happen before the S/4HANA conversion itself

Ownership is the quiet issue underneath. Sales owns customers, procurement owns vendors, finance
owns cost centers, and cross-domain cleanup stalls because nobody is responsible for the gaps

When early phases run long, the back end of the plan is where the squeeze lands. One testing
practitioner describes the mock migration as something you would typically repeat three to five times,
fixing and re-running each round, before the data and configuration are clean enough for a full dress

Test data is a second trap. Data that behaves in ECC doesn’t always carry over cleanly into S/4HANA’s
model, where the Universal Journal replaces several finance tables. The result is parallel testing that
nobody fully trusts: teams chase differences that turn out to be data problems while real defects go

ECC authorizations are built around transaction codes and menus. S/4HANA with Fiori grants access
through catalogs, groups and spaces instead. Copying ECC roles across unchanged is described as the
most common security mistake in a migration. Roles need to be re-derived against the new app

Read together, the six suggest a sequence. Assess first, before anyone commits to a plan: readiness
check, code scan, an honest look at the data. Choose the approach once you have seen the results, not
before. Run data cleanup and code remediation side by side, each with a named owner. Then put the
mock cycles and the test calendar into the plan before the build starts, and defend them when
something else slips.

This is also how Orpington Technologies Inc. approaches SAP work. The Canadian ERP advisory and
delivery firm has built its SAP practice around one move, ECC to S/4HANA, and staffs it with a highly
trained team that does this kind of migration for a living: the readiness assessment, the code and data
work, the mock cycles, the cutover weekend. It plans backward from SAP-set deadlines, so the
questions in the table below get asked in the first weeks of a program rather than the fourteenth
month.

If you are not sure where your own program stands, a conversation is a reasonable place to start.
Orpington’s team will look at your production system, your code and your data with you, and tell you
plainly which of these six you are closest to, even when the honest answer is that you are in better
shape than you feared. You can reach them at www.orpingtontech.com. None of the six is hard to spot
in month one. They are just expensive to discover in month fourteen.

Design decisions, user
acceptance

Have we compared greenfield, brownfield and
selective on our own data?