TL;DR: SAP S/4HANA migration creates control, data, and change-management risk because custom code, integrations, and legacy cleanup can break business continuity if they are not governed carefully, according to SafePaaS. The main issue is not the upgrade itself but whether identity, access, and process controls survive the transition intact.
At a glance
What this is: This blog argues that SAP S/4HANA migration often fails on governance, not technology, because customizations, integrations, data cleanup, and change management can all disrupt access and control continuity.
Why it matters: IAM, IGA, PAM, and application owners need to treat ERP migration as a control-preservation exercise, or the new platform can inherit broken privileges, unstable processes, and weak accountability.
Context
SAP S/4HANA migration is not just a technical upgrade. It is a governance exercise that has to preserve identity, access, process controls, and operational continuity while the underlying ERP environment changes.
SafePaaS frames the main challenge as the difficulty of keeping controls effective across custom code, integrations, data movement, and stakeholder change management. For IAM and application owners, the key question is whether the controls that worked in the legacy SAP estate still work once the transition begins.
The article treats migration risk as a programme issue rather than a single-system issue. That is the right lens, because failures often appear at the boundaries between systems, teams, and control ownership, not inside one module alone.
Key questions
Q: What breaks when SAP S/4HANA migration is not governed as a control programme?
A: Controls tied to legacy workflows, integrations, and master data can stop matching the new process environment even when the technical migration succeeds. That creates gaps in approvals, reconciliations, and ownership because the organisation assumes old control logic still applies. The safest approach is to treat control mapping as a core migration deliverable, not a post-go-live task.
Q: When does SAP migration create the most risk for IAM and controls teams?
A: Risk rises when custom code, integrations, and data cleanup happen at the same time as business process change. That combination makes it easy to move obsolete access, weak approvals, and bad reference data into the new environment unless controls are revalidated against the target design.
Q: What are the signs that migration controls are failing in an SAP programme?
A: Common signs include unclear control ownership, inconsistent master data, unresolved interface dependencies, and users relying on old approval habits after training. If business units cannot explain who approves exceptions or how records move between systems, the control design has not survived the transition. Those symptoms usually appear before a formal audit finding does.
Q: Who should own control readiness during an SAP S/4HANA migration?
A: Business owners, IAM, ITSM, and controls teams should share accountability, but one function must own the post-go-live process map. If no one is accountable for approvals, escalation, and exception handling, users will create workarounds that weaken the new control model.
Technical breakdown
Why SAP migration breaks control continuity
SAP S/4HANA migration changes system behaviour, business workflows, and integration points at the same time. That matters because many controls are embedded in process logic, approval paths, and downstream dependencies rather than sitting in a single IAM tool. When customisations, third-party applications, or ITSM links change, the effective control environment can drift even if the target platform is correctly installed. The migration problem is therefore not only technical compatibility but control preservation across a moving target.
Practical implication: map controls to business processes and integrations before cutover, not after the new system is live.
Data migration and legacy cleanup as identity control issues
Data migration is usually discussed as a records problem, but in ERP programmes it is also an identity and entitlement problem. Old customers, unused materials, and stale master data can preserve access paths, reporting dependencies, or approval logic that no longer reflect the operating model. ETL design, validation, and cleanup therefore affect who can act on what, not just whether records move successfully. If the source data is inconsistent, the target access model and downstream controls inherit that inconsistency.
Practical implication: validate master data, ownership, and access dependencies together so cleanup does not leave hidden entitlement residue.
Change management for IT application controls
Change management in ERP migration has two layers: the technical rollout and the human adjustment to new controls. A structured impact assessment, clear communication, user training, and milestone-based project governance reduce the chance that control owners, approvers, or business users misunderstand their new responsibilities. Without that discipline, controls may exist on paper but fail in practice because people continue to follow the old workflow. In migration programmes, control adoption is part of control design.
Practical implication: include control owners in training and sign-off so new workflows are actually followed after migration.
Breaches seen in the wild
- SAP Kubernetes secrets exposure 2023: Kubernetes secrets committed to GitHub exposed 203 valid registry credentials, including SAP artifact repository access. SAP closed it after Aqua's report.
- SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890): Hard-coded credentials in SAP SQL Anywhere Monitor scored CVSS 10.0 (CVE-2025-42890); SAP removed the tool, and no exploitation was seen.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
ERP migration exposes control drift before it exposes technical failure: The biggest risk in SAP S/4HANA migration is not that the platform cannot run, but that the existing control model no longer matches the new operating reality. Custom code, integrations, and business process changes can all move faster than governance can recertify ownership and authorization paths. The practitioner lesson is that migration planning has to treat controls as dependencies, not as afterthoughts.
Application controls do not survive migration by default: Controls tied to legacy workflows can appear intact while the underlying process has changed shape. That creates a false sense of continuity, especially where approvals, exceptions, and reconciliations depend on interfaces to surrounding systems. The migration itself becomes the point at which latent control assumptions are tested, and teams that do not remap those assumptions end up with compliance gaps.
Data cleanup is a control decision, not just a hygiene task: Removing obsolete customers, materials, and inconsistent records changes the operational identity surface of the ERP estate. If organisations treat cleanup as a technical housekeeping exercise, they miss the fact that stale master data often carries access and process logic forward. The practitioner conclusion is that data remediation and access remediation need to be governed together.
Change management is the control plane for ERP transition: Communication, training, and stakeholder alignment determine whether new controls are adopted or bypassed. A migration can be technically complete and still fail governance objectives if users continue to operate with legacy assumptions. The field should treat control adoption as part of migration success criteria, not a post-go-live clean-up item.
SAP migration needs a cross-functional ownership model: The article points to a programme that spans senior management, controls experts, IT, and business stakeholders. That is the correct shape of ownership for ERP change because no single team can preserve access, process, and data integrity alone. Practitioners should align governance to the migration workstream structure, not to legacy team silos.
What this signals
Control continuity is the real migration metric: Organisations should judge SAP S/4HANA migration by whether approvals, interfaces, and ownership remain intelligible after cutover, not by whether the platform simply goes live. When process controls survive, compliance and operations are much easier to govern.
Cross-functional governance is mandatory, not optional: The article implies a programme structure that brings together management, controls expertise, technical teams, and business owners. That is the only realistic way to preserve identity-related controls across ERP transition because control failure usually happens at handoff points.
Migration cleanup should include access logic: When teams remove obsolete records and customisations, they should also check whether those artefacts carried approval rules, ownership assumptions, or downstream dependencies. Otherwise, the new environment inherits old governance debt in a cleaner shape.
For practitioners
- Map controls to migration workstreams Tie each key business control to a specific migration workstream so ownership is explicit across custom code, integrations, data, and cutover tasks.
- Validate interfaces before cutover Test connectivity between the new SAP environment and ITSM systems, third-party applications, and legacy data flows before go-live.
- Treat data cleanup as governance work Review obsolete customers, unused materials, duplicates, and inconsistent master data with access and process owners, not just technical teams.
- Build control owner training into change management Train approvers, process owners, and support teams on the new workflows, exceptions, and responsibilities so the control model is usable after migration.
Key takeaways
- SAP S/4HANA migration can weaken governance when custom code, integrations, and business workflows change faster than controls are remapped.
- The article puts emphasis on data cleanup, impact assessment, testing, and stakeholder alignment because each one affects whether controls still function after cutover.
- Teams should treat control ownership and access continuity as migration deliverables, not as post-migration housekeeping.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on preserving access and control continuity through SAP migration. |
| GV.PO-01 — Organisational cybersecurity policy | Migration governance, ownership, and stakeholder alignment are central to the article's control message. | |
| Recommendation — Review permissions and entitlements before and after cutover to keep authorizations aligned to the new process model. Define policy ownership for migration controls so business and technical teams share clear accountability. | ||
| CIS Controls v8 | CIS-5 — Account Management | ERP migration can leave account and access dependencies intact if legacy cleanup is incomplete. |
| Recommendation — Reconcile active accounts and related dependencies during SAP cleanup to prevent stale access from carrying forward. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Customisations and integrations can expand access beyond what the new environment should allow. |
| Recommendation — Revalidate least-privilege access after migration so old role assumptions do not persist in S/4HANA. | ||
Key terms
- Control Continuity: Control continuity is the ability to preserve a security or governance control while the underlying tool, process, or platform changes. In practice, it means the control still works after migration, retirement, or replacement without losing visibility, traceability, or policy enforcement.
- Change Management: Change management is the controlled process used to manage role shifts, service changes, and operational updates. In identity governance, it is the trigger point where access should be added, reduced, or removed based on a new business need. If change handling is weak, privilege creep becomes normal.
- Data Cleanup: Data cleanup is the removal, archiving, or retirement of stale information that no longer needs to remain active. It reduces unnecessary exposure, cuts storage overhead, and helps prevent standing access to data that should no longer be broadly available.
- Migration Workstream: A migration workstream is a defined stream of programme activity such as custom code, data, integrations, or testing. It helps assign ownership and sequencing so control preservation is not left to a single team or a last-minute cutover checklist.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org