Microsoft Identity Manager 2016 did not reach the end of extended support in January 2026. Microsoft changed the lifecycle date to 9 January 2029. That gives organisations running MIM more supported time, but it does not turn MIM into a modern strategic identity governance platform, remove its ageing dependencies, or provide an in-place successor release.

The useful interpretation is precise: the extension creates a planning window. It is time to stabilise the current service, remove unsupported components, document the identity processes that MIM actually performs, and move each responsibility to a deliberate target. Treating 2029 as permission to defer the decision only compresses discovery, procurement, migration, coexistence and decommissioning into a smaller and riskier period.

This guide explains the current support position, the additional condition relevant to Microsoft Entra ID P1 and P2 customers, the technical work still required inside MIM, and a practical route from an inherited MIM estate to a governed future architecture.

Decision brief: keep MIM supported and stable while you build an evidence-based replacement or reduction plan. Do not promise a “MIM upgrade” unless you can name the target services, the controls they will own, and the method used to prove that access changed correctly.

What changed, exactly?

Microsoft’s lifecycle page for Microsoft Identity Manager 2016 now shows a fixed lifecycle with mainstream support already ended on 12 January 2021 and extended support ending on 9 January 2029. Microsoft separately states in the MIM product documentation that the previous end date of 13 January 2026 was extended to 9 January 2029.

There is a second point that often gets simplified too far. Microsoft publishes a support update for customers with Microsoft Entra ID P1 or P2. For those customers, standard support through the Azure portal is available for specified MIM 2016 components when the deployment is on MIM 2016 Service Pack 3 or a later hotfix or update. The listed scope includes the Synchronization Service, Password Change Notification Service, connectors, the MIM Service and Portal, add-ins and extensions, and related support scripts and language packs.

This does not mean that every MIM installation without P1 or P2 immediately becomes unsupported. Microsoft’s page also describes other routes under the fixed lifecycle and professional support. Licensing, deployment version, component scope and support route must therefore be checked for the organisation’s actual contract and build. A defensible programme record should contain the Microsoft lifecycle evidence, the tenant’s licence position, the deployed MIM build, and confirmation of the route through which incidents will be raised.

QuestionEvidence-based answerRequired owner action
Is MIM 2016 supported after January 2026?The published extended-support end date is 9 January 2029.Record the date in the technology-risk register and programme plan.
Does Entra ID P1 or P2 matter?Yes. Microsoft documents a standard Azure-portal support route for specified MIM 2016 SP3-or-later components for P1/P2 customers.Verify licences, build level and covered components; retain the evidence.
Is SP3 optional for a long-lived deployment?It is the current baseline named by Microsoft for the P1/P2 support route, and current updates are published on the SP3 line.Plan and test the move to a current supported build if the estate is older.
Does 2029 provide a successor version?No successor release or in-place modernisation path is identified by the lifecycle extension.Fund target architecture, migration and decommissioning as separate work.
Can the organisation wait until 2028?Technically it may continue operating, but the remaining time must also cover discovery, remediation, migration and evidence.Set internal decision and wave deadlines well before the support date.

Plan the target architecture during the support window

MIM can still perform valuable work. The Synchronization Service can join identity data from heterogeneous human-resources systems, directories, databases and applications. It can calculate attributes and provision changes. The MIM Service and Portal can support request and workflow patterns. Password Change Notification Service and supported connectors may remain embedded in operational processes that the business depends on every day.

Support for those functions is not the same as a strategic product roadmap. The architecture remains rooted in on-premises services, SQL Server, SharePoint-based portal components and custom integration logic. Microsoft is adding fixes and platform support on the SP3 line, but the lifecycle extension does not erase years of local rules, scripts, operational knowledge and dependencies. It also does not automatically translate a MIM workflow into Microsoft Entra ID Governance.

Think in terms of two clocks:

  1. The support clock ends on 9 January 2029 under the currently published lifecycle.
  2. The transformation clock ends earlier, because the organisation needs a stable period after migration for reconciliation, audit acceptance and controlled decommissioning.

If a complex programme needs twelve months for discovery and design, another twelve to eighteen months for delivery waves, and several months for stabilisation, the practical decision deadline is much closer than 2029 suggests. The exact duration depends on the number of identity populations, connected systems, custom extensions, approval paths and regulatory controls. Measure those facts rather than choosing a schedule by analogy with another company.

Stabilise the MIM service before redesigning it

A migration programme should not allow the source platform to decay while the target is being designed. An unstable MIM estate produces unreliable inventory data and turns every migration defect into an argument about whether the old or new system is responsible.

Start with the deployed version and supported platform matrix. Microsoft lists current support combinations for MIM 2016 SP3, including supported Windows Server, SQL Server and SharePoint versions. Compare every MIM server and dependency with that matrix. Record operating-system editions, database versions, SharePoint edition, service accounts, certificates, agent versions, connector builds and hotfix levels. A label such as “MIM 2016” is not enough to establish supportability.

