They should measure how much configuration must be rebuilt by hand before deciding whether migration is practical. If the main barrier is translation effort rather than policy design, automation can reduce lock-in by converting existing rules and mappings into the new platform instead of starting from zero.
When migration cost is really the blocker, what decision should you make first?
Organisations should separate platform pain from true business need. If the legacy iga system is still enforcing the right access model, the practical question is whether the migration burden comes from rebuilding rules, roles, connectors, and reviews by hand, or from a genuine redesign requirement. That distinction determines whether you should migrate now, automate the move, or defer and stabilise.
A useful way to test this is to look at the amount of configuration that can be translated rather than re-authored. When policy intent is already sound, high manual rebuild effort usually signals lock-in, not strategic value. In those cases, the migration plan should focus on preserving existing governance logic while reducing conversion effort.
How does translation effort change the migration economics?
Translation effort is different from implementation effort. A platform swap becomes expensive when teams must recreate access rules, approval flows, SoD logic, entitlement mappings, and application connectors from scratch, because the cost is multiplied across every governed system. When that happens, migration is no longer a simple technology refresh, it is an operating-model change.
That is why rule conversion, mapping reuse, and connector portability matter. If automation can carry forward the current control intent into the new platform, the organisation is paying for migration work once, instead of paying again for re-encoding the same governance decisions. For IGA, the economics often hinge on whether the incumbent platform stores portable policy data or only platform-specific configuration.
In practical terms, the best candidate for automation is the repeatable layer: entitlements, role relationships, certifications, workflow templates, and common joins and leavers logic. The harder a team has to handcraft those elements, the more the platform is acting like a trap rather than a control.
What approach reduces lock-in without weakening governance?
The safest approach is to modernise the migration path, not to weaken the control objectives. Organisations should preserve approval rules, review cadence, role structure, and deprovisioning intent while using translation tooling or scripts to move the configuration into the target platform. That keeps governance continuity intact while reducing the amount of bespoke rebuild work.
For teams assessing vendors or migration methods, it helps to treat portability as a control requirement. IGA Buyer's Guide is useful here because it frames platform selection around lifecycle, connectors, and governance fit, not just feature lists. The same logic applies when you already own a legacy system and need to decide whether its configuration can be carried forward.
Where identity lifecycle work is already mature, migration should preserve the operating model rather than freeze it in the old UI. IAM and IGA Basics provides the conceptual split between access administration and governance, which is exactly the split you need when deciding what must be rebuilt and what can be translated. If the answer is “the policy is fine, the platform is the problem,” automation is usually the right investment.
Risk and Threat Considerations
Legacy IGA lock-in creates more than project delay. It can prolong stale access logic, deferred connector replacement, and manual workarounds that become invisible over time. The risk is not just higher migration cost, but a longer period in which the organisation depends on brittle configuration and hard-to-change governance paths.
Failure mechanism: Manual rebuild requirements can make migration so expensive that teams postpone it, leaving the legacy platform in place even when it is harder to maintain, less adaptable, and more likely to accumulate unsupported custom logic. That increases the chance of inconsistent reviews, delayed deprovisioning, and configuration drift.
Impact: Over time, the organisation can inherit a larger attack surface, weaker governance agility, and higher operational fragility, especially when access rules, connectors, or workflows must be changed under time pressure.
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 | CM-2 — Baseline Configuration | Legacy IGA migration depends on controlled configuration baselines and portable settings. |
| CM-6 — Configuration Settings | The question centers on preserving governance settings when moving platforms. | |
| IA-5 — Authenticator Management | IGA migrations often include credentials, tokens, and other identity-enabling material. | |
| Recommendation — Document and transfer approved configurations to reduce rebuild effort during platform migration. Define and reuse approved settings so governance logic survives the platform change. Inventory and transition identity-enabling material under controlled lifecycle rules. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Migration cost is driven by how much configuration must be rebuilt or translated. |
| A.5.23 — Information security for use of cloud services | IGA platform transitions commonly involve SaaS control continuity and vendor change risk. | |
| Recommendation — Maintain configuration records so existing policy settings can be migrated instead of recreated. Assess provider change impacts before moving governance functions to a new platform. | ||
Practitioner Guidance
What to verify: Quantify how much of the current IGA estate is policy intent versus platform-specific construction. If the bulk of the effort sits in translation, mapping, and connector adaptation, then automation has a strong business case; if the real work is redesigning broken governance, a simple lift-and-shift will not help.
Decision rule: Treat migration as practical when you can preserve the access model and automate most of the conversion. Treat it as a redesign when the old system’s rules are so bespoke that carrying them forward would recreate the same complexity in a new product.
Practitioner takeaway: The right question is not whether the legacy IGA platform is expensive to replace, but whether the organisation is paying for genuine governance complexity or merely for manual translation that automation can eliminate.
Related resources from NHI Mgmt Group
- How do organisations decide whether to keep a legacy SAST platform or switch to a modern alternative?
- Should organisations store session logs in a way that supports team collaboration or keep them tied to individual devices?
- What happens when organisations keep extending a legacy identity platform instead of planning a transition?
- How should organisations prioritise capabilities when replacing a legacy IGA platform?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org