An SAP S/4HANA brownfield migration is a system conversion: you take your existing SAP ERP (ECC) system and convert it in place to S/4HANA, keeping your configuration, custom code, open items and history. SAP’s own term for it is “System Conversion”. This guide explains what a brownfield implementation in SAP involves, what has to be true before you start, how it compares with greenfield and bluefield, and where projects actually go wrong. Facts are as of October 2026.
What is an SAP brownfield migration?
“Brownfield” is the common name for the system conversion path. SAP’s help documentation describes three ways to move from SAP Business Suite or SAP ERP to S/4HANA: system conversion, selective data transition and new implementation. Brownfield, bluefield and greenfield are the market names for those three.
In a system conversion you move the existing system itself. The SAP conversion guide states that this path is relevant if you are an existing SAP Business Suite customer who wants to change your system into an S/4HANA system. The conversion runs through the Software Update Manager (SUM). If the system is not yet on SAP HANA, SUM also handles the database migration in the same procedure. In practice that means three things happen in one technical run: an optional database migration to SAP HANA, installation of the S/4HANA software, and conversion of your data into the S/4HANA data structures.
What this means for you: the system keeps its identity. Your company codes, chart of accounts, organisational structure, customising, master data and transactional history come across. What changes is the data model underneath (for example, the Business Partner becomes the leading object for customers and suppliers), and a set of functions that SAP has simplified or replaced. Those changes are listed in SAP’s Simplification Item Catalog, and working through them is most of the real work.
Brownfield vs greenfield vs bluefield: how to choose
The three paths differ in what they do with your code, your data and your processes. The table below keys the choice to those three positions rather than to preference. For a longer treatment, see our three-way comparison for Saudi Arabia, our dedicated guides to greenfield migration and bluefield (selective data transition), and the SAP modernisation decision tree.
| Question | Brownfield (system conversion) | Bluefield (selective data transition) | Greenfield (new implementation) |
|---|---|---|---|
| SAP term | System Conversion | Selective Data Transition | New Implementation |
| What happens to the existing system | Converted in place with SUM | Redesigned and migrated selectively; SAP says it combines process redesign with keeping selected historical data | Left behind; a fresh S/4HANA system is built |
| Custom code | Kept, after remediation against the simplification list | Depends on the scope agreed for the selective transition | Only what you deliberately re-build |
| Data | All of it converts, including history | Selected data and history you choose to carry | Loaded with the SAP S/4HANA migration cockpit, which SAP states is included in the S/4HANA licence |
| Process redesign | Limited; processes stay largely as they are | Redesign possible alongside kept history | Full redesign; SAP recommends SAP Activate and SAP Best Practices |
| Best fit | Stable processes, a code base worth keeping, a need to keep full history, a fixed deadline | You want to redesign some processes or merge or split systems but must keep selected history | Processes you want to change substantially, heavy customisation you want to retire, new entities or a clean data start |
| Main risk | Carrying technical debt and bad data into the new system | Needs specialist tooling and experience; SAP strongly advises engaging SAP Digital Business Services or specialised SAP partners | Larger change management load and re-implementation scope |
A practical way to read it: if your processes are sound and your question is “can the code and data survive the move?”, brownfield is the natural candidate. If your question is “do we want to run the business differently on the new platform?”, that points to greenfield or bluefield. Many programmes end up with a mix, for example converting the main system and redesigning one business unit or a newly acquired company separately.
A note on trade-offs. Brownfield is often described as faster and cheaper than greenfield. That is a reasonable expectation when code and data are in good shape, but it is not guaranteed. We are not aware of duration or cost benchmarks published by SAP for the path, and a conversion with heavy custom code or poor master data can take longer than the plan assumed. Treat “faster” as a hypothesis to test in the assessment, not as a property of the method.
Why the 2027 date matters
The deadline pressure behind most brownfield programmes comes from SAP’s maintenance commitments for SAP Business Suite 7 core applications, which includes SAP ERP 6.0 (ECC). SAP’s maintenance strategy page states that SAP will provide mainstream maintenance for Business Suite 7 core applications until the end of 2027. SAP re-confirmed this in an SAP News post on 7 October 2026: mainstream maintenance remains available through 31 December 2027.
- Mainstream maintenance: through 31 December 2027.
- Optional extended maintenance: three years, from the beginning of 2028 to 31 December 2030. It is optional and chargeable; SAP states a premium of two percentage points on the maintenance basis.
- After the maintenance windows: SAP says on-premise Business Suite 7 systems will run under customer-specific maintenance, and that it will not be able to provide comprehensive support for issues involving third-party databases or Java. SAP’s guidance is that this should not be treated as a sustainable long-term operating model.
- SAP’s S/4HANA commitment: SAP announced maintenance for S/4HANA until the end of 2040 (press release, 5 February 2020).
The same October 2026 post describes a transition option for SAP ERP for qualifying customers. As SAP describes it, the system must first be moved to SAP ERP, private edition on SAP HANA before 31 December 2030, and the option covers 2031 to 2033 without support for Java-dependent capabilities. Eligibility is conditional and it is not a substitute for converting to S/4HANA, so read the SAP News post before counting on it. SAP also says moving a third-party database system to SAP HANA removes the database dependency but is not recommended as the strategic long-term path.
What this means for planning: a conversion that has to be live before 31 December 2027 needs to be scoped and started well ahead of that date. Extended maintenance buys time, but at a premium, and it is a bridge rather than a destination. For the commercial side of the decision, see our guide on whether to upgrade from SAP ECC to S/4HANA.
Not sure brownfield is your path?
We review your code position, data position and deadline, and tell you which of the three paths fits and why. No obligation.
Prerequisites for a brownfield implementation in SAP
Most surprises in a conversion come from prerequisites that were discovered late. This table lists what SAP’s conversion documentation requires or recommends, and what each item blocks if you ignore it.
| Prerequisite | What SAP states | What it blocks if missed |
|---|---|---|
| Unicode system | The system must be a Unicode system. If it is not, SAP describes a two-step approach: a combined upgrade and Unicode conversion to a supported start release first, then the conversion to S/4HANA. | The conversion cannot start; adds a full project step ahead of it |
| AS ABAP only (no dual stack) | Dual-stack systems (ABAP and Java in one system) are not supported for the conversion and must be split first (SAP Note 1655335). | The conversion cannot start |
| Supported start release | SAP’s conversion guide (older-release text) lists SAP ERP 6.0 enhancement packages 0 to 8 as start releases for single-step conversion, with restrictions for some support package levels (SAP Note 2659710). Earlier releases need a two-step approach. Verify the current note for the S/4HANA release you are targeting. | Forces an interim upgrade |
| Business Partner via Customer/Supplier Integration (CVI) | Only customers with Customer/Supplier Integration in place can move to S/4HANA. All customers and suppliers, including those with deletion flags and assigned contacts, must be converted to Business Partners (SAP Note 2265093). | Conversion fails the checks; poor master data quality surfaces here |
| Maintenance Planner stack | Mandatory first step. It checks components, add-ons and business functions and creates the stack file SUM needs. | SUM cannot run; unsupported add-ons are found here |
| Simplification Item Check | Mandatory. Each simplification item describes the business and technical steps, preparatory and follow-on, and is available as an SAP Note. SUM re-triggers the check. | Blocks the conversion until relevant items are resolved |
| Custom code review | Not mandatory but highly recommended. The custom code migration tool checks your code against the simplification list. | Broken or non-compliant programmes found late, in testing |
| SAP Readiness Check | Highly recommended rather than mandatory. SAP states it highlights simplification item relevance, high-level custom code analysis, add-on compatibility and sizing. | Scope and effort estimated blind |
Custom code is where the effort hides
SAP’s conversion documentation (older-release text) says the custom code checks “do not yet identify all” non-compliant instances, and that the code must also be tested in S/4HANA. Automated analysis tells you where to look; it does not replace testing. SAP also recommends combining the conversion with housekeeping, meaning you decommission custom code that nobody uses. Retiring unused code reduces what you must remediate and test. Pull usage statistics from production before you size the remediation work.
Business Partner conversion is a data project, not a technical switch
Because every customer and supplier must become a Business Partner, duplicates, incomplete addresses and records with deletion flags all have to be dealt with before the conversion can pass its checks. Start the CVI work early and run it in the sandbox first, because cleaning master data takes business time that technical teams cannot supply.
How a brownfield migration runs: the technical path
- Assess. Run the SAP Readiness Check and the Simplification Item Check against a copy of production. This tells you which simplification items apply, how much custom code is affected and whether your add-ons are supported.
- Plan the stack. Use Maintenance Planner to select the target S/4HANA release and generate the stack file. SAP recommends a test conversion in a dedicated system early, to get real check results.
- Prepare the source system. Complete the preparatory steps from the simplification items, convert to Business Partners, clean up and decommission unused code, and fix Unicode or dual-stack issues if they apply.
- Convert with SUM. SUM performs the optional database migration (DMO), installs the S/4HANA software and converts the data. Rehearse this on a copy of production more than once and record the runtime each time.
- Follow-on activities. Complete the follow-on steps from the simplification items, adapt custom code, and test the business processes end to end.
- Cutover and go-live. Run the production conversion in the agreed downtime window and stabilise.
Downtime: which SAP tool does what
Downtime planning is where terminology goes wrong. SAP’s SUM documentation lists distinct downtime-reduction options for different scenarios:
| Option | Intended scenario (per SAP) | Relevant to ECC conversion? |
|---|---|---|
| Downtime-optimized DMO | Migration to SAP HANA (SAP Note 2442926) | Yes, where the conversion includes a database migration |
| Downtime-optimized Conversion (doC) | Conversion to S/4HANA (SAP Note 3074543, SUM 2.0 SP12 or later); SAP states it is available for educated consultants (ADM329) | Yes, this is the conversion-specific option |
| near-Zero Downtime Maintenance (nZDM) | Update and upgrade scenarios (SAP Note 1678565) | No, it is not a conversion technique |
| Zero Downtime Option (ZDO) | Updates and upgrades of S/4HANA; requires educated consultants (ADM330) | No, it applies after you are on S/4HANA |
The practical point: if a vendor promises “near-zero downtime” for your ECC conversion, ask which SAP option they mean and which SAP Note it rests on. Whichever option you use, the achievable downtime depends on your database size, your hardware and the number of rehearsals, so quote only figures from your own test runs.
Typical project phases
We are not aware of a standard duration published by SAP for a system conversion, so we do not give month counts here. Duration depends mainly on custom code volume, data volume and quality, add-on complexity and how much testing the business can absorb. The table shows the usual phases and what drives their length.
| Phase | What happens | What drives its length |
|---|---|---|
| 1. Discover and assess | Readiness Check, simplification items, custom code usage, add-on and interface inventory, path decision | Number of systems, quality of documentation |
| 2. Prepare | CVI and master data cleansing, code decommissioning and remediation, Unicode or dual-stack fixes, sandbox conversion | Custom code volume, master data quality |
| 3. Convert and rehearse | Repeated SUM runs on copies of production, runtime measurement, downtime tuning | Database size, hardware, number of rehearsals |
| 4. Test | Functional, integration, regression and user acceptance testing, interface and authorisation checks | Process breadth, test automation, business availability |
| 5. Cutover and go-live | Production conversion in the downtime window, reconciliation, hypercare | Downtime window, cutover rehearsal quality |
Risks of a brownfield implementation
- Technical debt comes with you. A conversion preserves what you have, including unused code, poor master data and workarounds. Without housekeeping, you pay to convert things you do not need.
- Custom code underestimated. Automated checks do not find everything, as SAP itself notes. Budget testing time for custom programmes, enhancements and interfaces.
- Prerequisites found late. Unicode, dual stack and Business Partner conversion are blockers, not tasks to leave for the end.
- Add-ons and third-party tools. Add-ons that Maintenance Planner does not support in the target release need replacing or removing before the conversion.
- Downtime surprises. The production run is only as predictable as your rehearsals. A single test conversion is not a downtime estimate.
- Missed redesign opportunity. Converting as-is means you keep old process habits. If the aim was to change how the business runs, brownfield may be the wrong path.
- Deadline compression. Starting close to the 2027 date leaves little room to absorb rehearsal failures or testing findings.
Brownfield migration and your deployment model
A brownfield conversion is not tied to one deployment model. Whether you run S/4HANA on-premise, in a private edition under RISE with SAP, or elsewhere is a separate decision. Our comparison of RISE vs GROW with SAP (and the Saudi Arabia edition) covers that choice, and our RISE with SAP page explains how we support it. If you are weighing Saudi-specific delivery, see our SAP migration services in Saudi Arabia.
Frequently asked questions
What is a brownfield migration in SAP?
It is a system conversion: your existing SAP ERP system is converted in place to S/4HANA using the Software Update Manager, keeping configuration, custom code and data. SAP’s documentation calls the path “System Conversion”.
What is the difference between brownfield and greenfield?
Brownfield converts the system you already run. Greenfield (SAP’s “New Implementation”) builds a new S/4HANA system and loads data into it, typically with the SAP S/4HANA migration cockpit. Brownfield keeps your processes and history; greenfield lets you redesign them. Our greenfield migration guide covers the other side.
What is bluefield?
Bluefield is the market name for SAP’s selective data transition. SAP describes it as combining the redesign of business processes with the option of keeping selected historical data, and advises engaging SAP Digital Business Services or specialised partners because some of the functions are not generally available. See our bluefield guide.
Can I do a brownfield migration from any ECC version?
Not every release converts in a single step. SAP’s conversion guide (older-release text) lists SAP ERP 6.0 enhancement packages 0 to 8 as start releases for single-step conversion, with restrictions for some support package levels. Verify the current SAP Note for your target S/4HANA release, since start-release rules vary by release.
When does ECC support end?
SAP states mainstream maintenance for Business Suite 7 core applications, including ECC 6.0, runs until 31 December 2027, with optional extended maintenance from 1 January 2028 to 31 December 2030 at a two-percentage-point premium on the maintenance basis. SAP reconfirmed these dates in October 2026.
Do I need Business Partner conversion for a brownfield migration?
Yes. SAP states that only customers with Customer/Supplier Integration in place can move to S/4HANA, and all customers and suppliers must be converted to Business Partners.
Is nZDM the way to cut downtime in an ECC conversion?
No. SAP documents nZDM for update and upgrade scenarios. For conversion to S/4HANA, the SAP-documented option is downtime-optimized Conversion (doC), plus downtime-optimized DMO where a database migration is included. doC is available to educated consultants (ADM329). With either option, size the downtime from your own test runs.
How long does a brownfield migration take?
There is no standard duration we can responsibly quote. It depends on custom code volume, data volume and quality, and testing scope. The way to get a defensible number is a Readiness Check plus at least one test conversion on a copy of production.
Get a plan based on your own system
A short assessment of your custom code, master data and deadline will show whether a system conversion fits, and what it would involve. See also our S/4HANA business case service.