Remove or replace dependencies that Microsoft has already deprecated:

  • Microsoft Entra MFA Server is deprecated and stopped servicing multifactor authentication requests after 30 September 2024. A MIM process that assumes the old MFA Server path needs a supported authentication design.
  • Silverlight is out of support and unavailable. Microsoft says BHOLD modules that require Silverlight should be uninstalled. Leaving an unused BHOLD portal in place creates avoidable exposure and false confidence.
  • Hybrid reporting through the former MIM reporting path is deprecated. Microsoft’s guidance points customers toward Azure Arc-enabled servers and Azure Monitor for reporting and monitoring scenarios.
  • Features on Microsoft’s deprecated-features list should not be selected for new design work. “It still runs” is not a sound reason to increase future dependence on it.

Operational hardening also includes tested backup and restoration, certificate-expiry monitoring, job and connector alerting, documented break-glass procedures, and a clear patching process. Run a restore rehearsal before a major migration wave. A backup that has never been restored is only an assumption.

Inventory the identity processes and their dependencies

MIM estates often contain more business policy than their documentation shows. Join rules, metaverse extensions, synchronization rules, Management Agent flows, workflows, sets, policies, scheduled scripts and manual operating procedures can collectively decide who receives access. A simple list of MIM servers and connectors will miss those decisions.

For every identity journey, trace the complete path:

source event → correlation → policy decision → approval → provisioning request → target result → reconciliation → retained evidence

Use production configuration exports, run histories, connector statistics, service records and target-system evidence. Interview HR, application owners, security, audit and operations, but test workshop answers against the deployed configuration. Where the evidence conflicts, record the discrepancy and assign an owner to decide the future rule.

Classify each current capability into one of five dispositions:

  • Retain temporarily: required in MIM during controlled coexistence.
  • Move: preserve the business outcome in a named target service.
  • Redesign: keep the control objective but change the process or ownership.
  • Merge: combine duplicate rules, roles or connectors before migration.
  • Retire: remove obsolete access, integrations or reports with owner approval.

This classification prevents the target platform from becoming an expensive replica of historical complexity. It also gives auditors a traceable answer when an old process is intentionally removed.

What Microsoft Entra can take over and where analysis is still required

Microsoft Entra now provides several services relevant to a MIM modernisation, but they solve different parts of the problem.

Inbound provisioning can bring worker identity data into Entra ID from supported cloud HR systems or through API-driven provisioning. Microsoft documents a /bulkUpload Microsoft Graph pattern for API-driven inbound provisioning. The source-data contract, matching attributes, data quality, retry behaviour and authoritative ownership still need design.

Lifecycle Workflows can automate joiner, mover and leaver tasks in Entra ID Governance. The service depends on suitable identity attributes and licensing. Microsoft’s deployment guidance makes attributes such as employee hire and leave dates part of the preparation. Published service limits, including workflow and custom-task limits, must be checked against the proposed operating model rather than discovered during implementation.

Application provisioning can provision users and groups to supported SaaS and on-premises applications. Microsoft documents SCIM as the preferred standard for many applications and provides an on-premises provisioning agent for applications behind the organisation’s firewall. For additional on-premises systems, ECMA Connector Host can support connectors without running the MIM Synchronization Service. Connector availability does not prove that every MIM transformation, deletion rule or reconciliation requirement is equivalent.

Entitlement Management and access reviews can support governed access packages, assignment policies, expiry and review scenarios. They require a business model for catalogue ownership, connected organisations, approvers, reviewers, exceptions and evidence. A technically valid access package with no accountable owner is not mature governance.

Self-service password reset has a direct strategic signal: Microsoft recommends that Entra ID P1/P2 customers using MIM for self-service password reset transition to Microsoft Entra self-service password reset. Treat that as a scoped migration with dependency and user-experience testing, not merely a portal switch.

Entra therefore may replace or reduce substantial MIM scope. It does not automatically govern every legacy database, infrastructure endpoint, SAP role, non-human identity or bespoke approval model. Microsoft documents on-premises connectors and extensibility, but each target must be proven against create, update, disable, delete, reconciliation and failure-recovery requirements. Where Entra does not own the complete governance outcome, the architecture may need an enterprise IGA layer, application-specific controls, or both.

A four-track modernisation plan

Run four connected tracks instead of one large “replace MIM” workstream. Each track produces evidence needed by the next.

Track 1. Supportability and risk control

Confirm the lifecycle and licensing position, move to an appropriate current MIM 2016 SP3 update, align dependencies with the supported-platform matrix, remove deprecated components, and rehearse recovery. Build a risk register for single-person knowledge, expired ownership, unsupported connectors, fragile scripts and missing reconciliation.

Exit evidence: approved support record, current component inventory, recovery result, vulnerability and dependency decisions, named operational owners.

Track 2. Identity and control discovery

