Brownfield vs greenfield S/4HANA: how to actually choose

If you run SAP ECC in Australia, you have a decision to make before mainstream maintenance ends. The three paths are well documented. Choosing between them is where most of the confusion sits, largely because the framing you get from vendors tends to serve the vendor.

The three options, briefly

Brownfield conversion takes your existing system — configuration, custom code, master data, transactional history — and converts it in place to S/4HANA. Same system, same client, new platform.

Greenfield implementation builds a new S/4HANA system and migrates only what you choose to bring. Configuration is redone, usually closer to standard.

Selective data transition sits between them: a new system, but with selected configuration, history and master data carried across.

Why the usual framing is unhelpful

The framing you usually encounter is that brownfield is the technical path and greenfield is the transformation path — that brownfield is faster and cheaper but carries technical debt, while greenfield is a chance to clean up but costs more.

That is accurate and almost useless, because it describes a trade-off without telling you where you sit on it. Every business would prefer to clean up if it were free. The real question is how expensive your existing estate makes each option, and that is knowable before you decide.

The decision is not philosophical. It is an arithmetic problem you can solve with data you already have in the system.

The question that decides it

How much of your custom code is still earning its keep?

Most ECC systems that have been running a decade or more have accumulated hundreds or thousands of custom objects. Reports built for a manager who left in 2016. Enhancements written around a process that changed twice since. Interfaces to systems that were decommissioned.

You can measure this. SAP Readiness Check identifies which custom objects are incompatible with S/4HANA. ABAP Test Cockpit assesses code quality and remediation effort. Usage statistics show what has actually executed in the last year, as opposed to what merely exists.

Run those three together and you get an inventory with a defensible recommendation against each object: remediate, rewrite or retire. In our experience a substantial share falls into retire — sometimes a third or more, occasionally much higher.

When brownfield is right

• Your custom code estate is modest, or a high proportion of it is still actively used and S/4HANA-compatible.
• Your business processes work and you have no appetite to redesign them right now.
• You need transactional history in the system rather than in an archive.
• Your constraint is time or budget rather than process quality.
• You have a single production system rather than a landscape that has grown through acquisitions.

Brownfield is not the lesser choice. For a business whose processes genuinely fit, it is faster, less disruptive and considerably cheaper, and it preserves institutional knowledge encoded in configuration that nobody has documented.

When greenfield is right

• Custom code analysis shows a large proportion of your estate needs remediation or has already fallen out of use.
• Your configuration has drifted so far from standard that upgrades are already painful.
• You are consolidating multiple systems, often after acquisitions.
• Your processes have genuinely changed and the system is now the constraint.
• You have the organisational appetite for a business transformation, not just a technical one.

That last point matters more than the technical criteria. Greenfield done properly is a business change program. Attempted as a technical project without business ownership, it tends to reproduce the old processes in a new system at greater cost.

Where selective transition fits

Selective data transition suits landscapes where neither extreme fits — typically a group carrying several company codes with different levels of customisation, where some entities want a clean start and others cannot afford the disruption.

It offers the most control and it is the most complex to execute. It generally requires specialist tooling and partners, and it usually costs more than either alternative. Choose it because your landscape demands it, not because it sounds like a compromise.

The 2027 constraint

SAP's mainstream maintenance for ECC runs to the end of 2027, with extended maintenance available afterwards at additional cost. So nothing switches off — it becomes a commercial question.

The more pressing constraint is capacity. Australia has a finite pool of experienced SAP consultants, and demand is concentrating as the deadline approaches. Rates rise, availability tightens, and the firms with the deepest benches prioritise their largest programs. A business that starts scoping in 2027 will pay materially more than one that started in 2026, for reasons that have nothing to do with the technical work.

What to do first

Before you take a single vendor proposal seriously:

1. Run the custom code analysis. Readiness Check plus ATC plus usage statistics. You need the inventory before you can evaluate any proposal.
2. Establish who owns the decision. If it is IT alone, you are heading for a technical conversion regardless of what the business needed.
3. Get the analysis as a document you own. Not a vendor slide deck. Something you can take to three firms and get comparable quotes against.
4. Decide what you are optimising for — cost, speed, process improvement or risk. You will not get all four, and knowing which one you are trading away prevents an expensive mid-program reversal.

The businesses that navigate this well are not the ones that pick the fashionable option. They are the ones that measured their estate before deciding, and could explain the reasoning afterwards.