TL;DR: IGA migrations often stall because application onboarding becomes the hidden critical path, with each system introducing its own account model, entitlement structure, and remediation workflow, according to Redblock. Starting application readiness before platform selection turns migration sequencing into a governance problem rather than a tooling problem.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Redblock's blog post: IGA migrations slow down when teams treat application onboarding as a late-stage task instead of the first dependency.
Why it matters: For IAM and IGA teams, the article matters because governance only works when downstream applications can actually enforce decisions, and late discovery of connector and data issues turns migration into a control gap.
Context
IGA migration work often looks sequential on paper, but the real dependency is the application estate. Each application carries its own account model, entitlement structure, workflow path, and evidence requirement, so the migration does not really begin until those details are understood.
The governance problem is not simply choosing an IGA platform. It is discovering too late that application readiness, data quality, and enforcement paths determine whether certification, deprovisioning, and audit evidence can be executed reliably across the estate.
Key questions
Q: What breaks when IGA migrations start with platform selection instead of application readiness?
A: The migration loses visibility into the systems that actually enforce access. Teams discover late which applications need custom workflows, data cleanup, or manual remediation, and that forces scope cuts, delays, and weaker governance coverage. The control plane may be live, but the estate it governs is still not ready.
Q: Why does an IGA migration create more risk than a normal application migration?
A: IGA platforms sit inside access reviews, provisioning, lifecycle changes, and compliance reporting, so a migration affects both operations and proof. If historical decisions, entitlement names, or remediation records are lost, teams may still run the platform but fail an audit. The real risk is losing the ability to explain who had access and why.
Q: What do identity teams get wrong about IGA migration sequencing?
A: They often treat application onboarding as a downstream task after the platform decision is made. That sequencing makes the hardest systems appear too late, when architecture, scope, and timelines are already fixed. The result is more manual work, more exceptions, and less reliable control coverage.
Q: When should organisations start application readiness in an IGA programme?
A: Application readiness should start before the platform decision is finalised, or at minimum in parallel with it. That timing exposes connector gaps, data quality problems, and execution constraints early enough to influence architecture and prioritisation instead of forcing late compromises.
Technical breakdown
Why application onboarding becomes the critical path
Application onboarding is not a single integration task. It includes identifying owners, mapping roles and entitlements, normalising account data, and proving that access changes actually take effect inside each application. In IGA programmes, that work often dwarfs platform configuration because every application behaves differently. Mature APIs, CSV-only exports, local admin consoles, and custom workflows all create different remediation paths. The technical issue is that governance decisions only become real when the target system can receive and enforce them. If the application cannot accept the change cleanly, the control exists only in the IGA layer.
Practical implication: Treat onboarding effort as a control design problem, not just an integration task.
Why late discovery breaks migration sequencing
Traditional migration sequencing selects the platform first and discovers application complexity later. That order means teams commit to timelines and architecture before they know which systems are easy to govern, which need custom execution logic, and which will need data remediation. The result is a migration plan that bends around reality instead of shaping it. Late discovery also forces scope cuts and manual workarounds because the hardest applications are uncovered when delivery decisions are already locked in. In identity governance, sequencing matters because the control plane cannot outpace the operational state of the applications it governs.
Practical implication: Discover application constraints before finalising the programme plan.
Application readiness and governance enforcement
An IGA platform can decide access, but it cannot by itself guarantee that the application state changed. That gap is especially visible in disconnected or legacy systems where local permissions, stale accounts, or manual admin steps still control enforcement. Application readiness closes this gap by validating that each identity action reaches the system and leaves an auditable result. The important distinction is between policy intent and execution reality. Without execution readiness, certifications, deprovisioning, and remediation remain partially advisory, even if the governance model looks complete on paper.
Practical implication: Build verification into the migration so policy decisions are confirmed in the application itself.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Application readiness is the real migration control point. The article shows that IGA programmes fail less because the governance model is wrong and more because the application estate is not ready to absorb change. That is a sequencing failure, not a feature gap. When onboarding and remediation are deferred, the migration becomes a forced compromise between coverage and schedule. Practitioners should treat application readiness as the primary determinant of governance effectiveness.
Late application discovery creates governance debt. The longer teams wait to inventory accounts, entitlements, connector limits, and manual enforcement paths, the more exceptions they accumulate. Those exceptions do not disappear after go-live. They become enduring workarounds that weaken certification, provisioning, and auditability. The named concept here is application readiness debt: the growing control debt created when application complexity is discovered after the migration plan is already committed. Practitioners should surface that debt early and budget for it explicitly.
IGA cannot enforce what applications cannot execute. The article makes clear that decision authority and enforcement capability are different layers. The IGA system can own policy, but disconnected applications still determine whether the action happens, whether it is validated, and whether evidence exists. That makes governance an execution problem as much as a policy problem. Practitioners should align identity governance design with application execution reality, especially across legacy, SaaS, and locally administered systems.
Parallelising readiness work changes the migration economics. Running application readiness alongside platform selection reduces late surprises because the hardest systems are being mapped before the programme is fully committed. That does not remove complexity, but it moves complexity earlier, where it can be priced and designed for. For identity leaders, the practical conclusion is that migration velocity depends on how soon application constraints are visible, not on how quickly a platform is chosen.
Control completeness, not platform selection, is the success metric. The article's underlying message is that an IGA migration is only successful when governance decisions reliably propagate into application state. That makes completeness of enforcement, evidence, and exception handling the right measure of progress. Practitioners should judge migration health by how many applications can actually execute and verify access changes, not by how far the platform rollout has advanced.
From our research library:
- 74% of organizations report identity-related breaches, and privileged access is a leading cause of lateral movement.
- Read next: Privileged Access Management Guide
What this signals
Application readiness debt: the longer IGA teams delay inventorying entitlement models and execution paths, the more governance debt they accumulate in manual exceptions and scope compromises. The migration then measures progress by platform milestones while the real control gap sits in the applications that still cannot enforce decisions.
Identity programmes increasingly fail at the handoff between policy and execution, not at the policy design stage. For practitioners, that means migration plans should be judged by how early they surface application-specific enforcement limits, because those limits decide whether access decisions become real or remain advisory.
For practitioners
- Map application readiness before platform commitment Inventory account models, entitlement structures, workflow exceptions, and connector constraints before locking the IGA architecture. This reveals which systems will drive the migration timeline and which can be automated cleanly.
- Split migration into two workstreams Run IGA selection and application readiness in parallel so discovery of hard-to-govern applications happens before timelines are fixed. That reduces the chance of late-stage scope cuts and manual workarounds.
- Validate enforcement inside each application Require proof that access changes, deprovisioning, and remediation actions actually changed the downstream application state. Governance is incomplete if the control plane records a decision but the target system does not reflect it.
- Budget for data cleanup and entitlement mapping Assume stale, duplicate, orphaned, or locally named entitlements will surface during onboarding and assign remediation capacity early. The hidden cost is not just integration effort but the time needed to make identity data usable.
- Prioritise applications with the hardest execution path Start with the systems most likely to expose manual admin steps, weak APIs, or inconsistent access structures so the programme learns its real constraints while options still exist. The hardest apps define the governance model for the rest.
Key takeaways
- IGA migrations stall when application onboarding is left until after platform selection, because the hardest work sits in the estate, not the software.
- The practical risk is partial enforcement, where governance decisions exist in the IGA layer but the downstream application never fully reflects them.
- Teams reduce migration drag when they discover entitlement structures, connector gaps, and remediation paths before commitments are locked in.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | IGA migration hinges on governing application entitlements consistently across the estate. |
| Recommendation — Map migration scope to PR.AA-05 so entitlement governance is validated in each target application. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on lifecycle handling of access paths and their downstream enforcement. |
| Recommendation — Apply IA-5 to ensure credential and authenticator changes are enforced across integrated applications. | ||
| CIS Controls v8 | CIS-5 — Account Management | Application readiness depends on knowing how accounts and entitlements are represented and remediated. |
| Recommendation — Use CIS-5 to inventory account handling differences before committing to the migration sequence. | ||
| MITRE ATT&CK | TA0007;TA0008 — Discovery; Lateral Movement | Late visibility into applications creates discovery gaps and increases paths for uncontrolled access. |
| Recommendation — Map unmanaged application paths to TA0007 and TA0008 to prioritise the systems most likely to bypass governance. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | Migration failures often stem from privileged access being managed inconsistently across applications. |
| Recommendation — Review A.8.2 controls to confirm privileged rights are enforceable in each application before cutover. | ||
Key terms
- Application readiness: Application readiness is the state in which each target system can accept identity governance actions reliably. It includes knowing the account model, entitlement structure, workflow path, and verification method for access changes before migration cutover.
- Governance-to-Enforcement Gap: The governance-to-enforcement gap is the distance between a written control and the point where that control actually affects system behaviour. In AI programmes, it appears when policies exist but agents can still act outside them because no runtime mechanism stops the action.
- Entitlement structure: An entitlement structure is the way an application groups, names, and assigns access rights. In migration work, it determines how easily roles and privileges can be mapped into enterprise governance policies without creating exceptions or manual remediation.
- Execution Layer: The execution layer is the operational point where identity policy becomes system change. It is where approvals, provisioning, revocation, and session controls either complete successfully or fail in ways that create drift. For practitioners, this is where governance is proven, not merely documented.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps identity and security practitioners connect policy design to the operational controls that make access decisions enforceable.
Published by the NHIMG editorial team on August 11, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org