In many enterprises, Microsoft Identity Manager 2016 (MIM) is the central system for identity processing and the delivery of identity management services. As the name suggests, the current version of Microsoft Identity Manager dates back to 2016. The core is based on the Microsoft Metadirectory Services (MMS) from the early 2000s.
Microsoft has extended support for Microsoft Identity Manager by three years, through 2029. That changes the deadline, but not the direction.
For many organizations, the headline looked almost comforting: Microsoft Identity Manager did not fall out of support on January 13, 2026 after all. Microsoft extended the extended support date to January 9, 2029, and the lifecycle page now reflects that explicitly. Service Pack 2, first released in November 2019, is listed as supported until that same 2029 date.
But there is also a hard lifecycle dependency that the extended Microsoft Identity Manager support date does not resolve. The Microsoft Identity Manager Portal is not a standalone component. It requires an on-premises SharePoint Server installation to function. In most real-world deployments, that means SharePoint Server 2016 or 2019, both of which reach end of support on July 14, 2026.
Service Pack 3 provides support for SharePoint Subscription Edition and is now available again after being silently pulled by Microsoft following its initial release in late March 2026, with no public explanation.
Some will read the extended support as relief and permission to wait or rely on Service Pack 3 to gain support for SharePoint Subscription Edition. That would be a mistake and you should review your identity management strategy to define a clear way forward.
Extended Support Does Not Change Microsoft's Strategic Direction
Microsoft keeps Microsoft Identity Manager serviceable until 2029, but that does not suddenly turn Microsoft Identity Manager back into a product with long-term innovation momentum.
Microsoft has been unusually clear about where identity innovation is going. The investment focus is Microsoft Entra ID, and on the governance side specifically Microsoft Entra ID Governance with lifecycle workflows, entitlement management, access reviews, privileged access controls and broader cloud-era identity governance capabilities.
That being said, organizations may want to reassess the role of Microsoft Identity Manager and evaluate whether it should remain part of their mid- to long-term identity management strategy.
The next relevant question is, what this means for your own environment. The reality is, that in many enterprises, Microsoft Identity Manager has long been the operational core of identity processing, supporting joiner-mover-leaver workflows, account and directory synchronization, metadirectory designs and connectors to systems nobody is eager to touch anymore.
Because Microsoft Identity Manager continues to run and appears manageable, it is rarely questioned. That is an illusion. The longer organizations wait to plan and execute a strategy for their Microsoft Identity Manager environment, the more complex a transition is likely to become. The real risk is not only operational or related to Microsoft support, but structural.
There are three structural challenges to consider:
- First, the people who originally designed the environment are often no longer available, while the configuration has evolved over years. In some cases this configuration is documented, in others not.
- Second, Microsoft Identity Manager migration expertise is already limited, and availability will become increasingly constrained as 2027 and 2028 approach.
- Third, identity modernization never happens in isolation. It collides with Entra ID rollouts, HR transformation, application renewal, mergers and acquisitions, carve-outs, and every other program that also claims to be business-critical.
For organizations where internal knowledge of the existing Microsoft Identity Manager configuration has already been lost, a structured reverse engineering approach is required to reconstruct documentation, uncover embedded logic, and identify operational risks. This creates the foundation for any further planning and decision-making.
Next you need a clear strategy and defined path forward. Otherwise support deadlines tend to escalate into board-level issues, with the risk that Microsoft Identity Manager continues to operate beyond 2029 without support.
Four Paths to Exit Microsoft Identity Manager
Let’s take a look at the possible paths forward. All of them aim to move away from Microsoft Identity Manager, but they follow very different approaches.
Path 1 - Microsoft-native migration to Entra ID Governance
This is the obvious option for enterprises that are already deep in the Microsoft ecosystem and whose Microsoft Identity Manager footprint is more standard than heavily customized. Microsoft Entra ID Governance covers core lifecycle and access governance scenarios and supports inbound HR provisioning, lifecycle workflows, entitlement management, access reviews, and connectors to many cloud and on-premises applications.
The problem is that many Microsoft Identity Manager deployments are not standard. They are full of custom synchronization logic, edge-case workflows, and legacy application dependencies that do not politely translate into cloud-native constructs. It also assumes that existing Microsoft Identity Manager logic can be translated into Entra-native constructs, which is often not the case for heavily customized environments.
Path 2 - Hybrid approach with Microsoft Entra ID and complementary IGA capabilities
This path positions Microsoft Entra ID as the primary identity platform, particularly for cloud identities, while introducing an additional IGA solution to complement its capabilities. Entra ID handles the core identity layer, while classic Identity Governance Administration (IGA) platforms address gaps in governance, non-Microsoft target systems, and more complex provisioning scenarios.
Rather than a full replacement, Microsoft Identity Manager functionality is gradually redistributed across Entra ID and the IGA solution. The result is a deliberately split architecture, where identity and governance responsibilities are shared across platforms. This approach is more effort-intensive from an integration perspective, but it is often the most pragmatic and realistic option for mid-sized and large enterprises with heterogeneous environments.
Path 3 - Full replacement with a central IGA platform
This path treats the Microsoft Identity Manager transition as an opportunity for a structural reset. A classic IGA platform becomes the central control plane for identity governance, provisioning and compliance. Microsoft Entra ID is integrated as one of several connected systems, rather than acting as the primary control layer.
In this scenario Microsoft Identity Manager is fully decommissioned and its logic is not simply migrated but re-engineered into governance-driven processes, including role models, access certification, separation of duties, and compliance reporting. This approach is particularly relevant for highly regulated organizations with complex environments or multi-cloud strategies.
This approach is more expensive, more political, and more disruptive. At the same time, it is often the first point in time at which identity governance is treated as a business control, not just a provisioning mechanism. The potential benefits are significant, but so are the required investment and effort.
Path 4 - Controlled Delay
The fourth path is the one many organizations will choose first. It focuses on stabilizing the existing Microsoft Identity Manager environment while deliberately buying time. This includes reducing visible technical debt, documenting long-standing configurations and workflows, and gradually moving less critical processes to alternative solutions where feasible.
The objective is to keep the platform operational and controlled, while preparing a structured and realistic exit. When managed properly, this approach creates breathing space and reduces immediate risk.
At the same time this approach requires discipline. Without clear ownership and a defined target state, “controlled delay” quickly turns into unmanaged stagnation. Still, it is a defensible and responsible short-term strategy, particularly when resources are constrained.
Each Organization Must Choose Its Own Path Beyond Microsoft Identity Manager
How do you decide which path to take? Choosing the right path requires a clear understanding of your current state, your target state, and how to get there.
For such scenarios, we have found the following five phases to be effective in defining an identity management strategy and selecting the most appropriate path to exit Microsoft Identity Manager.
Phase 1 - Discovery and Risk Assessment
Start with a complete inventory of the Microsoft Identity Manager environment. This includes management agents, synchronization rules, rule extensions, workflows, and all dependent applications. The goal is to identify technical debt, undocumented logic, and operational risks, including reliance on individuals who may no longer be available. The outcome is not documentation for its own sake, but a prioritized risk view that defines where action is required first.
Phase 2 - Strategic Path Definition
Based on that assessment, define and evaluate realistic options. The paths above provide a starting point, but this should also include comparing Microsoft Entra ID Governance with third-party platforms, assessing licensing models, and deciding where connectors should be built or sourced. A structured view on cost over time is essential. Independence is the key. Decisions of this scope should not be driven by vendor positioning or existing licensing footprints, but by architectural fit and long-term viability.
Phase 3 - Target Architecture and Transition Design
Design the target architecture for identity, provisioning, and governance. Define how the transition will be executed, including phases, fallback scenarios, and potential parallel operation. The critical part is the transfer of business logic embedded in Microsoft Identity Manager rule extensions. This is often poorly documented and regularly underestimated which frequently leads to a failed migration.
Phase 4 - Implementation Oversight and Quality Assurance
Ensure that implementation is controlled and validated against business requirements, not just technical configuration. This is particularly relevant when external integrators are involved. Independent oversight, combined with structured testing against real processes, helps avoid the common gap between what was configured and what the business actually needs.
Phase 5 - Target Operating Model and Capability Building
Define how the target environment will be operated. This includes roles, responsibilities, escalation paths, and administrative processes aligned with the new platform. Internal teams need to be prepared to run and evolve the solution. In parallel, establish an identity governance framework that remains in place beyond the migration itself and supports ongoing control and compliance.
The Timeline Has Changed but the Urgency Has Not
Microsoft has extended support for Microsoft Identity Manager from January 13, 2026 to January 9, 2029. Service Pack 3 is intended to provide support for SharePoint Subscription Edition and is available again after being silently pulled by Microsoft following its initial release in late March 2026.
This does not indicate a renewed strategic role for Microsoft Identity Manager. It reflects a transition period, giving customers additional time to move away from Microsoft Identity Manager. Microsoft’s investments remain focused on Entra ID as the primary identity platform and not on Microsoft Identity Manager.
This is valuable time, if used well to define your identity management strategy and a clear path forward to exit Microsoft Identity Manager. The sooner you act, the more control you retain over the migration.
