Join our Newsletter — 33% off our NHI Course

How should organisations prioritise capabilities when replacing a legacy IGA platform?

Start by ranking the capabilities that will matter after migration, not just the functions the legacy system already has. Modern IGA should preserve core governance, then add adaptability, broad connectivity, and automation that fit future requirements. The right priority is the one that reduces custom code, supports changing workflows, and keeps identity controls usable as the enterprise grows.

What to prioritise when replacing a legacy IGA platform

legacy iga replacements work best when capability priority follows the future operating model, not the old product menu. The first question is which governance decisions must still be reliable after migration, then which functions will reduce manual effort, improve integration coverage, and keep identity controls maintainable as workflows change. That usually means preserving core governance first, then adding flexibility and automation.

A good prioritisation lens is to separate “must govern” from “nice to automate.” Access requests, certifications, roles, and segregation-of-duties controls are foundational, but the replacement should also reduce dependence on custom code and brittle point integrations. If a capability only recreates the legacy interface without improving fit for future systems, it is usually lower priority than connective breadth or policy adaptability.

Modernisation also changes the value of a feature. In older deployments, a function may have been valuable simply because it existed inside the suite; in a replacement programme, the more important question is whether it still supports IGA platform evaluation across lifecycle, connectors, reviews and governance outcomes. Capability ranking should reflect the destination architecture, including the systems that are hard to integrate and the workflows that will need to survive organisational change.

How to rank capabilities without recreating the legacy stack

Start with the capabilities that preserve governance quality under change: lifecycle provisioning and deprovisioning, access reviews, role and entitlement management, and segregation-of-duties enforcement. Then rank the capabilities that make those controls easier to sustain, such as workflow adaptability, connector coverage, policy flexibility, and reporting that supports audit and remediation. This order avoids the common mistake of buying a new interface around old operational bottlenecks.

Customisation deserves special scrutiny. Heavy custom code can make a replacement look more complete in the short term, but it usually raises upgrade risk, slows change, and locks the programme into the same technical debt the migration was supposed to remove. Prioritise capabilities that configure cleanly, integrate broadly, and let the business adjust approval paths, review logic, and role structures without re-engineering the platform every time the organisation changes.

For many programmes, the most useful benchmark is whether the target platform can support identity and access governance basics while staying usable across people, systems and machines. The best capabilities are the ones that keep policy decisions visible and repeatable, not the ones that simply mirror legacy screens. That is especially true when the enterprise expects more applications, more automation, and more governance exceptions over time.

One practical way to rank features is to ask three questions for each one: does it reduce manual governance effort, does it expand the set of systems you can govern, and does it lower the amount of bespoke code you must own? If a capability answers “yes” to all three, it usually outranks a feature that only improves reporting cosmetics or reproduces an old process more elegantly.

Which capabilities matter most as the enterprise grows

As scale increases, the priority shifts from single-use convenience to survivable control. Workflow adaptability, connector breadth, inventory visibility, and closed-loop automation matter because they prevent governance from collapsing under volume and exception handling. A platform that cannot handle growth in applications, identities, or review campaigns will eventually force teams back into spreadsheets and manual workarounds.

That is why the replacement should also support lifecycle depth, not just access administration. Joiner-mover-leaver automation becomes more valuable when the organisation has many downstream systems, frequent role changes, and offboarding obligations that must be executed quickly and consistently. Likewise, review processes become more important when managers and app owners need enough context to make decisions without drowning in noise.

Broad connectivity deserves priority when the estate includes disconnected applications, shared services, and exceptions that cannot be handled by one workflow pattern. In that setting, a strong connector strategy is not just an integration convenience, it is the difference between governable scope and blind spots. The same is true for role design: if the platform cannot support manageable roles, it will amplify role explosion instead of containing it.

Growth also exposes whether the platform can support governance beyond traditional user accounts. The replacement should be able to extend controls into access reviews and certification, role governance, and separation-of-duties workflows without forcing separate tools for each control type. When those capabilities are integrated, governance stays coherent; when they are fragmented, review fatigue and inconsistent enforcement usually follow.

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 and CIS Controls v8 set 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 replacement prioritises lifecycle governance and access administration.
AC-6 — Least Privilege Capability ranking should favour controls that sustain least-privilege outcomes at scale.
AU-6 — Audit Review, Analysis, and Reporting Access reviews, certification and evidence reporting are core IGA replacement capabilities.
Recommendation — Preserve automated account lifecycle controls and approvals across the new platform. Prioritise functions that enforce least privilege and reduce standing access. Select reporting and review capabilities that support auditability and remediation.
CIS Controls v8 CIS-5 — Account Management IGA migrations depend on account lifecycle and governance capabilities.
CIS-6 — Access Control Management Priority should reflect how well the new platform maintains access control outcomes.
Recommendation — Use account-management controls to validate provisioning, deprovisioning and review workflows. Prioritise access-control functions that stay maintainable as the estate grows.
ISO/IEC 27001:2022 A.5.18 — Access rights IGA replacement directly affects how access rights are granted, reviewed and revoked.
A.8.2 — Privileged access rights Capability prioritisation should cover governance of elevated access and exceptions.
A.8.3 — Information access restriction The new platform should sustain restrictions as workflows and integrations change.
Recommendation — Ensure the new platform can administer and evidence access-rights decisions cleanly. Prioritise privileged-access governance where administrative risk is highest. Configure access restrictions so they remain enforceable after migration.

Practitioner Guidance

What to prioritise: Build the capability ranking around future governance load, not current product familiarity. The first tier should be the controls that must remain dependable after migration, then the features that reduce customisation, widen integration coverage, and make governance easier to operate at scale.

What to verify: Check whether each candidate platform can execute the real lifecycle, review, and role scenarios from your target state without bespoke code. If a feature only works in the demo but not across complex applications, edge-case approvals, or recurring recertification cycles, treat it as lower priority.

Common mistake: Treating parity with the legacy platform as the success metric. A replacement should improve maintainability and adaptability, otherwise the enterprise simply migrates old constraints into a new interface.

Practitioner takeaway: The best IGA replacement is the one that preserves governance fidelity while reducing dependency on custom logic, because that is what keeps identity controls usable as the environment expands.