Brownfield Migration

Expanded Definition

Brownfield migration describes a move from an existing enterprise system into a new platform while reusing as much of the current environment as possible. In SAP programmes, it usually means retaining core process design, selected custom objects, and parts of the user and role model rather than rebuilding everything from scratch.

The term is often used in contrast to a greenfield approach, where teams redesign more aggressively and accept more change. Brownfield delivery can shorten timelines and lower transition friction, but it also preserves technical debt and governance debt. That means old role names, inherited authorisations, unneeded interfaces, and long-lived exceptions can survive the migration unless they are explicitly reviewed.

For security teams, the key boundary is that brownfield migration is not itself a control strategy. It is a delivery method with security consequences. A common misunderstanding is to treat migration as a lift-and-shift exercise and assume the new platform will naturally be cleaner. In practice, the inherited structure is often the main source of residual access risk.

Examples and Use Cases

Brownfield migration appears in projects where continuity matters more than redesign. Teams may keep existing business roles, mapped transactions, and custom extensions so the organisation can move faster and reduce change resistance.

• An SAP ERP environment is upgraded into a successor platform while preserving most authorisation concepts and selected custom workflows.
• A finance organisation retains historic approval paths during migration to avoid disrupting month-end close and audit sign-off.
• A regulated business carries forward legacy integration points so downstream systems do not need immediate rework.
• An IAM team keeps role mappings intact initially, then schedules later cleanup to reduce project risk during cutover.

The main trade-off is speed versus revalidation. Brownfield migration can protect operational continuity, but it also delays structural cleanup and can make post-migration remediation more expensive if inherited access is not catalogued early.

For teams running large SAP estates, the practical reality is that migration scope often follows business continuity pressure, not security idealism. That makes early scoping of sensitive roles, privileged pathways, and custom access logic especially important.

Security Implications

Brownfield migration can preserve weaknesses that were tolerated in the old environment but become more dangerous in the new one. The most common issue is that existing entitlements are copied forward with only partial review, so dormant accounts, excessive access, and outdated segregation-of-duties exceptions survive the transition.

That creates a larger blast radius when a role is overprivileged or when a legacy interface still authenticates with broad authority. It can also obscure accountability if old approval chains, service accounts, or custom transports are no longer well understood. In audit terms, the migrated system may look modern while still depending on legacy exceptions that were never fully re-justified.

Observable symptoms often include role sprawl, duplicate access paths, inconsistent naming between old and new structures, and slow remediation because ownership is unclear. The security problem is not the migration method itself, but the tendency for inherited access to become accepted as baseline without fresh validation.

Domain and Governance Relevance

In enterprise identity governance, brownfield migration matters because it determines whether access control is re-established or merely transferred. When a migration preserves the old structure, the organisation is effectively inheriting prior decisions about privilege, segregation, and exception handling.

That is especially important in SAP environments, where business roles, technical users, integrations, and privileged access often interact tightly. If the migration includes non-human identities such as service accounts, batch users, or API credentials, the same brownfield logic can preserve machine access that should have been rotated, re-scoped, or retired.

For NHI governance, the practical question is not whether the platform changed, but whether every non-human account still has a current owner, a justified purpose, and a bounded lifespan. Brownfield migration is therefore a governance checkpoint as much as a technical delivery choice.

Where the migration is executed without a deliberate entitlement reset, the new environment may simply inherit old trust assumptions under a new interface.

Related resources from NHI Mgmt Group

• What is the difference between greenfield, brownfield, and bluefield ERP migration approaches for security and governance teams?
• 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?
• When should organisations choose Greenfield over Brownfield for SAP S/4HANA migration?