Map authoritative sources, identity populations, correlation logic, roles, workflows, connectors, privileged access, non-human identities and audit outputs. Measure volumes and failure rates. Define the control objective behind each important rule and classify its disposition.

Exit evidence: signed inventory, data-quality baseline, capability disposition, current-state journey maps, control and evidence catalogue.

Track 3. Target architecture and pilot

Assign each responsibility to a named service. Define where identity state is calculated, where access is requested and approved, which engine writes to each target, and where the reconciled result is stored. Select a pilot that includes a complete journey and realistic failure paths.

The pilot should test missing source data, a duplicate identity, manager changes, rejected approval, target timeout, partial provisioning, urgent termination and rollback. A successful API response is insufficient: compare intended access with actual target state.

Exit evidence: target responsibility matrix, threat and privacy review, pilot acceptance results, reconciled target report, support and operating model.

Track 4. Migration waves and decommissioning

Group applications and journeys into controlled waves. During coexistence, identify exactly which service has write authority for every target and entitlement class. Prevent MIM and a new provisioning service from racing to apply different desired states. Use comparison reporting until discrepancies are understood and accepted.

Decommission MIM deliberately after the last dependency is removed. Stop schedules and inbound feeds in order, archive configuration and evidence according to retention requirements, revoke service accounts and certificates, remove network access, close support procedures and transfer ownership of retained records.

Exit evidence: wave sign-offs, reconciled outcomes, accepted exceptions, archived evidence, revoked credentials, infrastructure shutdown record.

Three decisions leaders should make now

First, decide whether the organisation will use the extension as a stability window or allow MIM scope to grow. New MIM customisation should require an exception with an owner, retirement plan and clear reason why the target architecture cannot provide the capability.

Second, choose an internal completion date earlier than 9 January 2029. Work backward from that date through stabilisation, migration waves, pilot, design, procurement and discovery. Add contingency based on measured integration complexity, not a generic percentage.

Third, fund governance and evidence alongside provisioning. The most visible technical result is usually a created or disabled account. The business result is broader: the right person received or lost the right access, through an accountable decision, and the organisation can prove the final state.

A readiness test for your next steering meeting

Your MIM programme is ready to move from discussion to delivery when the team can answer all of these questions with named evidence:

  • Which MIM build and dependent platform versions are running, and are they supported?
  • Which Entra ID licences and Microsoft support route apply to the estate?
  • Which deprecated MIM components or integrations remain, and what replaces them?
  • What are the authoritative sources for employees, contractors, partners and non-human identities?
  • Which rules or extensions decide identity correlation, lifecycle state and access?
  • Which target service owns lifecycle, governance, provisioning, authentication, reconciliation and reporting?
  • Which service may write to each application during coexistence?
  • How will the pilot prove the actual target state, including failure and rollback?
  • Which historical evidence must remain available after MIM is shut down?
  • What internal completion date leaves enough time before 9 January 2029?

If the team cannot answer several of these questions, the next useful activity is a structured discovery and architecture assessment. Buying another set of licences before the current outcomes and controls are known transfers uncertainty; it does not resolve it.

Where easyIGA fits

Organisations that need a self-hosted governance layer across Microsoft and non-Microsoft systems can evaluate easyIGA as part of the target design. easyIGA provides a business-facing layer over the open-source midPoint identity governance engine, with a focus on access requests, approvals, reviews and understandable governance evidence. Self-hosted by default, on your own infrastructure, in your own jurisdiction. For organisations without suitable infrastructure, an EU-hosted deployment operated by our team is available on request.

Evaluate the target combination against the required identity outcomes and the real application estate. Check who owns each policy and how the implementation proves the result. Discovery, data cleanup and control design remain necessary whichever products are selected.

Contact our team if you want a technical assessment of a MIM estate or help defining the first modernisation wave. A useful review starts with the deployed version, connector inventory, extensions, lifecycle journeys, operating incidents and audit evidence. The output should be a supportability plan, a target responsibility matrix and a prioritised sequence that can be tested.

Confirm the product scope before choosing a platform

For a MIM transition, test easyIGA and midPoint with your connector versions and lifecycle rules. The evidence overview explains captured approvals, external grants and missing historical records. Include approval and failed target changes in the pilot. Our team’s experience with 14+ midPoint implementations helps turn that scope into a practical migration plan.

Continue with the implementation

Use the IGA guide to compare target governance capabilities, and the offboarding playbook to design a leaver acceptance test.

Sources and verification notes

Product scope and editorial wording updated on 24 September 2026. The original source-check dates below remain the dates of those checks.

The factual statements and current product guidance in this article were checked against these primary sources on 12 September 2026.

Support, licensing and service capabilities can change. Confirm the applicable Microsoft terms, licences, deployment versions and contractual support route before making a binding programme decision.

About the author

easyIGA team

Our team’s midPoint delivery experience informs easyIGA and the practical guidance on this website. Meet the people behind the product on About us.

Contact our team to report a factual error or request clarification.