SAP S/4HANA Migration
SAP Brownfield vs Greenfield Migration: How to Choose the Right S/4HANA Approach
Compare brownfield system conversion and greenfield new implementation for SAP S/4HANA. Learn how to evaluate data, custom code, process change, downtime, testing, and project risk.
Brownfield and greenfield in practice
A brownfield approach converts an existing SAP ERP system into SAP S/4HANA while preserving a significant portion of the current configuration, data, processes, and custom developments. A greenfield approach creates a new SAP S/4HANA system and designs the target business processes afresh. The decision is a transformation choice, not simply a technical upgrade choice.
The right approach depends on the value of the current system, the amount of process change required, the quality of master and transactional data, the condition of custom code, and the organization’s ability to absorb change.
What brownfield migration preserves
Brownfield conversion is usually appropriate when the existing SAP ERP system contains valuable, stable processes that the business wants to retain. Existing organizational structures, historical data, configuration, and custom developments can reduce redesign effort, although each area still requires analysis for S/4HANA compatibility.
A brownfield project can shorten business-process disruption because users continue working with familiar structures. It can also carry forward unnecessary complexity, obsolete custom code, inconsistent master data, and workarounds that were embedded in the legacy system. The project therefore needs a clear scope for retention, remediation, and retirement.
Use the SAP S/4HANA migration overview to establish the overall conversion sequence before selecting detailed workstreams.
What greenfield migration changes
Greenfield implementation starts with a clean SAP S/4HANA system and a deliberately designed target model. The project team defines the required organizational structure, standard processes, extensions, integrations, roles, data objects, and reporting requirements for the target environment.
This approach is effective when the current system has extensive process variation, unreliable data, heavy customization, duplicated functionality, or a business strategy that requires substantial operating-model change. It offers stronger design freedom but creates more work in process design, data migration, testing, and user adoption.
A greenfield project should define which historical data must be available in the target system, which data can remain in an archive, and which open transactions must be migrated or completed before cutover.
Brownfield versus greenfield decision factors
Evaluate the two approaches against the same evidence rather than choosing from labels alone:
| Decision factor | Brownfield system conversion | Greenfield new implementation |
|---|---|---|
| Existing processes | Retains and adapts proven processes | Redesigns processes for the target model |
| Custom code | Requires inventory, remediation, and retirement decisions | Rebuilds only the extensions that remain necessary |
| Historical data | Keeps a larger body of existing data in the converted system | Selectively migrates required data and defines access to history |
| Business disruption | Often lower for stable processes | Usually higher during design, testing, and adoption |
| Transformation potential | Constrained by the existing system baseline | Stronger freedom to standardize and simplify |
| Main risk | Carrying forward technical or process debt | Underestimating design, migration, and adoption effort |
The decision should be documented in a scored assessment. Include business value, regulatory retention, data quality, custom-code volume, integration complexity, process harmonization, downtime tolerance, and the capacity of business representatives to participate.
Technical readiness checks
Run technical and functional discovery before committing to an approach. For a conversion, inventory add-ons, custom code, interfaces, batch jobs, enhancements, data volume, and business functions affected by S/4HANA simplifications. For a new implementation, define the target scope, migration objects, integrations, security model, and required extensions.
The SAP S/4HANA SUM overview is useful when assessing the technical sequence and prerequisites for a system conversion. Pair that assessment with the SAP S/4HANA simplification item check to identify functional and technical changes that can affect the existing system.
Create an evidence register with an owner, status, decision, and follow-up action for every major finding. This prevents unresolved assumptions about data, add-ons, interfaces, and custom code from becoming cutover surprises.
Project delivery and testing
Both approaches require a controlled delivery model, but the emphasis differs. Brownfield projects concentrate on remediation, regression coverage, compatibility, and controlled adoption of changed functions. Greenfield projects concentrate on fit-to-standard decisions, configuration validation, migration reconciliation, role design, and end-to-end process confirmation.
A useful delivery plan separates the work into discovery, design, build or remediation, migration rehearsals, testing, training, cutover, and hypercare. The SAP S/4HANA migration project phases provides a planning reference for organizing these activities.
Testing must cover business processes across applications and integrations, not only individual transactions. Include converted or migrated data, authorizations, batch processing, output, interfaces, reporting, error handling, and operational procedures. The SAP S/4HANA migration test strategy can be used to structure coverage and entry criteria.
A practical selection process
Start by defining the target business outcomes and the processes that must change. Next, establish a fact base for the current system: data quality, custom-code dependency, add-on status, integration landscape, process variation, and operational constraints.
Then score brownfield and greenfield against agreed criteria. A brownfield recommendation is stronger when the current system is stable, the business processes remain valuable, data quality is manageable, and the organization needs continuity. A greenfield recommendation is stronger when process debt is widespread, standardization is a strategic goal, historical data can be selectively handled, and the business can support extensive design and testing.
Record the decision together with excluded alternatives, assumptions, dependencies, and conditions that would trigger a reassessment. Governance should revisit the choice when discovery reveals a materially different data, integration, compliance, or process profile.
Common decision mistakes
Choosing brownfield solely to reduce project duration can preserve avoidable complexity and increase remediation effort later. Choosing greenfield solely because the current system is old can create unnecessary migration, adoption, and data-reconciliation work.
Other frequent mistakes include estimating custom-code effort from object counts alone, treating data migration as a late technical task, overlooking interfaces owned outside the SAP team, and postponing business process ownership until testing. Decision quality improves when evidence is reviewed early and when business and technical owners approve the same baseline.
Operational handover
Before go-live, define who owns conversion defects, migration reconciliation, interface monitoring, authorization issues, job scheduling, and business-process support. Prepare runbooks for cutover tasks, validation checks, rollback decisions, and the first operating period.
A successful approach is the one the organization can operate after the project ends. The final recommendation should therefore include support capability, data stewardship, release governance, training coverage, and a measurable plan for retiring temporary migration controls.