What breaks when identity migration simply copies the old access model?

What Breaks When You Copy the Old Access Model?

Identity migration is not just a directory move or SSO swap. If you lift and shift the old access model, you carry forward the same authentication gaps, role sprawl, and unclear ownership that made the previous platform hard to govern. The new stack may be cleaner technically, but the access decisions underneath it stay just as weak.

That is why migration failures often show up as control failures, not outage events. The environment appears modernised, yet the organisation still depends on the same entitlements, the same exception paths, and the same assumptions about who should have access and for how long.

Copying the old model also blocks the one opportunity migration should create: a chance to re-scope privilege, retire stale access, and simplify policy. If that work happens after cutover, teams usually inherit the blast radius first and discover the governance debt later.

Why a Lift-and-Shift Migration Preserves the Wrong Security Properties

The core problem is that access design is part of the system’s security architecture, not a superficial configuration layer. When the legacy model is cloned, you usually preserve broad roles that were built around historical convenience, not current business need. That means standing privilege, overly large groups, and inconsistent exceptions survive the move.

This is also where authentication and authorization get conflated. A new login flow can improve the front door, but if the downstream entitlements are copied unchanged, users still reach the same sensitive functions as before. In practice, migration can improve the experience while leaving the actual trust boundaries untouched. For a structured view of how those boundaries should be rethought, see IAM and IGA Basics.

When the access model is copied into a new platform, governance fragmentation also tends to deepen. Teams may rebuild the directory, federation, or policy engine, but they keep the same approval habits, the same exception handling, and the same stale entitlements. That is how policy drift survives migration and becomes harder to see. A broader operating model view is covered in Identity Security Programme Guide.

What Should Change Before Cutover, Not After

The right migration question is not, “How do we preserve current access?” It is, “Which access patterns are still justified, and which ones should be retired or redesigned?” That usually means tightening role scope, separating admin from user functions, and deciding where policy should be centralized versus delegated.

Access retirement needs particular attention. Orphaned accounts, unused groups, service credentials with no owner, and old emergency paths often survive because no one wants to break production during migration. But deferring retirement only makes the new environment inherit the same hidden exposure. Lifecycle-oriented cleanup is central to NHI Lifecycle Management Guide, and the same principle applies to human and shared access.

Migration teams should also re-baseline authorization model decisions instead of mapping every legacy role one for one. If the old platform used nested groups, manual exceptions, or ad hoc local admin rights, translating those patterns directly into the target platform keeps the same privilege distribution in a different wrapper. The better move is to revalidate who needs access, at what scope, and under what expiry or review rule.

Risk and Threat Considerations

Copying the old access model turns migration into a control replication exercise, which means the organisation imports the same attack paths, excessive privilege, and weak accountability into the new environment. If attackers already understood the old entitlement structure, they often gain a familiar path into the new one.

Failure mechanism: Legacy permissions, stale exceptions, and overbroad roles are moved intact, so privilege remains easier to abuse than to detect or remove.

Impact: The new platform inherits the same blast radius, lateral movement potential, and governance blind spots, even if the infrastructure, UI, or authentication layer has been replaced.

Practitioner Guidance

What to prioritise: Inventory the access paths that create the largest blast radius first, especially privileged, shared, and rarely used entitlements. Those are the controls most likely to survive migration by inertia and the hardest to clean up later.

Decision rule: If a permission exists only because the legacy system needed it, treat that as a redesign candidate, not a migration requirement. If a role cannot be explained in current business terms, it should not be carried forward unchanged.

What to verify: Before cutover, verify that every retained role has an owner, a purpose, a review cadence, and a retirement condition. If any of those are missing, the migration has preserved a governance gap, not just an entitlement.

Practitioner takeaway: A successful identity migration reduces accumulated access debt instead of rehosting it, and the safest cutover is the one that changes privilege shape before users depend on the new stack.

Related resources from NHI Mgmt Group

• What breaks when inherited systems keep their old access model after an acquisition?
• What breaks when migration leaves old admin access in place?
• What breaks when an access recommendation model is trained without enough identity and entitlement context?
• How should security teams run access reviews for non-human identities?