Why the clock matters
SAP has announced the end of mainstream maintenance for SAP ECC 6.0 at the end of 2027, with optional extended maintenance available until 2030 at additional cost. For organizations still running ECC, that makes S/4HANA migration less a question of if than of when and how.
Migrations of this kind typically take many months for mid-sized companies and longer for complex enterprises. Waiting until the deadline is close compresses timelines, reduces the availability of experienced consultants, and increases risk. The right time to plan is well before you need to start.
Three approaches
Every migration starts with a strategic decision about how much of the past to bring forward.
- Greenfield (new implementation): re-implement processes on S/4HANA using standard best practices. Highest opportunity to simplify, highest change-management effort
- Brownfield (system conversion): convert the existing ECC system, keeping configuration, custom code and history. Faster and less disruptive, but carries existing complexity forward
- Selective data transition: a hybrid that lets you redesign some areas while carrying selected data and configuration across — useful for mergers, carve-outs or phased rollouts
How to choose
The decision depends on how well your current processes serve the business, how much custom code you rely on, how clean your data is, and your appetite for change. If years of customization have made the system hard to maintain and processes no longer match how the business works, greenfield may be worth the effort. If processes are sound and the priority is to move quickly with minimal disruption, brownfield is often the pragmatic choice.
Whatever you choose, base the decision on evidence from a readiness assessment rather than preference or vendor enthusiasm.
Phase 1: Readiness assessment
A structured assessment typically covers:
- Simplification item checks to identify functional changes that affect your processes
- Custom code analysis to find code that is unused, redundant or incompatible
- Data quality profiling for master data such as customers, vendors and materials
- Integration inventory of every interface, middleware flow and third-party system
- Infrastructure and hosting options, including cloud deployment models
- A business case, roadmap and high-level budget
Phase 2: Prepare before you migrate
Much of the risk can be removed before the main project starts. Archive data you do not need to migrate. Retire custom code nobody uses — in many long-running systems a significant portion of custom objects are rarely or never executed. Clean master data and resolve duplicates. Run the customer-vendor integration to business partners early if converting. Each of these activities makes the migration smaller, faster and more predictable.
Phase 3: Migrate, test and cut over
Execution typically follows SAP's Activate methodology: explore, realize, deploy. Plan for multiple mock conversions or data loads so the cut-over weekend is a rehearsal of something already done several times. Testing deserves more time than most plans allocate — unit, integration, end-to-end business process, performance and user acceptance testing, with real users from each function.
Change management and training are not optional extras. S/4HANA introduces new user experiences through SAP Fiori and different ways of working in finance and logistics. People need to understand what changes for them, well before go-live.
Building the right team
An S/4HANA program needs more than technical consultants. Successful programs combine functional experts for finance, procurement, sales and supply chain; technical specialists for data migration, custom code and integrations; Basis and infrastructure expertise; and, critically, business process owners from your own organization who make decisions and own outcomes.
Many organizations use a blended model: a partner provides architecture, specialist consultants and delivery management, while internal key users and a small core team carry process knowledge and stay on to support the system after go-live. Plan this knowledge transfer from the beginning rather than in the final weeks.
Budget realistically for internal effort as well. Key users will spend significant time on design workshops, testing and training, and their regular work needs backfilling during peak phases.
Pitfalls to avoid
- Treating the migration as a purely technical upgrade with no business ownership
- Underestimating data cleansing and the effort to reconcile migrated balances
- Carrying forward custom code that standard S/4HANA functionality now covers
- Missing interfaces that only surface during integration testing
- Compressing testing to protect the go-live date
- Starting without a hyper-care and support plan for the weeks after go-live
Getting started
Begin with a readiness assessment and a clear decision on approach. Then invest in preparation — data, code and integrations — before the main build. Organizations that do this work early tend to have shorter, calmer migrations and get more value from S/4HANA once they are live.
Talk to a senior consultant about your situation — no obligation.