When should organisations choose Greenfield over Brownfield for SAP S/4HANA migration?

Why This Matters for Security Teams

The Greenfield versus Brownfield choice is not just a programme-management decision. It changes how much technical debt, process debt, and data debt gets carried into SAP S/4HANA, and that has direct security consequences. Brownfield can preserve hidden risk when legacy custom code, old authorisations, and brittle integrations are already difficult to govern. Greenfield creates more redesign effort, but it also gives teams a cleaner chance to reset controls, simplify role design, and remove inherited exceptions. NIST guidance in the NIST Cybersecurity Framework 2.0 is clear that resilience depends on reducing unmanaged complexity.

For SAP environments, the governance question is often whether the current estate can be trusted to support a conversion without reintroducing the same access problems in a new platform. That is why a Brownfield path is usually safer only when the existing operating model is already well controlled, documented, and actively maintained. Where that is not true, Greenfield offers a stronger reset point. NHIMG research on SAP Breach shows how SAP risk often accumulates through long-lived complexity rather than a single obvious failure. In practice, many security teams discover the real cost of preserving the old model only after migration scope has already been approved.

How It Works in Practice

The decision usually comes down to four questions: how much custom code must be retained, how consistent the master data is, whether the current process design still matches business needs, and how much risk the organisation is willing to carry forward. Greenfield is typically chosen when the current landscape has become too fragmented to justify conversion, especially where authorisations, interfaces, and data definitions have drifted over time. Brownfield is usually chosen when the business needs continuity, and the existing process baseline is stable enough to replatform with minimal redesign.

Security teams should evaluate migration choice alongside control design, not after it. A Greenfield programme can support cleaner segregation of duties, simpler role mining, and better removal of obsolete accounts and elevated access. Brownfield can still be secure, but it requires more discipline around cleanup before, during, and after technical conversion. NHIMG’s Ultimate Guide to NHIs highlights how unmanaged identities and overprivileged access become harder to govern as environments grow in complexity, which is a useful parallel for SAP landscapes with decades of accumulated entitlements. The same logic applies to SAP service users, batch jobs, technical connectors, and interface credentials.

• Choose Greenfield when custom code is excessive, process redesign is required, or legacy data cannot be trusted as-is.
• Choose Brownfield when the current process model is still valid and the main goal is platform modernisation.
• Use a control review to identify obsolete roles, dormant technical accounts, and undocumented integrations before migration.
• Map critical SAP business functions to least-privilege access and remediation priorities before any cutover.

For security and architecture teams, the practical test is whether the organisation can cleanly define what should survive the move. If the answer is no, a Greenfield build often reduces long-term exposure more than it increases short-term effort. These controls tend to break down when the source estate has undocumented customisations, because the migration team cannot reliably distinguish essential business logic from inherited risk.

Common Variations and Edge Cases

Tighter migration governance often increases cost and timeline pressure, requiring organisations to balance delivery speed against the value of a cleaner control baseline. That tradeoff is especially visible in mergers, carve-outs, and subsidiary rollouts, where one business unit may justify Greenfield while the core enterprise stays on Brownfield.

There is no universal standard for this yet, but current guidance suggests treating hybrid approaches as a separate decision rather than a compromise by default. Some organisations run Brownfield for the core ERP and Greenfield for new subsidiaries or acquired entities. Others use selective redesign, where only the most problematic modules, data sets, or integrations are rebuilt. That can be sensible, but it should not become a way to avoid removing insecure legacy design.

One common edge case is a Brownfield conversion that still needs substantial process reengineering after go-live. In those situations, the organisation may keep the old complexity and still pay for redesign later, which weakens the case for Brownfield. Another edge case is a Greenfield programme that ignores existing security lessons and recreates the same access model in a new tenant. That is why change control, identity governance, and process ownership matter as much as the migration method itself. NHIMG’s SAP SQL Anywhere Monitor Hardcoded Credentials analysis is a reminder that legacy implementation shortcuts often survive long after the original business need has passed.

Related resources from NHI Mgmt Group

• What is the difference between greenfield, brownfield, and bluefield ERP migration approaches for security and governance teams?
• What breaks when SAP data is not classified before migration to S/4HANA?
• What is the difference between greenfield, brownfield, and hybrid SAP S/4HANA migration approaches?
• Why does a Greenfield migration usually create more governance and change-management risk than a Brownfield conversion?