They often treat it as a data transfer problem instead of a governance problem. Old records, duplicate masters, and unused objects can carry stale permissions and distort control reporting, so cleanup must happen before data is loaded into S/4HANA.
Why This Matters for Security Teams
SAP migration fails when teams assume the main task is moving tables into S/4HANA. The real risk is carrying forward bad identity data, obsolete authorisations, and stale object ownership into a new control plane. That can distort SoD analysis, inflate access, and make remediation look complete when it is not. NHI Mgmt Group’s research shows 97% of NHIs carry excessive privileges, which is a useful warning sign for any migration that preserves old access patterns instead of re-validating them. See Ultimate Guide to NHIs — Key Research and Survey Results and the NIST Cybersecurity Framework 2.0 for the governance mindset that migration work requires.
Security teams also get tripped up by assuming legacy role design will map cleanly into the target environment. In practice, SAP projects often move faster than entitlement review, so dormant users, technical accounts, batch jobs, and legacy connectors keep access that no one re-justified. That creates a hidden trust inheritance problem: migrated records look modern, but the access behind them is still rooted in old assumptions. In practice, many security teams encounter failed remediation only after audit exceptions, privileged access drift, or interface outages have already spread across the new landscape.
How It Works in Practice
The safest migration approach treats data as part of an identity and control transformation. Before loading into S/4HANA, organisations should classify records by business value, owner, sensitivity, and operational dependency. That includes customer and vendor masters, but also service users, RFC accounts, background jobs, integration tokens, and any object that influences authorisation or reporting. Current guidance suggests cleaning and validating these assets in the source system first, because a clean target built from dirty input simply recreates the same governance gaps.
Practically, that means running entitlement review, duplicate detection, inactive object removal, and ownership assignment before cutover. Teams should align migration waves with control checks, not just technical loads. For example:
- Remove unused masters and obsolete objects before the extract step.
- Reconcile technical users, service accounts, and interfaces against actual system usage.
- Validate authorisation objects and inherited roles after each migration wave.
- Confirm that access recertification covers both human users and non-human accounts.
This matters because legacy SAP environments often contain broad entitlements that were tolerated for years as operational shortcuts. If those rights are copied forward, the migration can preserve excessive access at scale, even when the new platform appears more controlled. The NHI governance lens is useful here: identity lifecycle, rotation, and offboarding are not separate from migration, they are part of it. The same principle appears in NHI Mgmt Group’s research on visibility gaps and long-lived secrets, especially in the research and survey results. These controls tend to break down when cutover deadlines force a technical-only migration and ownership decisions are deferred until after go-live.
Common Variations and Edge Cases
Tighter migration control often increases project time and business disruption, so organisations must balance cutover speed against access assurance. There is no universal standard for this yet, but best practice is evolving toward phased remediation, not a single end-state clean-up.
Some SAP programmes choose selective data retention, where only active records move and inactive history stays archived. That lowers risk, but it can also hide patterns needed for audit, tax, or legal retention. Other environments rely heavily on third-party integrations, where migrating interface accounts too early can break downstream processes. In those cases, the safest path is to separate business-critical technical identities from low-risk cleanup work and validate each dependency explicitly.
Another edge case is global SAP estates with multiple business units. Local role models, naming conventions, and ownership rules often differ enough that a direct lift-and-shift creates governance inconsistencies. The practical answer is a clean mapping layer with agreed ownership, not a one-to-one copy of legacy access. Where organisations skip this, they usually discover the problem after go-live, when inherited access is already embedded in production workflows and audit evidence is no longer easy to reconstruct.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Migration must revalidate access rights, not just move data. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Legacy service accounts and secrets often retain excessive privilege after migration. |
| NIST AI RMF | GOVERN | SAP migration needs governance over identity, ownership, and control evidence. |
Inventory non-human accounts, remove stale privileges, and rotate or retire credentials before loading S/4HANA.
