When Is It Time to Replace an Old IGA or IDM System?

A system can still work technically while no longer meeting current or future needs. The types of identities being managed are changing, expectations around access governance are increasing, and the way people interact with business systems is evolving. The need to renew an IGA or IDM platform should therefore be assessed against these changing requirements, rather than simply against the age of the product.

Identity environments and ways of working have changed

Many older IDM solutions were built around a relatively straightforward model. An employee record was created in the HR system, user accounts and the required access rights were provisioned to target systems, and those accounts were disabled when the employment relationship ended.

This remains important, but today’s environments are considerably more complex. Organisations manage employees, consultants, partners, contractors and other external users. One person may have several simultaneous roles or contracts, and not every identity originates from an HR system. Access is required across cloud and on-premises systems, permissions may need to be time-limited, and their continued need should be reviewed regularly.

AI assistants and agents are also becoming part of everyday workflows. An agent may retrieve information, prepare tasks or perform actions on a user’s behalf. At the same time, organisations are beginning to manage more non-human identities, which also require clear ownership, a defined purpose, controlled access and a managed lifecycle.

AI can also change how identity governance itself is operated. Finding access information, preparing changes, identifying exceptions and carrying out administrative tasks do not necessarily need to rely entirely on traditional forms and administration consoles. A new IGA platform should therefore be evaluated not only on what it supports today, but also on how easily it can accommodate new ways of working.

Do not migrate the old environment as it is

An IGA or IDM renewal should not begin with selecting a new product. The first step should be to understand what the current environment actually does and which parts of it are still needed. Long-running identity environments tend to accumulate integrations, rules, exceptions and customisations. Some remain business-critical, while others continue to exist simply because nobody has removed them. Moving everything directly into a new platform risks carrying years of technical and process debt into the new environment.

A renewal is therefore a good opportunity to review what is genuinely required, what can be simplified and what can be retired. The underlying identity model should also be reconsidered. One person does not always mean one employment relationship or one role, external users may have a very different lifecycle from employees, and the same environment may increasingly need to support applications, machine identities and AI agents.

Modern IGA is more than provisioning

In many older IDM environments, provisioning is the part that already works well. Modern IGA, however, is expected to provide broader governance of access.

An organisation should be able to understand what access a person or other identity has, why it was granted, who is responsible for it and whether it is still required. This includes access requests and approvals, time-limited access, periodic reviews, clear ownership and sufficient history for audit purposes. The same principles should apply to non-human identities when they have access to business systems and information.

Adaptability is equally important. New applications, user groups, organisational structures and working practices are introduced continuously. If every change requires a separate development project or highly specialised expertise, the platform’s lifecycle cost can become significantly higher than its initial price.

The question is therefore not only what a platform can do today, but also how easily it can be changed in the future.

Procurement requirements should describe the need, not the old system

The same thinking should be reflected in IGA procurements and RFPs. If requirements are built directly from the features, integrations and operating model of the existing system, the procurement process may effectively ask vendors to recreate the old environment using different technology. This can exclude alternative and potentially simpler ways of solving the same business problem. It can also place too little emphasis on deployment effort, custom development and how easily the platform can be extended or changed over time.

Requirements should clearly describe what the organisation needs to manage while leaving room for different implementation approaches. Relevant areas include the lifecycle of different identity types, access approvals and reviews, integrations, audit requirements and the ability to adapt to organisational change.

Future needs should also be considered without turning them into overly detailed technical requirements. An organisation does not need to have AI agents widely deployed today in order to ask how a platform could govern their access and lifecycle in the future. It is equally reasonable to assess whether the architecture allows new ways of operating and automating identity governance.

A good procurement process should clearly define the problems the organisation needs to solve, rather than prescribing in excessive detail what the technical solution must look like.

Renewal can be done in phases

Replacing a large IDM environment does not necessarily require a big-bang migration. The old and new platforms can operate in parallel while integrations, user groups and processes are moved in stages. This reduces risk and creates an opportunity to improve processes rather than simply copy the existing environment.

The biggest mistake in an IGA renewal may not be choosing the wrong product. It may be defining the new solution entirely on the terms of the old environment.

Before selecting technology, it is worth deciding what should be retained, what can be removed, and what kinds of identities, access models and ways of working the organisation will need to support over the coming years.