MIM 2016 end of support: what January 9, 2029 actually means
If you run Microsoft Identity Manager, you have probably been told a date and left to work out what it means. This is that, without the vendor framing.
Microsoft Identity Manager 2016 leaves support on January 9, 2029, extended from January 13, 2026. That extension is the detail most people missed, and the reason some organizations quietly shelved a migration two years ago and have not looked at it since.
The date is not the interesting part. What matters is what has already broken, what extended support actually entitles you to, and how long the work in front of you really takes.
The dates, precisely
Four dates matter, and they are all published on Microsoft's own lifecycle pages rather than inferred.
January 12, 2021. Mainstream support for MIM 2016 ended. Everything since has been extended support.
January 9, 2029. End of support, extended from the original January 13, 2026.
October 11, 2022. Forefront Identity Manager 2010 and FIM 2010 R2 left support entirely. If you are still on FIM rather than MIM, you are not approaching a deadline. You passed one nearly four years ago and are running unsupported today.
April 2026. Microsoft released MIM 2016 SP3 builds, and strongly encourages customers to stay on a supported service pack. Being on MIM is not the same as being on a supported MIM.
That last point catches people. Several estates I have seen are running a build old enough that the support conversation is already academic.
What extended support actually gets you
This is where the date is misleading in your favor and against you at the same time.
Extended support means security updates only. Microsoft states plainly that it does not accept requests for design changes or new features for products in the extended phase. So the product you have is the product you will have in
- Nothing is coming.
That has a consequence people underrate. It is not that MIM stops working on January 9, 2029. It is that MIM stopped changing on January 12, 2021, while everything it connects to kept moving. The gap between MIM and its dependencies has been widening for five years, and it widens whether or not you migrate.
Which brings us to the part that is not theoretical.
Parts of it have already stopped working
The support date is a future problem. These are current ones.
MIM hybrid reporting is gone. The hybrid reporting feature, introduced with MIM 2016, is deprecated, and as of November 2025 the cloud endpoints its agent depended on are no longer available. If you built reporting on that, it is not degraded, it is off. Microsoft's guidance is to move to Azure Monitor or equivalent.
MFA Server stopped answering. Entra Multifactor Authentication Server was deprecated, and from September 30, 2024 it no longer services MFA requests. If your MIM self-service password reset or your Privileged Access Management approvals depended on MFA Server, that dependency is already broken. The replacement path is custom MFA providers, Windows Hello, or smartcard based authentication in Active Directory.
Silverlight took BHOLD with it. Silverlight reached end of support, and any BHOLD module with a Silverlight dependency went with it. Microsoft's own guidance is to uninstall those modules.
None of those are 2029 problems. If you have not audited which of them you depend on, that is the most useful hour you will spend this month.
If you are on FIM, your date has already passed
A quiet number of estates never moved from Forefront Identity Manager to MIM. FIM 2010 and FIM 2010 R2 left support on October 11, 2022. There is no extended phase left to sit in and no future date to plan against. You are running an unsupported identity system today, and have been for nearly four years.
The practical consequences are worth stating plainly, because "unsupported" sounds abstract until it is not.
No security updates. If a vulnerability is found in a component FIM depends on, there is no patch coming for FIM. Your compensating control is network isolation and hoping.
No support path when it breaks. Not a slow support path, none. The troubleshooting resource is your own team, whatever documentation survived, and whoever you can hire who still remembers FIM.
An audit finding waiting to happen. If you operate anywhere with a regulator, an authorizing official, or an annual assessment, running an out of support identity system is the kind of finding that is trivially easy for an assessor to write up and very hard for you to argue with.
The good news, such as it is: the migration path off FIM and the migration path off MIM are largely the same work. The synchronization service, the policy layer, the rules extensions and the lifecycle logic all have to be understood and moved either way. Being on FIM does not make the project bigger. It just removes your ability to schedule it comfortably.
Why 2029 is not the deadline that matters
Here is the part nobody puts in a slide.
The binding constraint is not Microsoft's support calendar. It is the fact that migrating MIM is a discovery problem before it is an engineering problem, and discovery is slower than every estimate anyone gives it.
Your MIM configuration is not in one place. It is spread across a synchronization service, a policy service, a portal, and compiled .NET assemblies. The synchronization rules are readable. The policy layer is readable with effort. The rules extensions are compiled, and on most estates the source is gone: the developers left and the project files went with them.
So the honest sequence is not "migrate in 2028 because support ends in 2029". It is: find out what your MIM actually does, discover that a meaningful fraction of it lives in a DLL nobody can read, and then decide what to do about that. The organizations that start that in 2029 are not starting a migration. They are starting an archaeology project with a gun to their head.
What to do in the next ninety days
None of this commits you to anything, and all of it is work you need regardless of which platform you land on.
Run the MIM Configuration Documenter. It is Microsoft's own tool, it runs on your network, and it produces a sync report and a service report. Those two files are the closest thing to a complete statement of what your MIM does. If you do nothing else, do this, because every conversation afterwards is better informed.
Inventory your rules extensions. For every scripted attribute flow, find the assembly name, then find out whether anyone still has the source. Do this before you need the answer. "We will look for it later" is how a six week phase becomes a six month one.
Check the three broken dependencies above. Hybrid reporting, MFA Server, and BHOLD Silverlight modules. Whether you use them is a five minute question with a large blast radius.
Write down your joiner, mover and leaver process as it actually behaves, not as the runbook says. In MIM, one lifecycle event is usually implemented across several management policy rules and workflows. Nobody has the whole thing in their head, and the reconstruction is the part that needs your people rather than a tool.
What a migration actually involves
Two things make MIM migrations slow, and neither is the part people budget for.
The first is that the configuration must be understood before it can be moved, and understanding it is manual unless something reads the reports for you. Every management agent, every join rule, every attribute flow with its precedence order, every set, every policy rule. Transcribing that by hand is where projects lose their first year.
The second is compiled logic. A documenter report can tell you that an attribute flow uses a rules extension. It cannot tell you what the extension does, because that lives in a DLL. Without the source you are reverse engineering behavior from outcomes, or you are guessing. Guessing produces a subtly wrong distinguished name that looks entirely correct in the output and surfaces in production weeks later.
We built tooling for the first problem, and we decompile assemblies to solve the second. You can read how the transformation works, including what it refuses to translate and why, because the honest list is the part that makes the rest credible.
The one thing worth deciding now
You do not have to decide where you are going. Entra ID, SailPoint IdentityIQ, or something else is a real architectural decision and it deserves more than a support date driving it.
What you should decide now is whether you know what your MIM does. Most organizations do not, and the gap between "we have MIM" and "we can describe MIM" is the entire risk in this. That gap does not close on its own, and it gets more expensive every year the people who built it move on.
January 9, 2029 is not the day the system stops. It is the day you stop having the option to wait.