A migration approach that converts an existing SAP system into the new platform while preserving much of the current structure. It can reduce disruption and speed delivery, but it often carries forward legacy roles, customisations, and access risks unless teams deliberately remediate them during the project.
Expanded Definition
Brownfield migration in an SAP context means moving an existing landscape into a new platform while preserving significant portions of the current structure, data model, and process design. It is often chosen when business continuity, implementation speed, and cost control matter more than a clean redesign. In NHI and access governance terms, the critical point is that brownfield migration can also preserve old privilege patterns, technical users, service accounts, secrets distribution, and custom integrations unless those elements are deliberately reviewed and remediated. That makes it different from a greenfield approach, where teams rebuild controls with less inherited baggage. Guidance varies across vendors on how much legacy should be retained, but the security principle is stable: inherited access must be treated as untrusted until revalidated. For governance baselines, teams commonly map migration decisions to the NIST Cybersecurity Framework 2.0 to ensure identity, change, and recovery controls are not bypassed during conversion. The most common misapplication is treating brownfield migration as a technical copy-forward exercise, which occurs when project teams assume legacy roles and credentials remain acceptable because the underlying SAP workload still functions.
Examples and Use Cases
Implementing brownfield migration rigorously often introduces remediation overhead, requiring organisations to weigh faster delivery against the cost of revalidating inherited access, interfaces, and secrets.
- An enterprise migrates an SAP ECC environment to a newer platform while carrying forward role structures, then performs a post-migration review to remove dormant privileged accounts and outdated technical users.
- A finance team preserves custom batch jobs during conversion, but reissues certificates and API keys because existing secrets were embedded in scripts and CI/CD tooling.
- A regulated manufacturer keeps core process flows intact to reduce downtime, while validating every service account against least-privilege requirements before cutover.
- A migration program uses the Ultimate Guide to NHIs as a reference point to identify service accounts, secrets storage, and offboarding gaps that might otherwise be inherited unchanged.
- Security architects align the project with NIST Cybersecurity Framework 2.0 to ensure identity, protect, detect, and recover functions are tested before go-live.
These examples show why brownfield migration is attractive when the business cannot afford a full redesign, yet still requires explicit security gating for inherited access paths.
Why It Matters in NHI Security
Brownfield migration matters because it can preserve the very NHI weaknesses that organisations were trying to leave behind. Inherited service accounts, long-lived credentials, excessive privileges, and undocumented automation are especially risky when they are embedded in a legacy SAP landscape and then transferred into a new operating model. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which makes migration a high-risk moment for hidden access sprawl. A brownfield program that ignores those conditions may create a modern platform with the same old exposure. This is why teams often pair migration with vault cleanup, credential rotation, and explicit offboarding checks, rather than assuming the new environment resets trust. The Ultimate Guide to NHIs is useful here because it frames lifecycle and visibility as core controls, not optional extras, while the NIST Cybersecurity Framework 2.0 helps translate that into operational governance. Organisations typically encounter the real impact only after cutover reveals unexplained access paths or a credential compromise forces emergency remediation, at which point brownfield migration becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Brownfield migration often preserves secrets and legacy NHI exposure. |
| NIST CSF 2.0 | PR.AC-1 | Legacy roles and service accounts must be revalidated during migration. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero Trust requires explicit verification of every inherited access path. |
| NIST SP 800-63 | Assurance concepts inform how migrated credentials should be reissued or strengthened. | |
| OWASP Agentic AI Top 10 | LLM-08 | Migration programs can carry forward tool-using automation and agent permissions. |
Reissue machine credentials at the required assurance level instead of copying weak legacy authentication.
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?
