SAP S/4HANA migration exposes IAM and control gaps teams miss

At a glance

What this is: This is a governance-focused overview of SAP S/4HANA migration challenges, with emphasis on controls, data migration, change management, and stakeholder alignment.

Why it matters: It matters because migration programmes often expose weak access governance, stale entitlements, and broken process controls that affect NHI, autonomous, and human identity operations alike.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read SafePaaS's guide to SAP S/4HANA migration challenges and controls

Context

SAP S/4HANA migration is not only a systems project. It is a control transition that can expose identity, access, data, and process weaknesses if teams treat it as a technical cutover rather than an operating-model change. For IAM and governance teams, the central question is whether entitlements, approvals, integrations, and exception handling remain trustworthy while the platform changes beneath them.

The article's core message is that migration success depends on more than code conversion or data transfer. Customisations, third-party connections, and user adoption all create failure points where stale access, poor cleanup, or incomplete testing can undermine business continuity and control integrity. That is a familiar pattern in large change programmes: the technology moves faster than the governance model around it.

Key questions

Q: How should security teams govern SAP migration without losing control over access and approvals?

A: Treat the migration as a governance redesign, not a technical refresh. Re-map roles, indirect access, approvals, and exception handling before cutover, then test the target environment end to end. If control ownership is unclear or shared informally, the migration will preserve legacy risk in the new platform.

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 do organisations get wrong about data migration in SAP projects?

A: 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.

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 turns access governance into a control problem

SAP migration changes the application boundary, the data model, and the integration surface at the same time. That matters because identity controls are often embedded in legacy roles, custom workflows, and indirect access paths that do not translate cleanly to S/4HANA. If entitlement design, approval logic, and exception handling are not revalidated, the migration can preserve old access paths inside a new platform. The result is not just technical debt. It is control debt that survives go-live.

Practical implication: re-map roles, approvals, and delegated access before cutover, not after users find the gaps.

Data migration, cleanup, and the hidden identity risk

Data migration is often described as extraction, transformation, and loading, but governance teams should also see it as a privilege-cleanup exercise. Obsolete records, duplicate masters, and unused objects can retain access relationships that no longer make business sense. When legacy data is moved without cleanup, stale permissions and bad reference data can follow into the target system and distort controls, reporting, and segregation of duties. In practice, data quality and identity quality are inseparable in migration work.

Practical implication: combine data cleanup with access review so obsolete objects do not carry old permissions into S/4HANA.

Change management is the control layer most programmes underestimate

The article correctly treats change management as more than communications. Migration success depends on stakeholder alignment, user readiness, documented milestones, and visible risk handling because controls fail when people do not understand new process boundaries. In SAP environments, that often means the business, ITSM, security, and controls functions must agree on where approval, testing, and escalation now sit. Without that alignment, users invent workarounds and the control model erodes quietly after go-live.

Practical implication: define post-migration control ownership explicitly and test whether users can follow the new process without informal shortcuts.

NHI Mgmt Group analysis

SAP migration exposes control continuity, not just technical compatibility. The article's real lesson is that enterprises often treat migration as a product upgrade when it is actually a control re-platforming exercise. Roles, integrations, approvals, and exception paths must survive the move, or the organisation inherits old access logic in a new environment. Practitioners should read migration programmes as governance transitions, not only implementation projects.

Custom code creates a hidden identity and entitlement carryover problem. When legacy extensions are rewritten or adapted, teams frequently focus on functionality and miss embedded access assumptions inside the code path. That is where indirect authorisation, service dependencies, and approval bypasses can persist. The practitioner takeaway is that code adaptation must be reviewed as part of entitlement design, not treated as a separate technical stream.

Data cleanup is also privilege cleanup. The article's emphasis on removing obsolete records before migration points to a broader governance truth: outdated masters and duplicate objects often preserve obsolete access relationships. This is where identity hygiene, data quality, and segregation of duties intersect. The practical conclusion is that migration teams should retire unnecessary entities before they are given a new life in S/4HANA.

Stakeholder buy-in is the prerequisite for control enforcement. The migration can only hold if senior management, business owners, and controls teams agree that process changes are not optional. SAP programmes fail in predictable ways when governance is framed as overhead rather than operational design. The practitioner conclusion is simple: without executive ownership of the control model, migration risk migrates too.

Control continuity gap: This article shows that the governance assumption of unchanged access paths is false during SAP migration. That assumption was designed for stable systems with predictable dependencies. It fails when customisations, integrations, and business processes are being rebuilt simultaneously, which means practitioners must rethink how access validity is proven during transition.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For migration programmes, that gap is a warning sign: secret handling, access cleanup, and control validation need to move together, as outlined in NHI Lifecycle Management Guide.

What this signals

Control continuity gap: SAP migration programmes often expose the same issue seen in identity projects more broadly: the organisation assumes old approvals, access paths, and exception handling will remain valid after a platform change. They usually do not. Teams should plan for a re-baselined control model, not a straight lift-and-shift of governance.

With 27 days to remediate a leaked secret in our research, slow cleanup becomes more than an operational nuisance during migration. If stale data, stale access, and stale secrets are all carried forward together, the new SAP environment can inherit the same weaknesses with a cleaner interface.

The programme signal is clear: migration owners should pair technical cutover planning with identity lifecycle discipline and post-go-live review ownership. Where change management is weak, users fill the gap with informal access paths, and that is where the control model starts to erode.

For practitioners

• Revalidate roles before cutover Map legacy SAP roles, indirect access, and workflow approvals to the target S/4HANA design, then test whether each entitlement still matches business need after migration.
• Treat data cleanup as access cleanup Remove obsolete materials, one-time customers, duplicate masters, and other stale objects before migration so outdated records do not carry forward unwanted permissions or reporting noise.
• Test integrations with control checkpoints Validate ITSM links, third-party application paths, and business process handoffs end to end so approval, logging, and segregation controls still function in the new environment.
• Assign control ownership for the post-go-live state Document who owns each approval, review, and exception process after migration so business users do not revert to informal workarounds when the first issue appears.

Key takeaways

• SAP migration becomes a governance problem when roles, approvals, and integrations are not revalidated against the target design.
• Data cleanup, custom code adaptation, and change management are the three places where stale access and broken controls most often survive cutover.
• The control model has to be owned explicitly after go-live, or users will recreate the legacy process outside the intended SAP S/4HANA path.

Key terms

• SAP migration control continuity: The extent to which existing governance, approvals, and access rules remain valid when SAP moves to a new platform. In practice, it is the test of whether a migration preserves decision rights and control evidence, or quietly replaces them with legacy workarounds and informal exceptions.
• Custom code carryover risk: The chance that rewritten or adapted extensions preserve old access assumptions, indirect authorisation paths, or business logic that no longer fits the target system. In SAP migration, code is not just functionality. It often contains embedded governance choices that need to be reviewed before go-live.
• Data cleanup in migration: The process of removing obsolete, duplicate, or inaccurate records before moving information into a new system. For identity and governance teams, it also means preventing stale objects from carrying forward old permissions, weak references, or misleading control data into the target environment.
• Post-go-live control ownership: Clear accountability for approvals, exceptions, reviews, and escalation after a migration has completed. Without named ownership, teams tend to drift back to informal processes, which undermines the new control model and makes compliance evidence harder to sustain.

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 responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by SafePaaS: SAP migration challenges and best practices for a secure transition to S/4HANA. Read the original.