SAP's end-of-mainstream-maintenance timeline for ECC has turned S/4HANA migration from a strategic option into a deadline most enterprises running SAP now have on the calendar. That urgency is exactly what makes migrations risky: teams under deadline pressure tend to under-scope the parts of the project that don't feel urgent until they suddenly are — data quality, custom code remediation, and cutover rehearsal chief among them.
Start with the decision that shapes everything else: Greenfield, Brownfield, or Bluefield
A greenfield migration rebuilds your SAP landscape from scratch on S/4HANA, which is the cleanest technical outcome but the most disruptive to existing processes and the most expensive in implementation hours. A brownfield migration converts your existing ECC system in place, preserving configuration and history but carrying forward years of accumulated technical debt along with it. Bluefield approaches — a selective, phased conversion — split the difference, but require more upfront analysis to scope correctly. The right choice depends less on technical preference and more on how much of your current configuration is actually still serving the business versus surviving out of inertia. That's worth an honest audit before committing to a path.
Data cleanup is the least glamorous, most predictive phase
The single best predictor of a smooth cutover isn't the technical migration plan — it's how seriously the data cleanup phase was taken. Duplicate vendor and customer master records, inconsistent material classifications, and years of unreconciled historical transactions don't just carry forward into S/4HANA — S/4HANA's simplified data model is considerably less forgiving of them than ECC was. Teams that treat data cleanup as a compliance checkbox rather than a real workstream consistently hit the most painful surprises during testing, when it's most expensive to fix.
Custom code remediation deserves its own timeline, not a footnote
Every custom ABAP development, every user exit, every BAdI implementation built up over years of ECC customization needs to be inventoried and assessed against S/4HANA compatibility — and a meaningful fraction of it will need rework, not just a compatibility check. SAP's own Custom Code Migration app is a reasonable starting point for the inventory, but the assessment of what's actually still business-critical versus what accumulated and was never cleaned up is a judgment call that takes real stakeholder time. Underestimating this phase is one of the most common causes of timeline slippage.
Cutover planning: rehearse the rollback as seriously as the migration
A cutover plan is only as good as the fallback plan behind it. Before go-live, the cutover should be rehearsed at least once in a full mock run — not just the migration steps, but the rollback procedure if something goes wrong at 2am during the production cutover window. Teams that skip the rollback rehearsal because "the migration plan is solid" are the ones most likely to be improvising under pressure if that plan meets a production edge case it didn't account for.
Change management matters as much as the technical migration
S/4HANA introduces genuine UX and workflow changes — the Fiori interface, simplified data structures, and new transaction codes are a real adjustment for teams who've used the same ECC screens for a decade. Underinvesting in end-user training and change management is one of the fastest ways to turn a technically successful migration into a business-perceived failure, because adoption friction gets blamed on the new system rather than the training gap that actually caused it.
None of this makes S/4HANA migration simple — it isn't, and no roadmap makes it so. But the enterprises that get through it with the least disruption are consistently the ones that treated data cleanup, custom code assessment, and cutover rehearsal as first-class workstreams from the start, rather than as risks to manage if time allows.