When should organisations prioritise migration over access cleanup, and when should they not?

When migration should wait for access cleanup

Prioritise access cleanup first when the current environment already shows signs of privilege sprawl, uncertain ownership, or authentication debt. If you move those workloads before the access model is stabilised, you usually preserve the same weak assumptions in a new platform. That creates a cleaner migration project on paper, but the control problem survives intact.

The practical test is whether the move will make access harder to understand, revoke, or validate later. If the answer is yes, the cleanup is part of the migration’s critical path, not a separate follow-up task. This is especially true where inherited entitlements, shared accounts, or old trust paths would be expensive to unwind after cutover.

In other words, migration can be the right vehicle for rationalisation, but only when the target state is already defined. If the team cannot say who owns each access path, why it exists, and what will break if it is removed, then the migration should not be used to postpone that work.

When migration can safely come first

Move first only when access risk is already bounded and the migration itself depends on speed, sequencing, or platform availability more than on detailed entitlement changes. In that case, the goal is not to perfect every permission before day one, but to ensure the moved dependencies are explicitly validated and the residual access risk is understood.

This is the right pattern when the source environment is already well-governed, the migration scope is tightly controlled, and there is a credible plan to revalidate access in the destination. The migration should carry known-good dependencies, not uncertain ones. Where possible, that means onboarding only the accounts, service links, and credentials that have a clear business owner and an expected expiry or review point.

The threshold question is whether the migration would improve access observability or weaken it. If the new platform gives you better logging, clearer separation, and stronger controls, a staged move may be justified. If it mainly copies the old access structure into a fresh wrapper, migration should not be treated as progress on its own.

How to decide the sequence without creating a blind spot

The safest ordering is usually: clean up what you can prove, migrate what is validated, then retire the rest. That does not mean every account must be perfect before any move starts. It does mean no dependency should cross the boundary unless its purpose, owner, and privilege level are known well enough to defend in the target state.

A useful decision rule is simple: if the access path is hard to explain now, it will be harder to control after migration. If the access path is already constrained and documented, migration can proceed in parallel with a tightly scoped cleanup backlog. The risk is not the existence of cleanup work, it is letting the migration hide unresolved access debt.

When a program spans many systems, the sequence also changes at scale. The larger the footprint, the more likely that a rushed move will duplicate stale entitlements, break accountability, or leave dormant access in place long after cutover. That is why migration plans should include an explicit validation gate for ownership, authentication method, and privilege level before each dependency is accepted.

Risk and Threat Considerations

Migration can amplify access risk when it carries forward excessive privilege, weak authentication, or unclear ownership into a new control plane. The danger is not just that access remains messy, but that the new environment may make the old mess look normal, delaying detection and cleanup.

Failure mechanism: Teams move systems before they remove legacy access paths, so dormant accounts, shared credentials, and overly broad permissions survive the cutover and continue to provide unnecessary reach.

Impact: The organisation inherits the same exposure in a new platform, often with lower visibility into who still has access, which increases the chance of misuse, accidental damage, and slower incident response.

Practitioner Guidance

What to prioritise: Start with the access paths that can create the largest blast radius, especially privileged accounts, shared service credentials, and any dependency that has no clear owner. Those are the items most likely to make a migration unsafe if they are simply lifted and shifted.

What to verify: Before moving a dependency, confirm that the identity behind it is still needed, that its authentication method is current, and that the minimum required privilege is known. If you cannot produce that evidence, treat the dependency as a cleanup item, not a migration candidate.

Practitioner takeaway: Migration is only a shortcut when the access model is already trustworthy; otherwise, it becomes a way to preserve old risk faster.

Related resources from NHI Mgmt Group

• When should organisations prioritise cleanup of unused access over adding more approval steps?
• When should organisations prioritise a password manager migration over other access projects?
• When should organisations prioritise provisioning automation over more access cleanup?
• Should organisations prioritise JIT access over broad entitlement cleanup?