Microsoft Identity Manager Is Being Retired – Three Years to Act
- Joonas Jokinen
- 6 days ago
- 4 min read
Is there already an urgent need to act, and what should organizations do at this stage?
Microsoft Identity Manager (MIM) will reach the end of its lifecycle in three years. There is no need for immediate panic. Instead, now is an excellent time to begin a controlled decommissioning of Microsoft Identity Manager and to plan and implement a new identity management solution.
Although few years remain until end of lifecycle, replacing a critical system such as identity management is rarely a quick or simple project. In practice, time pressure often increases during the final 12 months, when available options narrow and risks grow.
Establish a Solid Foundation and Identify Requirements
Depending on the size of the organization, number of users, and complexity of processes, collecting background information and preparing for the transition can take more time than expected. In many environments, the existing identity management solution has evolved over the years into a web-like structure containing numerous rules, functionalities, and integrations.Often, not everything is sufficiently documented, and no single individual has a complete overview. For this reason, the first and most important step is a thorough review of the current state.
Understand the Current Environment
Once the current solution is sufficiently understood, future planning can be carried out realistically and purposefully. At the same time, it becomes possible to identify both technical and business needs that could not previously be addressed.Carefully review current processes and technical implementations. Then consider where and how processes can be improved in collaboration with stakeholders, and what requirements this places on future technology. Security must be taken into account, but it should also enable smooth day-to-day operations.
At a minimum, the following aspects of the Microsoft Identity Manager solution should be clarified:
Which management agents are in use, what they are used for, and how they are configured
Which systems act as source and target systems
Whether the MIM portal is in use and what functionalities or customizations it includes
Where and how the different stages of the identity lifecycle actually take place, for example:
Does MIM only provision accounts?
Does a master data system generate user ID values?
Are mailboxes created via PowerShell?
Which business-critical processes MIM supports and which of them rely on manual exceptions
What has and has not been documented, and who holds critical tacit knowledge of the solution
When mapping the current state, it is also important to consider the value of historical data. Access history, audit logs, and previously granted exceptions may be essential for both business continuity and compliance in the future solution.
Explore Alternatives – Do Not Replace the Old Solution One-to-One
Once the foundation is in place and requirements are identified, it is time to explore alternative solutions. At this stage, it is important to avoid falling into the trap of directly replacing the old solution on a 1:1 basis.
Instead, focus primarily on what the new solution enables, not just how it works technically. Also consider how and by whom the solution will be used and maintained going forward. Will maintenance be handled internally, outsourced, or through a hybrid model?
Remember that maintenance involves more than keeping the system running. It also includes configuration, change management, and continuous development. Regulatory and compliance requirements must also be considered, as well as whether the solution is cloud-based or on-premises. For example, data residency may play a significant role in the selection process.It is also important to consider how the change will affect different user groups, such as end users, managers, and approvers. Changes to identity management often have a broad impact on daily workflows, approval processes, and self-service capabilities.
What Should Be Required from the Future Solution?
When evaluating a future IGA solution, at least the following aspects should be considered:
Support for different user groups (e.g. internal employees, partners, students, machine accounts, service and integration accounts, and privileged users)
Support for different contract models (multiple concurrent employment or study relationships)
Need for segregation of duties (SoD)
Support for required source and target systems and integrations (e.g. HR systems, Entra ID)
Approval worklfows
Automated access reviews and attestations
Reporting and auditing capabilities
Availability as a SaaS service or an on-premises solution as required
Overall extensibility of the UI and the solution
User experience and self-service capabilities
Vendor dependency and future development direction of the solution
Total cost of ownership for implementation and ongoing maintenance
A successful transition is often built in phases: first understanding the current state, then defining requirements and comparing solutions, and only after that implementing the new solution while running a controlled parallel decommissioning of the old one.
Next Step: Planning the Implementation
Once the foundation is in place and the solution is selected, implementation can be planned in a controlled and phased manner. A well-prepared transition reduces risks and ensures that the new solution supports business operations from day one.
Even if the actual implementation still feels distant, early preparation facilitates decision-making and reduces risks in later phases.
If the process raises questions or compares alternatives feels challenging, discussing the situation with an expert can help clarify the overall picture.
Read more how we can help or be in touch!
Source: