Should IAM teams treat ERP migration and access governance as one programme?

Why ERP migration and access governance belong in the same operating model

ERP migration is not just a technical cutover. It changes the systems of record for users, roles, entitlements, approvals, and removal paths, so access governance has to move with the programme rather than trail behind it. If the migration team and IAM team are separate, you often end up reconciling stale roles, duplicate provisioning logic, and inconsistent controls after go-live.

That is especially true when the target ERP introduces new role models, shared service accounts, integration identities, or changed approval chains. In practice, the migration plan should define how access is re-provisioned, who owns the role redesign, and what evidence proves the new access model is working before the old one is retired.

One useful way to think about the programme boundary is that migration decides where access lives, while governance decides how it is justified, reviewed, and removed. If those two decisions are split, the organisation may complete the technical migration but still inherit the old risk posture in the new platform. That is why migration readiness, role mapping, and entitlement cleanup should be managed as one change stream.

What changes in a hybrid ERP estate

Hybrid ERP environments create overlapping identity paths. Users may authenticate through the old platform, the new platform, or middleware in between, and the same business role can be represented differently in each layer. That makes access reviews harder, because reviewers must understand whether a permission is still needed, duplicated, or simply residual from the transition.

It also changes the deprovisioning problem. During migration, a user may retain access in the source system for reconciliation, in the target system for testing, and through an integration account for batch processing. Unless the programme treats these as one governed scope, removal becomes fragmented and the organisation loses confidence in the actual effective access state.

For this reason, the better control model is to inventory identities, roles, and integration paths together, then retire them on a common timetable tied to cutover milestones. That gives the business a single view of entitlement change, rather than two separate projects with different closure criteria.

Teams often underestimate that role redesign is a governance activity as much as a technical one. ERP roles embody business process decisions, so migration creates a moment to challenge inherited access, remove role inflation, and decide which entitlements are temporary bridge access versus permanent production access.

How to run migration and governance as one programme

The most effective model is a joint programme with shared ownership for target roles, access approvals, recertification, and offboarding. The migration workstream should not declare success until the identity workstream can show that old access paths are either removed or formally time-bound, and that the new platform has a validated access model for production use.

There are a few practical decision points that matter. First, define whether role mapping will be one-to-one, role-to-role, or process-based, because that choice drives how much manual review is needed. Second, decide early which temporary access will be allowed during parallel run, and how it will be tracked to expiry. Third, require exception handling for privileged and shared accounts so they do not become the hidden bridge between systems.

NHIMG’s Segregation of Duties (SoD) Guide is useful here because ERP migration often changes toxic combinations as much as it changes roles. The organisation should test SoD conflicts in the target design, not wait until after cutover when mitigation options are narrower.

NHIMG’s IAM and IGA Basics also aligns closely with this programme model, especially where teams need a common language for provisioning, entitlements, reviews, and access governance across systems. When that vocabulary is shared, migration and governance decisions become easier to sequence and defend.

NHIMG’s Joiner-Mover-Leaver (JML) Guide reinforces the operational point: ERP migration changes joiner, mover, and leaver flows, so deprovisioning and role change logic need to be validated as part of the cutover plan, not after it.

Risk and Threat Considerations

Separate programmes create a predictable failure mode: the migration finishes, but stale entitlements, temporary access, and duplicated roles remain active long enough to become business as usual. That increases the chance of excessive privilege, SoD conflicts, and untracked access paths carrying into the new ERP estate.

Failure mechanism: Access ownership is split between project teams, so no single control owner can confirm which identities, roles, and exceptions should be removed at cutover. The result is residual access that survives because it sits between migration closure and governance review.

Impact: The organisation inherits preventable exposure in a system that is often finance-critical, audit-sensitive, and tightly coupled to downstream business processes. Remediation becomes slower and more disruptive after go-live than it would have been during the migration window.

Practitioner Guidance

What to prioritise: Make the ERP role model, access recertification plan, and deprovisioning schedule part of the same steering forum that approves cutover. If those artefacts live in different plans, the programme will optimise for technical launch instead of effective access closure.

What to verify: Confirm that every temporary entitlement has an owner, an expiry condition, and a removal path, and that privileged or shared accounts are explicitly covered. Also verify that the target ERP has a measurable baseline for effective access before source-system access is reduced.

Practitioner takeaway: Treating ERP migration and access governance as one programme is less about governance neatness than about control continuity, the access model either moves with the system, or it quietly becomes obsolete the moment cutover begins.

Related resources from NHI Mgmt Group

• Should IAM teams treat directory governance and IGA as one programme?
• Should IAM teams treat GenAI as part of access governance?
• What should IAM teams look for in a shared access governance programme?
• Should IAM teams treat policy-based access control as part of identity governance?