The decision to migrate from SAP ECC to S/4HANA is easy to make in principle and brutally difficult to execute in practice. Having led and advised on multiple migrations across industries — from consumer goods to aerospace to logistics — I want to share what the textbooks won't tell you.
Greenfield vs. Brownfield: The First Decision That Matters
Before you do anything else, you need to decide on your migration approach. This choice affects everything — timeline, cost, risk, resource requirements, and how much business disruption you'll absorb.
Brownfield (System Conversion) means converting your existing ECC system to S/4HANA. You keep your data, your configurations, your processes. The advantage is speed and familiarity. The disadvantage is that you also keep your technical debt, your workarounds, and your customisations — and you move all of that into a new platform.
Greenfield (New Implementation) means building S/4HANA from scratch, migrating only the data you need, and redesigning your processes around SAP's best-practice templates. The advantage is a clean slate. The disadvantage is that it's expensive, time-consuming, and requires significant business change management.
Most organisations I work with end up somewhere in between — what SAP calls a "selective data transition" — where you convert the system but re-engineer specific areas. This is often the pragmatic middle ground, but it requires sophisticated programme management.
The Five Things Most Projects Get Wrong
1. Underestimating data migration
Data migration is consistently the most underestimated workload in any SAP migration. It is not a technical task — it is a business task. Someone in Finance has to own the GL account data. Someone in Supply Chain has to own the material master. If the business doesn't step up, IT ends up making data decisions it shouldn't be making, and the quality of what lands in your new system will reflect that.
2. Ignoring custom code until it's too late
Most ECC systems have years of custom development. Some of it is necessary. Much of it is compensating for processes that should have been redesigned years ago. A custom code analysis at the start of the project — not midway through — is non-negotiable.
3. Treating it as a technical project
S/4HANA changes how Finance works. It changes how Supply Chain works. It changes how reporting works. If your executive sponsors think this is an IT upgrade, you have a problem. The organisations that succeed treat this as a business transformation with a strong IT backbone.
4. Staffing with insufficient business involvement
IT teams cannot make SAP decisions in isolation. Every configuration decision in SAP is a business decision. Your best process owners need to be on this project — full time or close to it — not pulled in for workshops once a quarter.
5. Underinvesting in change management
Go-live is not the end of the project. It's the beginning of adoption. The investment in training, communication, and post-go-live support determines whether your migration delivers its promised benefits.
Building the Migration Plan
A realistic migration timeline for a mid-to-large organisation runs 24–36 months. Anyone telling you 12 months is either selling you something or scoping a much smaller project than you think you're buying. Key phases:
- Assessment and scoping (2–3 months): Custom code analysis, integration inventory, data quality review, process scope definition
- Preparation and blueprinting (3–4 months): Fit-gap analysis, design decisions, technical architecture, team mobilisation
- Realisation (9–15 months): Build, unit testing, integration testing — the core of your project
- Testing and cut-over preparation (3–4 months): UAT, performance testing, cut-over rehearsals, training
- Go-live and stabilisation (3–6 months): Hypercare, defect resolution, adoption monitoring
Choosing Your Implementation Partner
Your SI (systems integrator) will make or break this project. Things I look for beyond the obvious criteria:
- Industry experience specifically in your sector — not generic SAP experience
- The actual team, not the team presented in the sales process
- References from projects that went difficult, not just projects that went smoothly
- Functional depth, not just technical capability
The best time to evaluate your migration approach was two years ago. The second best time is today. The worst time is when SAP sends you a letter about support costs.
If you're at the beginning of this journey, take the time to assess properly before committing to an approach. A few months of rigorous upfront assessment will save you years of expensive rework downstream.
