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.
Why platform-first migrations lose control of the real estate
IGA migration work breaks down when the project treats the target platform as the deliverable and the application estate as a later integration task. That reverses the dependency order. The platform can be procured, configured, and even demonstrated in isolation, but access governance only becomes real when the applications, entitlements, ownership, and workflows are ready to connect.
Application readiness is the difference between a control plane that exists on paper and one that can actually enforce access decisions. Without a current inventory, stable connectors, mapped roles, and defined remediation paths, the migration team is forced to infer the estate after the fact. That usually means rework, partial cutovers, and a control design that reflects the platform’s defaults rather than the business’s actual access patterns.
In practice, this is where teams discover that some systems cannot support standard provisioning, some require exception handling, and some have stale entitlement data that must be cleaned before the new model can be trusted. The most useful way to think about the problem is to start from the applications that create the access governance workload, not from the product chosen to manage it. A platform-first sequence makes the migration look cleaner than it is, while hiding the operational and governance complexity that determines success.
What application readiness changes in an IGA migration
Application readiness is not just a technical dependency list. It tells you whether each system can express identities, entitlements, ownership, approvers, and lifecycle events in a way the new IGA process can consume. If that information is missing, the migration cannot accurately model joiner, mover, and leaver flows, access reviews, or segregation of duties controls.
The readiness work also exposes which systems will need custom workflow, which ones need data cleanup before onboarding, and which ones will need manual remediation even after the platform is live. That is why readiness is not a nice-to-have pre-project activity. It is the point at which the organisation learns whether the future operating model is feasible at enterprise scale or whether it will become a patchwork of special cases.
This is also where lifecycle discipline matters. A migration that does not account for orphaned accounts, stale entitlements, and disconnected applications will carry those problems into the new platform and present them as configured coverage. The control has not improved if the underlying application data still cannot support accurate certification, revocation, or ownership assignment. For a deeper view of that lifecycle dependency, see IAM and IGA Basics and the Joiner-Mover-Leaver (JML) Guide.
When application readiness is explicit, the project can separate what the platform can do from what each application can actually support. That distinction prevents false progress metrics, because a completed installation is not the same thing as a usable governance control.
Why the sequencing failure creates scope, delivery, and governance debt
Starting with platform selection creates a governance debt that shows up later as scope cuts and manual exceptions. The team may have a vendor, a design, and a roadmap, but it still does not know which applications require remediation to participate. That means late surprises about integration effort, data quality, and process complexity, all of which tend to land after commitments have already been made.
The practical consequence is usually one of three outcomes: the migration narrows to a subset of “easy” applications, the timeline slips while teams retrofit difficult systems, or governance coverage is weakened so the platform can go live on schedule. None of those outcomes is neutral. They all reduce confidence that access decisions are comprehensive, current, and enforceable across the estate.
This is also where role design and access governance get distorted. If the migration begins too early, role models may be designed around the new tool’s shape instead of the business application’s actual entitlements. A better sequence is to validate application readiness first, then choose the platform features that fit the estate. Resources such as the IGA Buyer’s Guide and Role Mining and Role Design Guide are useful once the application realities are known, because they help you evaluate platform capability against actual governance needs rather than assumptions.
At scale, this sequencing error also produces backlog. Each uncovered application becomes a separate exception path, and each exception path adds manual effort, delayed deprovisioning, and weaker review evidence. The project can still claim progress, but the programme has effectively traded one governed model for many unmanaged edge cases.
Risk and Threat Considerations
When IGA migration starts with platform selection, the main risk is that access enforcement becomes partially visible but not fully effective. The organisation may believe governance has improved while the systems that actually hold entitlements, credentials, and review evidence are still outside the control plane. That gap creates both operational exposure and access-control blind spots.
Failure mechanism: The new platform goes live before the estate is mapped, cleaned, and integrated, so critical applications remain on manual workflows, stale data, or one-off exceptions. Over time, that produces weak revocation, missed certifications, and inconsistent ownership for access decisions.
Impact: The organisation ends up with uneven coverage, delayed remediation, and a governance model that can be bypassed or ignored for the hardest systems to manage. In the worst case, the migration institutionalises exceptions that make future access reviews less trustworthy, not more.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | IGA migration readiness depends on accurate account and entitlement governance across applications. |
| AC-6 — Least Privilege | Late-discovered access gaps often leave roles and entitlements broader than intended. | |
| AU-2 — Event Logging | Access governance needs application events and evidence to support reviews and remediation. | |
| Recommendation — Map application accounts and entitlement sources before cutover, then verify lifecycle controls per system. Review application permissions early and remove excess access before migrating governance workflows. Confirm each application can produce reviewable access and change evidence before onboarding it. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Migration sequencing determines whether access control is actually enforceable across applications. |
| A.5.18 — Access rights | Readiness work must validate how access rights are granted, reviewed, and revoked in each system. | |
| Recommendation — Align platform rollout to application-level access control requirements before declaring coverage. Validate application access-right processes and clean up exceptions before switching governance platforms. | ||
Practitioner Guidance
What to prioritise: Build an application readiness inventory before you finalise platform scope. The inventory should distinguish onboardable systems, systems needing data cleanup, systems needing workflow changes, and systems that will require manual bridging for a defined period.
What to verify: Confirm that each high-value application has an owner, an entitlement source of truth, a revocation path, and a workable review process before it is counted as migrated. If any of those elements are missing, treat the application as not ready rather than as “covered.”
Common mistake: Counting platform deployment, connector availability, or pilot success as evidence that the migration is ready for production governance. Those are delivery milestones, not proof that the estate can sustain access control at scale.
Practitioner takeaway: Select the platform after you understand the application estate, because IGA succeeds when the control model fits real systems, not when the tool is installed first and the estate is forced to conform later.
Related resources from NHI Mgmt Group
- Why does application sprawl change IGA platform selection criteria?
- What breaks when organisations start data modernization with the platform instead of the business problem?
- What breaks when session policy is global instead of per application?
- What breaks when an IGA platform cannot reissue entitlements during role changes?