What is the difference between Greenfield and Brownfield SAP S/4HANA implementation from a controls perspective?

Control redesign versus control carryover in SAP S/4HANA migrations

From a controls perspective, the key difference is whether the organisation is designing a new control environment or reworking an inherited one. Greenfield gives teams the chance to reset authorisation models, segregation of duties, logging, interface governance, and custom exception handling around the target design. Brownfield preserves more of the existing business and security logic, which reduces redesign effort but also keeps legacy assumptions, hidden access paths, and technical debt in scope.

That distinction matters because SAP control failures often emerge at the seams between business process design, role architecture, and integration dependencies. A greenfield programme can still fail if the target state is underspecified, but a brownfield programme can fail because teams assume inherited controls are already fit for S/4HANA and do not revalidate them against changed processes, new modules, or revised data flows. In practice, many control gaps are discovered only when inherited roles, custom transactions, and integration accounts are tested against the new operating model rather than during the migration design itself.

For broader control planning and identity governance context, NHI Management Group recommends reviewing the OWASP Non-Human Identity Top 10 where SAP integrations, service accounts, and automation credentials form part of the control boundary.

How controls are treated differently in each migration approach

greenfield implementation treats controls as part of the target-state architecture. That means access design, approval workflows, role definitions, SoD rules, logging strategy, emergency access, and interface controls are typically defined from first principles. The advantage is clarity: the programme can align controls to the new process model instead of trying to preserve structures that were built for ECC, custom extensions, or older business rules. The downside is that the organisation must be precise about what each process should allow, because a clean start does not automatically produce a secure design.

brownfield implementation begins with the existing control landscape and then adapts it to S/4HANA. This is often faster, but it creates a stronger dependency on the quality of the legacy environment. If the old role model contains overbroad access, redundant composite roles, undocumented firefighter use, or weak segregation design, those problems can survive the transition unless they are explicitly removed. Brownfield projects therefore need stronger validation of what is being preserved, what is being remapped, and what becomes invalid because the underlying transaction set, data model, or process flow has changed.

• Greenfield usually allows cleaner role rationalisation and fewer inherited exceptions.
• Brownfield usually requires deeper analysis of legacy authorisations, because inherited access may still work even when it is no longer appropriate.
• Both approaches need testing for business process integrity, but brownfield places more weight on regression testing of controls that were assumed to be stable.
• Both approaches need special attention to non-human access such as batch jobs, interfaces, and API credentials, because these often sit outside standard user review processes.

Where this guidance breaks down is when the migration is technically brownfield but operationally behaves like a redesign, such as when major process harmonisation, data conversion, or custom code retirement changes the effective control model.

When the migration choice changes governance, testing, and exception handling

Tighter control redesign often increases delivery effort, requiring organisations to balance speed against assurance. In a greenfield programme, the biggest governance challenge is deciding which business exceptions are still justified in the new design, because the absence of legacy controls can make it easier to either over-permit or over-restrict access. In a brownfield programme, the hardest governance decision is usually what must be retired rather than retained, since preserving the old model can keep exceptions alive by default.

The practical edge cases are important. A brownfield conversion may still need a near-greenfield treatment for roles if the legacy environment has years of accumulated exceptions or inconsistent business role design. Conversely, a greenfield deployment may still inherit brownfield-like risk if the organisation reuses old interfaces, shared technical users, or unchanged approval assumptions. There is no consensus that one approach is inherently more secure; the real issue is whether the programme has enough control evidence to prove that the target state matches the intended operating model.

Practitioners should also distinguish process controls from technical controls. A clean SAP build does not eliminate the need for approval design, monitoring, and periodic recertification, while a conversion project does not justify preserving controls that were only tolerable in the old platform. The best indicator of maturity is whether the team can explain, test, and defend each major access path after the migration, especially where roles, interfaces, and privileged functions intersect.

In practice, brownfield migrations tend to expose control debt late, while greenfield migrations tend to expose design gaps early.

Practitioner Guidance

What to prioritise: Treat role architecture, privileged access, interface accounts, and SoD rules as migration design objects, not as post-cutover cleanup. The control model should be evaluated against the target business process, not just against the old system structure.

What to verify: Confirm which controls are truly inherited, which are merely remapped, and which are invalid because the S/4HANA process or technical design has changed. Validation should include business-critical transactions, emergency access, and automated access paths that are often missed in user-centric reviews.

Decision rule: If the legacy environment already carries significant role sprawl or undocumented exceptions, assume brownfield will need greenfield-style rationalisation for the control layer even if the technical migration is incremental.

Practitioner takeaway: The security question is not whether SAP S/4HANA is greenfield or brownfield, but whether the migration creates a control model that is explicit, testable, and still valid after the underlying process changes.

Related resources from NHI Mgmt Group

• What is the difference between greenfield, brownfield, and hybrid SAP S/4HANA migration approaches?
• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• What is the difference between code scanning and runtime identity monitoring?