Every large SAP migration starts the same way: a room full of people, a whiteboard, and someone drawing three boxes labelled “Greenfield,” “Brownfield” and “Bluefield.” Within twenty minutes someone will say “of course it depends on your specific situation.” Within thirty minutes someone will say “we should probably use a hybrid approach.” By hour two, you have a decision matrix nobody can read.
This is our attempt at the version of that conversation that actually helps.
The three canonical paths — and what they really mean
Greenfield (New Implementation). You throw away the customisation, keep the master data you want, and re-implement on a fresh S/4HANA system. In SAP marketing terms, this is the innovation path. In real terms, this is the “the last twenty years of custom code is not worth carrying” path. Best when your customisation is a swamp, or when you’re re-designing the business processes anyway.
Brownfield (System Conversion). You take your existing ECC 6 system — customisation, data, transports, everything — and run SUM with DMO to convert it in place to S/4HANA. Fewer decisions, faster timeline, but you carry your existing sins into the new house. Best when your customisation is manageable and your processes are essentially fine.
Bluefield / Selective Data Transition. A middle path: fresh S/4HANA installation, then selective migration of data and configuration from the ECC source, typically using SNP CrystalBridge, SAP Landscape Transformation, or similar tooling. Best for M&A consolidations, carve-outs, and cases where you want to keep the good customisations but leave the bad ones behind.
Everyone will tell you their choice is “obvious.” It rarely is.
The four questions that actually decide
Skip the vendor decision matrix. Ask these four questions instead.
Question 1: How much of your Z-code is doing something your business actually still does?
Do a custom code audit. Not a count of Z-programs — a count of Z-programs that are executed in the last twelve months, and of those, how many are business-critical. In our experience the ratio is usually shocking: a company with 8,000 Z-objects will find that 200 are actively used and business-critical, 800 are occasionally used, and the rest is dead code from projects finished a decade ago.
- If the “actively used and critical” count is small and the code is mostly reports and enhancements → Greenfield or Brownfield, roughly equal weight.
- If the “actively used and critical” count is large and includes complex process customisations → Brownfield. Re-implementing all that in Greenfield is a two-year project with a high failure rate.
Question 2: How healthy is your master data?
Pick five random material masters, five random customer masters, five random vendor masters. Look at them.
- If most of the fields make sense, values are consistent, duplicates are rare → your data will survive any path. Choose based on process, not data.
- If you find duplicates, obsolete records, encoding issues, missing mandatory fields, “9999 Fritz Test” entries from 2014 → Greenfield or Bluefield. Brownfield will just move the swamp faster. Take the cleanup opportunity.
Question 3: How urgent is the business case?
- If ECC 6 support pressure means you need to be live within 14 months → Brownfield. Nothing else is realistic.
- If the driver is Finance close speed or a specific business capability → Greenfield. Rebuild the process around the new capability.
- If the driver is post-merger consolidation of multiple ECC instances → Bluefield almost always wins.
Question 4: How much internal capacity do you have?
Brownfield needs about half the internal business-side engagement of Greenfield. Greenfield needs about twice the internal SI-side engagement of Brownfield. If your business analysts are already stretched, Greenfield is a mistake. If your ECC is a mess of undocumented customisation and the people who wrote it have retired, Brownfield is a mistake.
The nine phases of a real migration
Regardless of path, the phase model is roughly the same. What differs is the time and effort split between phases.
1. Discovery & readiness assessment · 6–10 weeks
Run the SAP Readiness Check. Run the Custom Code Migration app. Get outputs from both.
Do a custom code inventory (Solution Manager or Focused Build works, but a hand-audited spreadsheet is fine for smaller landscapes). Classify: Retire · Simplify · Convert · Rebuild.
Run a Simplification Item Catalog analysis against your current business processes. Every Simplification Item that you flag as impacting your business is a downstream decision — MM materials number extension, business partner conversion, new asset accounting.
Deliverable: a clear-eyed report saying “this is what our customisation actually looks like.” Most clients haven’t had this report in a decade.
2. Path decision & scope lock · 3–5 weeks
The decision workshop. All the numbers from phase 1 go on the table. The three paths get scored honestly (not by the SI presenting the pretty deck). Scope gets locked at high level.
Key sub-decision: on-prem, private cloud (RISE), or public cloud (S/4HANA Cloud, Public Edition)? Public cloud sounds nice but has a much tighter customisation envelope — it forces clean core, whether you like it or not. For most Indian mid-size customers we work with, the honest answer is private cloud via RISE, or on-prem.
3. Data cleansing (in parallel) · 12–20 weeks
The one activity that pays back regardless of path. Deduplicate materials, retire obsolete records, standardise vendor and customer master, close old open items in finance. Business Partner conversion is a mandatory downstream requirement for S/4HANA. Do it now, not in production cutover week.
4. Custom code remediation · 12–24 weeks
The ABAP-heavy chunk. Convert obsolete syntax. Replace removed function modules. Update selects for HANA (no more SELECT * INTO CORRESPONDING with implicit conversions). Address Simplification Items in code. Rewrite anything that touched a removed data model (COMPRESSION_TYPE_CATALOG, MATNR extension, one-off customer includes). Run ATC with S/4HANA cloud check variants and get to green.
We cover this in more depth in our Code remediation checklist for the S/4HANA move.
5. Sandbox conversion / build · 8–12 weeks
Brownfield: run SUM DMO on a sandbox copy. Test result end-to-end.
Greenfield: install fresh S/4HANA sandbox, migrate a representative slice of master data and one full process (order-to-cash), get to a working demo. Discover what breaks. Adjust scope.
Bluefield: same as Greenfield plus the selective-transition tooling setup.
6. Fit-to-standard workshops · 8–12 weeks (Greenfield/Bluefield only)
This is where the value of S/4HANA is realised — or lost. Every custom process gets held up against SAP Best Practices for the relevant industry. Every time you can retire a custom process and adopt standard, you buy back three years of maintenance debt. Every time you decide “no, ours is different” — write down why in a way that will make sense to your successor in five years.
7. Cutover rehearsals · 8–16 weeks (multiple)
Rehearse cutover at least three times. Each rehearsal exposes the weak assumption you made in phase 3 about a data conversion. Every rehearsal is faster than the last one. The go-live rehearsal, if you’re lucky, is boring.
8. Go-live and hypercare · 4–8 weeks
Cutover weekend. On-call rotations. Financial period-end close inside the first month of hypercare — this is where most projects that were “successful at go-live” quietly cost their sponsors bonuses. Have double the finance-side muscle in place for month 1.
9. Post-go-live optimisation · 6–12 months
Fiori launchpad content curation. Custom code performance tuning on HANA. Retirement of workarounds and stopgap solutions used to make go-live happen. This is the phase most migration projects budget for and then skip. Don’t. This is where the ROI lives.
What to standardise, what to leave custom
The single most useful heuristic we’ve developed:
Standardise everything that a competitor also does the same way. Customise only the things that are your specific competitive advantage.
If your material master, your quotation-to-order flow, or your general-ledger structure looks like a slightly-different version of what a competitor does — standardise it. You are not losing edge, you are removing overhead. If your production planning model reflects a specific way you handle mixed-flow batch manufacturing that your competitors can’t copy — customise it, document it, and defend it.
Every rand you spend customising something that isn’t a competitive advantage is a rand you’re spending twice: once to build, once to maintain, once every year to defend during audit, and once more in the next migration in ten years. That’s four rands.
A representative timeline
For a mid-sized manufacturer on ECC 6, moderate customisation, three plants, one ECC instance:
- Brownfield: 12–16 months end-to-end, of which 5–6 months is remediation-heavy.
- Greenfield: 18–24 months end-to-end, of which 6–8 months is fit-to-standard workshops.
- Bluefield: 14–18 months, split between build and selective transition.
For a larger group with multiple ECC instances (say three, after M&A):
- Brownfield of the largest instance + integration hub for the others: 18–24 months, but the total programme runs 30–36.
- Bluefield consolidation into one S/4HANA target: 24–30 months, more predictable end state.
- Greenfield: 30–42 months, usually mis-estimated in the initial business case by a factor of 1.5.
Nobody wants to hear “42 months.” Everyone claims it can be 24. Then it’s 42.
Three things worth stating out loud
One: ROI on this class of programme comes from the process re-engineering, not the technology. Budget for BPR from day one. Get a senior BPR lead on the programme. If the BPR lead reports to IT, you’ll get an IT project. If they report to the COO, you’ll get a business transformation. Structure accordingly.
Two: clean core is not a marketing slogan you can ignore. Every custom in-core enhancement you make in S/4HANA is a decision you’re pushing onto the team that migrates this system to S/4HANA’s successor in 2038. Don’t be the person they curse.
Three: you cannot bolt agile onto this. A 20-month programme cannot be run as 40 two-week sprints without an architectural spine holding it together. You need a proper programme structure, proper deliverables, proper phase gates. Layer agile within the phases — inside development, inside testing, inside remediation. Do not run the whole thing as one giant Jira backlog.
Who we help, where
We run migrations for mid-sized Indian manufacturers and offshore-delivered work for US clients. The Indian mid-market has specific characteristics — cost sensitivity, thin business analyst layer, strong shop-floor knowledge, weak documentation — that need a specific delivery model. We’re not going to compete on a large group Greenfield programme against the Big Four; we can absolutely deliver a Brownfield to S/4HANA for a two-plant elevator manufacturer or a diversified agri-products group, on time and on budget.
If you’re at the “we should probably do this within 18 months” moment on your ECC → S/4HANA journey, book a scoping call. No slide deck, one senior consultant, an honest recommendation.
