Brownfield vs Greenfield: The Honest Comparison
The brownfield vs greenfield decision is the most consequential strategic choice in an S/4HANA migration. It affects project cost, timeline, risk profile, and the degree to which the migration is an opportunity to redesign business processes versus a technical upgrade. It is also, consistently, a decision that is influenced more by consultant preference and sales positioning than by objective analysis of the customer's situation.
Definitions and What They Actually Mean
Brownfield (system conversion) converts your existing ECC system to S/4HANA in place. The system history, custom code, configuration, master data, and transactional data all move to S/4HANA. The technical approach uses SAP's Software Update Manager with the Database Migration Option or in-place upgrade.
Greenfield (new implementation) builds a new S/4HANA system from scratch. Configuration is rebuilt. Master data is cleansed and migrated. Transactional history either stays in a legacy system for read access or is selectively migrated. Custom code is rewritten or eliminated.
Selective data transition (sometimes called bluefield or hybrid) is a middle path: a new S/4HANA system is implemented, but historical data is migrated from the existing ECC system using the SAP Landscape Transformation tool. This combines the process redesign opportunity of greenfield with data continuity closer to brownfield.
The Real Cost of Greenfield
Greenfield is sold on the basis of the clean start: no legacy constraints, no accumulated technical debt, standard processes, maximum use of SAP Best Practices. These benefits are real. The costs are less prominently discussed.
Every configuration decision that was made over your ECC system's lifetime must be made again. Every country-specific legal requirement must be re-implemented. Every integration must be rebuilt. Every report must be recreated. Every user must be retrained — not on the delta changes from ECC to S/4HANA, but on an entirely new system configuration.
Data migration in a greenfield project is a full-scale migration project embedded within the S/4HANA implementation. Open items, master data, and any historical data to be migrated require extraction, cleansing, transformation, and loading tools — typically using SAP Migration Cockpit or legacy migration tools. The quality of your current master data directly determines how painful this is.
The total cost of a well-executed greenfield implementation is almost always higher than a brownfield conversion of equivalent scope. The argument for greenfield is not cost — it is strategic: the forced clean slate removes accumulated process compromises that a brownfield would carry forward.
The Real Cost of Brownfield
Brownfield carries forward everything: the good and the bad. Configuration that was correct for 2010 business processes migrates unchanged. Custom code that was written for a deprecated table gets flagged and must be remediated. Business processes that evolved as workarounds become permanent because nobody questions them during the conversion.
The brownfield argument is cost and speed: faster than greenfield, lower risk of losing institutional knowledge embedded in configuration, and no need to re-implement what already works. The actual cost depends almost entirely on the state of your existing system.
A clean, well-maintained ECC system with limited customisation converts to S/4HANA relatively smoothly. A heavily customised, years-of-accumulated-workaround ECC system may require more remediation effort than a greenfield implementation would have cost.
The honest assessment of brownfield cost requires: a readiness check output, a custom code scan with finding counts by severity, and an honest conversation about which simplification items in your active modules are blockers.
Custom Code: The Deciding Factor
For organisations with extensive custom development, custom code remediation cost often dominates the migration investment regardless of approach. In brownfield, custom code must be remediated to work with S/4HANA's changed APIs and data model. In greenfield, equivalent functionality must be rebuilt or replaced.
The difference is: in brownfield, you are fixing existing code — you know what it does and you have tests (or at least users who know if it breaks). In greenfield, you are rewriting from a functional specification — the risk is forgetting something the existing code handles implicitly.
For systems where custom code volume is very high (thousands of custom programs), neither approach is cheap. The question shifts to: is the custom code worth carrying forward, or is this an opportunity to replace it with standard functionality the business was not using?
Selective Data Transition
Selective data transition is underused and underunderstood. It is not a compromise between brownfield and greenfield — it is a distinct approach with its own trade-offs.
The primary advantage is that it allows business processes to be redesigned in a fresh system while preserving transactional history for reporting and compliance. Finance teams that need 7+ years of posting history accessible in the new system without running a legacy system in parallel benefit from this approach.
The primary disadvantage is complexity. Selective data transition requires the Landscape Transformation Server (or equivalent tooling), careful scope definition for what data to migrate, and reconciliation testing to verify that migrated data balances correctly. It is typically more expensive than pure brownfield and requires more specialist expertise.
The Decision Framework
A simplified decision framework: if your ECC system is relatively clean, your business processes are largely standard, and your custom code volume is manageable — brownfield is likely faster and cheaper. If your ECC system has significant technical debt, your business wants to use the migration as a process redesign opportunity, and the business has the capacity to participate in a longer implementation — greenfield provides more long-term value.
If you need historical data in the new system for compliance but also want process redesign — selective data transition is worth evaluating properly.
The worst decision is the one made without a current-state assessment. Do the readiness check, do the custom code scan, and price both options from the actual findings before committing.
What Consultants Do Not Tell You
Consultants who specialise in greenfield implementations will recommend greenfield. Consultants who specialise in conversions will recommend brownfield. This is not always cynical — people advocate for the approach they know — but it means you should seek perspectives from practitioners who have done both and can speak honestly about the failure modes of each.
The other thing that is underemphasised: both approaches require sustained business involvement. The failure mode is not technical — it is the business treating S/4HANA as an IT project. Greenfield without business ownership produces a system that nobody uses correctly. Brownfield without business validation produces a system that works technically but has migrated the wrong version of the business processes.
> Editorial note: SAP's S/4HANA release strategy and the tools available for each migration approach continue to evolve. Verify current tooling and approach options with SAP and your implementation partner against the specific S/4HANA release you are targeting.