S/4HANA on AWS: brownfield vs greenfield vs selective transition

"Should we go greenfield or brownfield?" is the question every S/4HANA programme opens with, and it is usually the wrong place to start. The path is a consequence of decisions about your current system, not a decision in itself. This post works through what actually drives the answer, then where the AWS-side sizing fits once the path is settled.

The three paths, briefly

• Greenfield — a new S/4HANA implementation. Processes get redesigned, master data gets rebuilt, history is left behind or archived. The cleanest result and the largest project.
• Brownfield — a system conversion. The existing ECC system becomes S/4HANA in place, keeping customisation and history. Less disruptive, but you carry forward whatever technical debt you already have.
• Selective data transition — a middle path. A new S/4HANA system, but with selected configuration and data carried over. More control than brownfield, less rebuild than greenfield, and more tooling-dependent than either.

The questions that actually decide it

Rather than starting from the path, start from these. The answers point at the path on their own.

How much of the current system is worth keeping?

If the existing processes are a competitive liability and the customisation is mostly scar tissue, the cost of carrying it forward is the argument for greenfield. If the system broadly works and the business has no appetite to re-test every process, brownfield's "keep what works" is the pragmatic answer.

What is the appetite for business disruption?

Greenfield means re-training, re-testing and a meaningful change-management effort. Some organisations have the bandwidth and the mandate; many do not. Brownfield is the lower-disruption path precisely because the business processes survive the move. Be honest about which kind of organisation you are.

How clean is the data?

Greenfield is an opportunity to leave bad data behind, but only if you have the means to rebuild the good data cleanly. Brownfield brings the data quality you have today along with everything else. If a data-cleansing project is happening anyway, that tilts the calculus toward greenfield or selective.

What is the deadline pressure?

Timeline often decides in practice even when it should not in theory. Brownfield is usually the faster route to "running on S/4HANA"; greenfield is the slower route to "running on a better S/4HANA". A hard deadline tied to ECC maintenance dates pushes many landscapes toward conversion.

Where AWS fits — and where it does not

Notice that none of the questions above are AWS questions. The path is a functional and organisational decision. AWS enters once the path is chosen, and it is largely the same infrastructure problem either way:

• Sizing the target. S/4HANA on a HANA database needs HANA-certified compute. The certified EC2 families change over time, so the right move is to size against the current list rather than a number someone remembers from a previous project.
• The landing zone underneath. Greenfield or brownfield, S/4HANA lands in an AWS account structure with a network, security baseline and IAM model. Building that well once is independent of the migration path. We keep a working checklist for SAP-on-AWS landing zones.
• The cutover. Brownfield conversions and greenfield go-lives both need a rehearsed cutover window with a rollback plan. The AWS-side tooling — Migration Hub, Application Migration Service — supports both; the wave planning differs.
• HA and DR. The productive HANA gets HANA System Replication across Availability Zones and a DR posture across regions, regardless of how it got there.

The one place the path does change the AWS work meaningfully is the transition window. A brownfield conversion often runs the source and target in parallel for a period; a greenfield build runs the new system alongside the old until cutover. Both need capacity planned for the overlap, and both benefit from non-production auto-shutdown so the parallel run does not double the bill for longer than necessary.

And RISE?

RISE with SAP is a fourth option that cuts across this: SAP runs the infrastructure for you, on a hyperscaler, under one contract. It is the right answer for some landscapes and the wrong one for others, and the honest comparison deserves its own treatment — which is why we wrote RISE with SAP vs self-hosted on AWS. Many mid-size estates end up hybrid: some workloads on RISE, others on a self-hosted AWS landing zone next to it.

A practical sequence

1. Answer the four questions above with the business, not just IT. The path falls out of the answers.
2. Once the path is set, size the S/4HANA target against the current HANA-certified instance list.
3. Build the landing zone properly — it outlives the migration and you do not want to rebuild it later.
4. Plan the cutover and the rollback, then rehearse the cutover before the real one.
5. Stand up monitoring before go-live, not after. The first week on a new system is exactly when you most want one view of work processes, jobs, dumps and HANA signals.

That last point is where Farrenio fits after the move: SM50, SM37, ST22 and the rest cross-system, alongside HANA database signals, in one view from day one. As an AWS reseller for SAP, the landing zone, the sizing and the operate-after-go-live are the work we do.

If you want a sized S/4HANA-on-AWS landing zone and an honest read on which migration path fits your situation, write to contact@farrenio.com.