Microsoft Identity Manager (MIM) reaches end-of-life on January 9, 2029. This means, there will be no patches, vendor support, or updates. What sounds like a relatively distant deadline is already an active planning problem for thousands of organizations – because the average MIM migration takes 12 to 36 months, and some environments take up to five years.
This guide brings together everything you need to know: why the window is narrowing, what a safe migration actually involves, how much it costs, and what separates the projects that succeed from the ones that stall.
In a nutshell
- MIM reaches end-of-life in January 2029 – no patches or vendor support after that date
- A typical MIM migration takes 12-36 months; some environments take up to 5 years
- There is no direct MIM successor – every organization must define its own migration path
- Staying on MIM creates security, compliance (GDPR, HIPAA, PCI DSS, SOX), and operational risk
- The biggest migration failures are organizational, not technical
- Licensing, connector readiness, and hidden professional services costs are the financial traps most companies don’t see coming
- Start with a MIM health check and roadmap now before time pressure forces rushed decisions.
Why waiting until 2029 is riskier than it looks
The 2029 end-of-life date feels comfortable. It isn’t. Here’s why.
You don’t know what’s inside your MIM until you start
MIM environments have a way of becoming what we at Qwey refer to as Pandora’s Boxes. Many organizations we work with don’t have proper documentation for their setup. When we begin an assessment, it often turns out that no one truly knows what processes live there, what logic drives them, or even which systems are connected.
We’ve seen companies that had moved “almost everything” from MIM, only to find MIM still running in the background, quietly supporting several business-critical functions no one had fully mapped. Two platforms running in parallel, with no one quite sure what would break if MIM were switched off.
That’s why analysis always comes first.
Migration takes 12-36 months, sometimes longer
The wide timeline range isn’t an exaggeration. It comes from what you find once you open the system. Years of patches, custom scripts, and “temporary fixes” that became permanent. Processes from computer synchronization to improvised role-based access workflows that are extremely difficult to migrate.
In one environment we supported, MIM was connected to over 60 different systems, maintained through layers of quick fixes accumulated over four years. Just cleaning up and stabilizing the environment took thousands of hours before migration work could properly begin.
There is no direct MIM successor
Unlike other Microsoft products, MIM has no clear one-to-one replacement. Microsoft’s focus has shifted firmly to the cloud. Some identity management functions live on in Entra ID (formerly Azure AD), but key MIM features – including certificate management and certain on-premises workflows – don’t have native cloud equivalents. Every organization must define its own path forward. They can consider Microsoft services, third-party IAM tools, or a hybrid model.
Waiting puts you on the clock
All of this takes time. Time to analyze your MIM, plan the migration, and then have both systems in parallel safely. Let’s not forget about the time to train users before cutover. If you wait until 2028 to start, you’ll be forced into rushed decisions or leaving unsupported, non-compliant software running. In the identity space, “unsupported” quickly becomes “unsafe.”
That’s why companies should be asking themselves how long they can afford the risk instead of simply looking at how long technically can MIM still work.
The security and compliance risks of staying on MIM
Security risks that grow with every passing year
After January 2029, Microsoft will stop patching new MIM vulnerabilities. Every new security hole stays open. But the security problem is already building now. MIM only receives security patches, not improvements, and that’s not enough in an era where threats evolve daily.
MIM wasn’t designed for today’s security expectations. It doesn’t natively support stronger authentication methods, adaptive access, or just-in-time privileges for on-premises environments. Modern IAM platforms include these capabilities by default.
A disabled workflow might seem harmless, but it can lead to accounts staying active long after employees leave. We know of companies that lost money because a former staff member kept using an old company login for online purchases. Not malice, just no one remembered to close the door.
We also have a more dramatic example. One company experienced an error in HR that marked 5,000 employees as terminated in SAP. MIM dutifully synchronized that data and deactivated their accounts overnight. On Monday morning, no one could log in. The business stopped for hours. A single safety threshold rule – one that pauses synchronization when too many records change at once – would have prevented it. Simple, but often missing.
Compliance exposure across GDPR, HIPAA, PCI DSS, and SOX
Running unsupported software is a compliance problem waiting to surface. Regulations including GDPR, HIPAA, PCI DSS, and SOX all require that critical systems remain vendor-supported and up to date. Once Microsoft stops supporting MIM in 2029, using it in production could automatically put you out of compliance.
And in practice, auditors don’t wait for a system to be officially retired. If they see a key identity system approaching end-of-life, they want a transition plan. “We’re still thinking about it” doesn’t pass an audit.
MIM’s reporting capabilities weren’t built for today’s compliance expectations. There’s no easy way to run access reviews, enforce separation of duties, or perform certification campaigns. Reporting is limited, and anything beyond basic logging needs to be scripted. We’ve seen teams spend days assembling Excel reports just to prove that the right people have the right access. It’s tedious, and prone to the kind of human error that rarely gets caught until the next audit.
Partial identity management isn’t enough anymore. If only half your systems follow compliance rules, you’re still exposed. Auditors don’t care how strong your Active Directory governance looks if ten other systems are left on manual provisioning.
The operational cost of dwindling expertise
The talent pool for MIM is shrinking. Engineers who built and maintained these environments have moved on to modern platforms. Finding someone who still understands the custom scripts and connectors can feel like searching for a needle in a haystack. Every workaround, every patch applied to keep MIM alive is an investment in a technology with an expiration date. Those same resources could be building your next-generation identity platform.
Why MIM migrations fail – and why it’s usually not technical
Most discussions about MIM migration failure focus on API incompatibilities or sync errors. In practice, projects collapse for organizational reasons: ownership disputes between departments, undocumented business logic buried in “black box” systems, and change fatigue.
The invisible inventory gap
A recurring issue is that organizations rush into vendor selection without first auditing what’s actually running. We’ve seen security departments start a migration with a surprisingly shallow approach, where they’ve focused entirely on the target state while remaining blind to the logic running inside the legacy system.
When a team can’t define what MIM actually does, the project stalls. This often leads to a costly “double-spend”. Companies pay for the new platform that’s being implemented, while MIM also stays active indefinitely because no one knows how to safely untangle it. Two systems running in parallel means that the legacy platform never actually retires.
A thorough MIM environment assessment before vendor selection is the single most effective way to avoid this.
Your MIM instance is an iceberg
A typical MIM instance is an archive of 10 to 15 years of business decisions that nobody ever wrote down. They frequently include custom sync rules, bespoke workflows, and connector logic. The worst part here is that the architects who built these solutions have often long since moved on.
The most common mistake is starting with a platform choice rather than discovery
Organizations sign a contract for Entra ID or a third-party IGA tool, then discover mid-migration that their legacy HR integration is held together by a custom PowerShell script no one knew existed.
A thorough discovery phase frequently uncovers three times more dependencies than initial scoping assumed. If that’s true for your company, then a planned 12-month project becomes an 18-24-month ordeal.
Deep discovery must be the first phase of any credible migration well before any contract is signed.
The organizational failure modes nobody talks about
Identity projects sit at the intersection of HR, IT, Security, and Compliance. In most organizations, no one truly “owns” the data flow between them.
HR is often reluctant to engage with the technical plumbing. The friction between IT and security, where competing priorities meet, can lead to a total standstill.
We’ve seen projects started by IT that stalled the moment they hit HR data quality issues. When neither side is accountable for the “truth” of the identity data, the project dies in a graveyard of unanswered emails.
Research confirms that without a named owner, enterprise projects are significantly more likely to fail. A steering committee isn’t enough, and you need a single leader with the authority to break cross-departmental deadlocks. If a project lacks a sponsor who can resolve an issue between HR and IT, the migration is over before it begins.
Scope creep and the “migration vs. modernization” trap
MIM migrations attract scope creep. Because the system has been in place for so long, stakeholders see the migration as a once-in-a-decade opportunity to fix every lingering identity issue at once.
A platform migration morphs into a full IGA transformation including role modeling, access certification, privileged access, and cloud SSO – while the budget and timeline remain rooted in the original “simple migration” estimate.
The discipline that works is to ruthlessly separate Phase 1 (replicating current-state capabilities on the new platform) from Phase 2 (improving processes, redesigning roles, adding capabilities).
Move first, then improve. Don’t try to fix ten years of process debt while simultaneously changing the entire identity platform.
For a detailed breakdown of failure patterns and a four-step success framework, see our guide on why MIM migrations fail.
What actually needs to be rebuilt when you leave MIM
Moving off MIM isn’t a migration in the narrow sense but a full IAM modernization effort. The core challenge is mapping MIM’s functionality to a new environment. There are four pillars that define MIM’s role and must be rebuilt in any replacement.
Identity sources. Each system – HR applications, organizational directories – that provided data to MIM must now be mapped to new connectors in the replacement platform.
Provisioning rules. Every instruction for a create, update, or disable action needs a clear equivalent in the new platform’s provisioning engine.
Group logic. Rule-based group memberships, including any groups that required approval, must be rebuilt with precise conditions.
Lifecycle flows. The sequence of events for joiners, movers, and leavers requires entirely new triggers, tasks, and termination actions designed for the modern platform.
The hidden logic problem
The hardest part isn’t the visible configuration. Provisioning workflows are relatively easy to review in the MIM console. The most difficult elements are the things no one knows about like the surrounding scripts, external custom code, and auxiliary databases that perform calculations feeding back into the identity system. Finding and dissecting this surrounding logic is critical to avoiding post-migration failure.
Custom code in MIM, frequently implemented as extensions to replace missing features, cannot simply be moved to a new platform. It must be analyzed, and that logic must be integrated into the new environment’s standard processes.
Maintaining security and compliance through the transition
Security gaps during migration are rarely dramatic. They appear as subtle “permission drift” – a role mapped too broadly during a test phase, an entitlement transferred that loses its original restrictions, and quietly, the system becomes over-provisioned. Keeping RBAC and Separation of Duties rules intact through migration requires constant validation.
Audit trails need special attention. When systems run in parallel, the evidence trail splits. Part of the data lives in the old MIM database, the rest on the new platform. Auditors don’t care about your migration plan, they need to see the complete, end-to-end trail. Without clear accountability for log ownership, identity governance stops being a useful control mechanism and becomes a massive data dump.
For a full security and compliance framework for MIM replacement, see our guide on preserving security and compliance in a post-MIM world.
The real cost of replacing MIM
MIM migration costs vary significantly. Some migrations take a few months, others span up to five years, and the cost range is correspondingly wide. Any single number would be meaningless. What you can do is understand the cost categories and build a realistic 3-5 year total cost of ownership.
The cost categories that matter
Legacy cost carry-over. Using MIM means continuing to pay for everything that supports it, including custom-built integrations, and – often forgotten – manual overhead. Provisioning accounts by hand, handling password resets, managing access requests through outdated workflows. These translate directly into time, cost, and risk.
Specialist staff. Ideally, you want someone on board who still understands how to maintain and customize MIM. Their knowledge is essential both for understanding dependencies and for working alongside the team implementing the new IAM solution. Without that person, the initial analysis by an external vendor takes significantly longer and costs more.
License and subscription fees. Modern IAM solutions shift from perpetual on-premises licensing to subscription SaaS or hybrid models. These costs include dual-running: the period when MIM and the new platform must operate simultaneously during transition.
Implementation and integration. These are typically the largest one-time costs and vary by number of systems and complexity. They cover connector work, data mapping, workflow rebuilds, custom scripting, SSO and MFA integration, and testing. For what vendors consistently omit from their quotes, see our guide on what your MIM replacement vendor won’t tell you.
Infrastructure and hosting. Moving to cloud SaaS reduces on-premises hardware spend, but migration costs, cloud consumption, and temporary hosting during transition all need to be factored in. Note that not all organizations can move their solution off-premises due to regulatory requirements.
Cloud versus on-premises: different cost structures
Every client faces the same decision, whether to run IAM in the cloud or keep it on-premises. Cloud IAM platforms simplify maintenance. While there’s no infrastructure management, and no patching, there is also less room for customization. If you rely on unique connectors or bespoke workflows, on-premises still wins. But each update then becomes a project in itself. Replacing MIM means rethinking not just the tool, but the operating model behind it.
Vendors like SailPoint and Omada offer both. One Identity leans more on-premises, which suits organizations with strict data control requirements like banks or government agencies.
7-step MIM migration planning checklist
Step 1: Map your current MIM state. List everything running under MIM – every workflow, connector, and integration point. Capture how many users and applications are in play, and where they sit.
Step 2: Define what you actually need. Focus on business priorities, not features. Decide which modern IAM capabilities truly matter – single sign-on, lifecycle automation, identity governance, hybrid support.
Step 3: Build a total cost picture. Include licensing, migration effort, parallel running, ongoing operations, training, and risk. Total cost of ownership over 3-5 years, not just the implementation bill.
Step 4: Compare vendors against your real requirements. One Identity, Omada, and others differ in how they license users, handle customization, and price support. See our vendor checklist for the specific questions that matter most.
Step 5: Plan the migration rhythm. Don’t rush to full cutover. A phased transition lets you pilot, measure impact, and adjust before scaling. Slower on paper, faster in practice when issues stay contained.
Step 6: Prepare people, not just systems. Technology change fails when communication lags. Train users early, align stakeholders, update governance models.
Step 7: Keep monitoring after go-live. Track license usage, user adoption, support tickets, and access risks. The goal is to stay effective, not just delivered.
What to ask your MIM replacement vendor before signing
The difference between a smooth implementation and a painful one often comes down to a handful of direct questions asked before the contract is signed.
The four questions that expose the gap between sales pitch and reality
- Can the platform support your organization’s key IAM processes – and if so, how? Ask specifically which critical workflows are supported out of the box and which require customization. The answer directly impacts both timeline and cost.
- How flexible will the solution be when requirements change? Some platforms look strong in demos but become restrictive once real-world complexity kicks in. You need to understand how easily it can be configured or extended later.
- What will this cost over the next 2–4 years, not just now? Licensing, support, and additional modules all evolve as the system grows. Get a realistic multi-year view.
- What assumptions is the vendor making about your environment? Projects are frequently scoped on hidden assumptions: clean HR data, simple integrations, optimistic estimates per application. When these assumptions don’t hold, the gap becomes your problem.
The connector trap: “integrates with everything” rarely means what you think
During a vendor demo, salespeople love to point to a catalog of logos and declare that the platform integrates with everything. “Supported integration” is a loose term. A logo in a marketing brochure rarely aligns with the complexity of a production environment.
Buyers must distinguish between three tiers of connectors, each with a very different risk profile:
- Native connectors: Built, maintained, and fully supported by the vendor. Most stable, but sometimes limited in depth.
- Partner connectors: Developed by third parties. They extend the vendor’s reach but often carry separate licensing costs, fragmented support SLAs, and upgrade delays.
- “On the roadmap” connectors: Software that doesn’t exist yet. Counting on these for migration timelines is a high-risk gamble that reliably causes delays.
The fastest way to verify connector claims before signing is not to look at the vendor’s clean sandbox environment. Map out your most complex, specific, or questionable identity processes and make the vendor prove the connector can handle those exact edge cases in a live demo.
The hidden professional services costs
Vendors systematically scope for the best-case scenario. They build estimates around clean data, standard workflows, and a handful of basic connectors. Real environments carry duplicate identities, mismatched job titles, inconsistent department structures, and contractor edge cases. Old environments are packed with orphaned technical accounts and forgotten access groups.
Internal costs that vendors routinely omit from quotes like policy rewriting and translation, coexistence management during the parallel-running period, change management and end-user communication, and help desk surge capacity around cutover.
A vendor proposing a multi-stage estimate with room for re-evaluation after the discovery phase is showing you a green flag. It means they understand the reality of complex infrastructure – and that they won’t surprise you mid-project with the bill for what they should have scoped properly from the start.
FAQ
When does Microsoft Identity Manager reach end-of-life?
Microsoft Identity Manager reaches end-of-life on January 9, 2029. Microsoft stopped releasing major product updates after 2019; the last security hotfix was published in October 2023. After end-of-life, Microsoft will no longer patch new vulnerabilities.
How long does a MIM migration typically take?
Between 12 and 36 months for most organizations, depending on environment complexity. Organizations with many connected systems, heavy customizations, or poor documentation can face timelines of up to 5 years. The earlier you begin the assessment, the more options you retain.
Does MIM have a direct replacement?
No, MIM doesn’t have a direct replacement. Unlike other Microsoft products, MIM has no one-to-one successor. Some functions live on in Entra ID, but key MIM capabilities – including certificate management and certain on-premises workflows – have no native cloud equivalents. Each organization must define its own migration path.
What are the most common alternatives to MIM?
The most common migration paths are Microsoft Entra ID Governance, enterprise IGA platforms such as Omada or SailPoint (better for complex governance requirements and multi-platform environments), and open-source options like midPoint (for organizations prioritizing flexibility and avoiding per-user licensing). None of these is the right answer for every organization, which is precisely the point.
What should we do first if we’re still running MIM?
If you’re still running MIM, start with a thorough assessment of your MIM environment to understand what processes and integrations are actually in place. Then build a migration roadmap with realistic timelines. At a minimum, maintain current documentation, run regular health checks, and ensure your backups are tested. The earlier you start planning, the more options you have, and the less likely you are to end up in a fire drill when time runs out.
Ready to understand what your MIM environment actually contains? Book a free assessment and let’s map your migration options before the clock forces your hand.