Choosing Between Brownfield and Greenfield for S/4HANA
Brownfield is a technical in-place conversion of an existing ECC system to S/4HANA, keeping configuration, history and customisations but forcing them through the new data model. Greenfield is a net-new implementation with a redesigned process landscape and selective data migration. The choice determines project duration, downtime, risk profile and how much of the legacy landscape survives, and it should be made once, early, and deliberately.
This page covers the practical difference between converting an existing ECC system in place versus rebuilding on S/4HANA from a blank slate, and the hybrid selective data transition route that sits between them. It focuses on what each route actually does to custom code, interfaces, history and the business, and on the sequencing mistakes that turn a sound architectural choice into a schedule failure.
Published 16 Sept 2026· 1,082 words
Classic ECC behaviour
In the ECC world there was no equivalent decision to make, because moving forward normally meant staying on the same data model. Companies applied enhancement packages and technical upgrades in place, kept the same underlying tables such as BSEG, MSEG, KNA1 and LFA1, and carried forward whatever general ledger variant, org structure and custom Z-development they already had. A full reimplementation happened occasionally, usually driven by mergers, template rollouts across regions, or a decision to consolidate several ECC instances into one, but it was a business-driven project rather than something forced by the technology itself. Landscapes accumulated years of custom reports written directly against cluster and pooled tables, interfaces hardcoded to specific field structures, and authorisation designs built around whatever org structure existed at go-live. None of that was under pressure to change, because the data model underneath stayed constant release after release.
S/4HANA behaviour
S/4HANA changes the underlying data model itself, which is why the route to get there stops being a purely technical question. Brownfield is a conversion of the existing ECC system in place: the same client, the same configuration, the same customisations, run through a conversion process that restructures data into the new model, most visibly the universal journal and the business partner structure, while preserving transaction history and most custom code with adaptation. Greenfield is a new implementation on a fresh S/4HANA system, with processes and org structure redesigned rather than carried over, and only selected master data and open items migrated in, typically leaving detailed historical postings behind in the legacy system or an archive. Selective data transition sits between the two: it moves selected company codes, ledgers or a defined slice of history and configuration into a new or converted target, letting a project take some of the ECC baggage forward and leave the rest. None of the three routes is free of custom code or interface work; they differ in how much of the existing landscape is forced through unchanged versus rebuilt.
Project impact
The impact differs sharply depending on the route chosen, and different people carry the pain in each case.
- Finance is affected in every route: the universal journal changes how custom FI/CO reports read data even in brownfield, where the underlying tables are converted but the reporting layer often is not adjusted until testing exposes gaps
- Custom code owners face effort regardless of route; brownfield forces a code remediation pass against every simplification item, greenfield forces a decision on which Z-programs are even worth rebuilding against redesigned processes
- Interfaces break in both directions, because target field structures and some table names change; interface teams who assume brownfield means no interface work are consistently wrong
- Business process owners feel greenfield hardest, since transaction habits, org structure and even the chart of accounts may all move at once, multiplying training and hypercare load
- Authorisation design has to be rebuilt from scratch in greenfield and reviewed carefully in brownfield, since business partner and organisational changes shift which authorisation objects actually control access
- Month-end is the first real test of a brownfield conversion, because reconciliation reports that ran quietly for years against the old structures often silently produce wrong totals against the converted one until someone checks
Migration actions
The route decision has to be made deliberately and early, then executed with the right gates in sequence.
- Run a fit-to-standard and business process assessment before committing to a route; the decision belongs to architecture and business sponsors jointly, not to the technical team alone
- For any brownfield candidate, run the simplification item check against the current system as a hard pre-conversion gate, not an optional cleanup step; unresolved simplification items block conversion outright
- Run a custom code impact analysis in parallel, regardless of route, since both brownfield and greenfield require deciding which Z-objects survive, get rebuilt, or get retired
- Decide the historical data strategy before cutover planning starts: convert everything, archive and leave read-only in the source system, or use selective data transition to bring across only defined slices
- For greenfield, build the target org structure, chart of accounts and master data governance model before any migration load begins, since loading data into an undefined target structure guarantees rework
- For selective data transition, agree scope boundaries explicitly in writing, since ambiguous scope is the single most common cause of this route quietly turning into either a full brownfield or full greenfield effort mid-project
Whose problem this is
The route decision is architectural and strategic, owned jointly by the enterprise architect and the business sponsor, not delegated to Basis or a single functional lead. Execution afterward splits along functional and technical lines: functional teams own process redesign and reconciliation, technical teams own the conversion or migration tooling, custom code remediation and interface rework, but neither side owns the initial choice alone.
Common pitfalls
Several failure patterns recur often enough to be predictable.
- Treating brownfield as a purely technical upgrade and skipping process redesign entirely, which locks in years of accumulated workarounds into the new system unchanged
- Underestimating downtime for a large brownfield conversion because sandbox and quality system tests ran against a fraction of production data volume
- Discovering the true custom code footprint only during the technical conversion itself, because an earlier code inventory was incomplete or excluded rarely-used but still-scheduled batch jobs
- Choosing selective data transition without a firm scope boundary, which drifts during the project until the team is doing the full effort of both other routes combined
- Revisiting the route decision mid-project after sunk cost has already been spent on migration or conversion tooling specific to the original choice, causing a schedule and budget reset
- Passing all functional tests in the quality system and then finding at the first live month-end that reconciliation reports built against old table assumptions produce incorrect totals under real posting volume
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-s4hana-changes/brownfield-conversion-versus-greenfield-implementationERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.