MIM Replacement Vendor Checklist – What to Ask Before Signing

Intro

Many IT leaders recognize the exact moment the sales demo ends and reality sets in. The presentation showed flawless automation and instant connectivity, but post-signature deployment brings a totally different experience.

Are most vendors lying? No, they are simply optimizing their pitch for the close, not for long-term operational success.

This piece serves as a practical pressure-test checklist before making a commitment. It breaks down what really happens beneath the surface of a migration strategy, specifically focusing on connector readiness, licensing structures, professional services scoping, migration complexity, and ongoing support.

As practitioners at Qwey who have sat on both sides of these complex identity deals, the goal is to ensure infrastructure teams know exactly what questions to ask to protect their timelines and budgets. If you’re still deciding whether to migrate at all, see our guide on Microsoft Identity Manager end-of-life risks.

What this guide covers

Connector readiness – how to tell whether a vendor’s integrations will actually work in your environment
Licensing traps – hidden costs in “per identity” pricing and SaaS vs. on-premises economics
Professional services scoping – line items that routinely disappear from vendor quotes
Migration complexity – what “seamless migration” really requires from your team
Post-sale support – how the vendor relationship changes the moment you sign.

Your pre-signature checklist: 4 questions to ask every MIM replacement vendor

When it comes to the actual decision point, the difference between a smooth implementation and a difficult one often comes down to a handful of very direct questions.

If there’s a simple rule for how to evaluate MIM vendors, it’s this – focus less on what the platform promises, and more on how it behaves in your specific context.

Here’s a list of questions I recommend asking:

Can the platform support my organization’s key IAM processes (and if so, how?).
You can also ask the vendor which of their critical workflows are supported out of the box, and which require customization. This is one of the most important things to ask a MIM vendor before signing, because the answer directly impacts both timeline and cost.
How flexible will the solution be when requirements evolve?
It’s about how easily it can be configured or extended later. Some platforms look strong in demos but become restrictive once real-world complexity kicks in.
What will this cost over the next 2-4 years, not just now?
Your goal here is to find out how licensing, support, and additional modules will evolve as the system grows.
What assumptions is the vendor making about your environment?
This is often the most overlooked point. Projects are frequently scoped based on hidden assumptions like clean HR data, simple integrations, or optimistic estimates (e.g. a few hours per application). When these assumptions don’t hold, the gap between expectation and delivery becomes your problem.

The connector gap: “integrates with everything” rarely means what you think

During an on-premise identity management migration, salespeople love to point to a massive catalog of logos and declare that the platform integrates with everything.

But in reality, “supported integration” is a loose term. A logo in a marketing brochure rarely aligns with the complex reality of a production environment. When moving away from Microsoft Identity Manager (MIM), discovering that a critical connector only handles basic login, while completely ignoring entitlement management, role mapping, or automated deprovisioning creates a massive operational bottleneck.

The gap between promise and reality

A look at community discussions across platforms like Reddit reveals a consistent theme: the biggest frustration with modern identity tools is that integrations are much more difficult than vendors make them appear. Security teams repeatedly search for tools that connect easily to SaaS apps, integrate cleanly with HR systems, and work smoothly with Entra, Okta, or Active Directory without requiring months of custom engineering.

Instead, the reality of a migration often brings broken automation. Teams quickly discover that a connector being listed in a vendor catalog does not mean it fully solves the operational problem. Every application handles identity differently. SaaS platforms, cloud providers, legacy internal tools, and HR systems all use distinct APIs, permission structures, and sync logic. Even standards like SCIM behave inconsistently between vendors.

The three tiers of connector reality

To run an accurate MIM vendor comparison on-premise, buyers must distinguish between three different types of connectors, as each carries a vastly different risk profile:

Native connectors. Built, maintained, and fully supported by the vendor. These offer the highest stability but often lack the deep, specific functionality required for complex enterprise workflows.
Partner connectors. Developed by third-party partners. While these expand the vendor’s reach, they often introduce separate licensing costs, fragmented support SLAs, and upgrade delays when the core platform changes.
“On the Roadmap” connectors. Marketing code for software that does not exist yet. Counting on these for a migration timeline is a high-risk gamble that usually leads to project delays.

A mismatch in on-premise connector readiness quickly translates into tangible costs. When a connector fails to deliver, the project suffers from delayed go-live dates, unexpected custom development fees, or a frustrating fallback to manual provisioning.

Moving beyond the vendor sandbox

Evaluating a platform based on a standardized vendor demo is a mistake. Why? Because sales sandboxes feature pristine data, simplified permission models, and zero legacy friction. Real environments, however, are messy. HR databases contain inconsistent department names, contractor edge cases, and duplicate identities that easily break automated role assignments.

The fastest way to verify connector claims before signing a contract is to shift the terms of the demonstration. Do not look at the vendor’s clean environment. To truly test on-premise connector readiness, the validation process must follow two strict rules:

Demand a default feature breakdown. Ask the vendor exactly how they built the integration and which specific lifecycle scenarios work by default, straight out of the box. If basic onboarding requires a multi-week configuration, the connector is not truly ready.
Force a demo on real structural complexity. Do not look at the vendor’s clean environment. Instead, map out the most complex, specific, or questionable identity processes currently running in the organization. Hand that specific architecture over and make the vendor prove the connector can handle those exact edge cases in a live demo.

Flipping the script forces the vendor to show exactly how the integration handles real-world complexity. A thorough MIM environment assessment before vendor demos helps you define exactly which edge cases to test.

Spotting the integration red flags

Several warning signs show that a vendor’s integration catalog is more aspirational than functional:

Connectors listed on marketing pages that carry a hidden “beta” tag.
Integrations that require third-party middleware or extensive custom engineering to perform basic lifecycle workflows.
A heavy reliance on fragile workarounds, such as scheduled CSV imports or custom scripts, to connect with older internal applications that lack modern APIs.

In all honesty, the hidden cost of IAM is rarely the software license itself. It is the continuous engineering effort required to maintain connections as APIs change and application permission models evolve.

What to secure in writing

Verbal promises during the sales cycle offer zero protection when an integration fails during deployment. To protect the project timeline, ensure the final contract explicitly details the technical scope of every critical connector. Demand clarity on the following points:

Exact versioning. The specific version of the connector and whether it supports the exact version of the target system (especially for legacy on-premise tools).
Supported attributes. A complete list of data fields the connector synchronizes out of the box.
Known limitations. Documentation detailing what the connector cannot do, such as handling multi-value attributes or complex approval workflows.
SLA coverage. Clear maintenance guarantees ensuring the vendor updates the connector when third-party APIs change.

Unmasking the connector gap early keeps an identity migration on track and prevents a modern security project from turning into a costly custom development nightmare.

MIM replacement licensing traps vendors don’t mention

Licensing used to be one of the most opaque parts of IAM projects. Over the last several years, things have improved, because most vendors today rely on relatively simple, measurable models – typically pricing based on the number of identities.

On the surface, that makes costs easier to predict and removes the kind of surprises organizations used to encounter in the past.

But that clarity only holds if there’s a clear definition (and understanding of all parties) of what the vendor actually means by an “identity.”

The hidden complexity behind “per identity” pricing

In some cases, the definition is that one employee equals one identity, regardless of how many accounts they use. In others, the same individual can be counted multiple times if they hold separate roles, such as administrator, developer, or standard user.

From a licensing perspective, that distinction can significantly change the total footprint. Two platforms may appear comparable at first, but produce very different cost structures in the end. It’s not hidden, but it’s rarely emphasised in conversations with potential clients, and it tends to surface only when discussions become more advanced.

It’s also worth realising that unused or inactive accounts can be a major source of unnecessary cost. Licensing is typically tied to whether a person is considered active within the organization, and that definition usually comes from HR systems rather than system usage. Employees on long-term leave, for example, are still treated as active identities. Access may be disabled for security reasons, but the license remains.

There are also a few areas where licensing can become more expensive, because it exceeds the basic plan. These include:

governance and certification features
workflow automation
privileged access management
advanced reporting and compliance
enterprise-grade connectors and integrations.

These elements are rarely optional in mature IAM programs. Over time, the platform changes from a single licensing line to a layered cost structure.

SaaS vs. on-premises – the real cost trade-off

If I were to name one of the most tricky decisions in IAM today, this would make the top of my list. The industry push toward SaaS is strong, and for vendors it makes perfect sense financially. For customers, the economics are more nuanced.

It’s true that SaaS removes the need to manage infrastructure and updates, but it’s not like those responsibilities disappear. They’re simply embedded in the subscription cost, and as a result, licensing is often higher.

Though on-premise deployments require internal administration, they can actually be more cost-effective over the long term. This is particularly relevant in environments with strict regulatory constraints or complex customization needs.

There’s also a functional consideration. SaaS platforms tend to limit deep customization. Organizations with non-standard processes need to ask themselves where this is a “deal-breaker”, as it would introduce additional complexity rather than reducing it.

What subscription licensing changes long-term

Most vendors already operate on subscription-based models. This doesn’t create sudden cost spikes, but it does shift how costs accumulate. Namely:

licensing becomes a recurring operational expense
renewal is unavoidable
long-term cost depends on how the platform evolves.

Since the financial impact is spread over time, it makes early decisions more consequential.

That makes one question particularly important: what does the vendor’s product roadmap look like?

Understanding how the solution is expected to develop (and whether on-premise capabilities will keep pace) helps avoid being forced into a migration later on someone else’s terms.

Professional services – the costs missing from your MIM migration quote

Vendors systematically scope for the absolute best-case scenario, not the actual production environment. They build estimates around the assumption of clean data, standard workflows, and a handful of basic connectors.

When a project hits the ground, those assumptions shatter against years of technical debt. Uncovering the hidden costs of on-premise MIM migration early is the only way to protect a budget from death by a thousand Change Requests (CRs).

The best-case scenario trap

From my experience, vendors often gloss over the state of internal data during the sales process. They assume the organization will hand over perfectly structured, clean identity sources. When the migration kicks off, the reality looks like this: duplicate identities, mismatched job titles, inconsistent department locations, and contractor edge cases.

Worse yet, old environments are usually packed with orphaned technical accounts and forgotten access groups. No one knows who owns them or whether they still require their current permissions.

If a vendor assumes a clean slate, the internal team gets stuck cleaning up this data debt in the middle of deployment. The timeline slips and budget overruns follow immediately.

An experienced, transparent vendor approaches this differently. When a project contains too many unknowns, they will not give a flat-rate implementation price. Instead, they quote specifically for an initial analysis and design phase (that’s how we do it at Qwey). They explicitly state that the final implementation costs will be re-evaluated after completing the envisioning and design process. A vendor proposing a multi-stage estimate with room for adjustment is actually a major green flag – it shows they understand the reality of complex infrastructure.

The “Lift-and-Shift” illusion

Believing that policies, rules, and custom logic from an old Microsoft Identity Manager setup will map cleanly onto a new platform is a major mistake. On-premise environments carry a massive accumulation of custom-coded rules and logic. A vendor cannot accurately scope this by simply looking at a device or user count.

To secure a realistic professional services estimate, an organization must provide a live, updated inventory of the current environment.

The problem with dead documentation. Handing a vendor the architecture blueprint written ten years ago during the initial MIM deployment is useless. Documentation must live alongside the system. If it has not been updated with every script rewrite and process tweak over the past decade, it does not reflect reality.
The code gap. If custom code sits between internal APIs to handle authentication or sync logic, the vendor needs to see it. If sample code or documentation cannot be provided, the vendor has to spend days reverse-engineering the logic, driving up MDM professional services hidden costs.

A migration should never be a blind copy-paste exercise. It is a rare opportunity to optimize processes. Instead of forcing the new system to replicate broken, decades-old workflows, an organization should document the current state, map out the desired future state, and hand that exact scope to the vendor during scoping calls.

At Qwey, we call this stage the MIM discovery phase. A structured reverse-engineering of your existing environment before any vendor is engaged. It produces a live inventory of every connector, custom rule, and business process currently running in MIM – the document that replaces dead blueprints and makes vendor scoping calls productive rather than speculative.

See our guide on MIM migration costs and planning for a full breakdown.

Internal costs vendors leave out of the quote

Beyond the vendor’s invoice, an on-premise IGA licensing pitfalls and migration strategy often ignores the massive strain placed on internal teams. The sales pitch focuses on the software, but the budget must account for critical operational tasks that vendors routinely omit:

Policy rewriting and translation. Translating legacy MIM policies into the rules of the new identity governance platform requires weeks of focused work from internal identity engineers.
Coexistence management. The old and new platforms must run simultaneously during a transition period to minimize the risk of a catastrophic outage. Managing this coexistence requires continuous internal engineering oversight.
End-user communication and change management. Moving to a new system changes how people request access, approve workflows, and log in.
Helpdesk surge capacity. The week of the cutover always triggers an influx of password resets, access issues, and sync errors. The internal helpdesk needs extra staffing to handle the surge without stalling business operations.

What “seamless MIM migration” actually involves

“Seamless migration” is a phrase that comes up in almost every conversation around on-premise identity management migration. It suggests that there’s a clean switch and minimal disruption. This can be an overpromise, because replacing MIM is a gradual process closer to a phased programme than a single cutover.

Both systems run in parallel for at least part of the migration process. The new platform is introduced step by step, while the old one continues to operate. If managed well, both environments can coexist without major issues. The problems begin when that transition isn’t clearly structured.

The biggest issue appears when responsibilities are not clearly separated. If the new system is introduced but the old one is left untouched, both can end up doing the same thing and overwriting each other’s data.

Avoiding this comes down to discipline, so:

clearly defining which system owns which processes
disabling or adjusting overlapping functionality in the legacy system

This isn’t always easy to execute without an expert team, because some processes in MIM cannot just be “switched off”. They may require code changes, which takes time and effort.

The dependencies vendors tend to underestimate

I’ve seen that in many MIM vendor comparison on-premise discussions, the focus stays on the platform itself. The complexity, however, often lies in everything connected to it.

Identity systems sit at the centre of a wider ecosystem, including:

SIEM integrations
conditional access policies
network access control rules

These dependencies are easy to overlook early on, but they come up later, when timelines are tighter and changes are more difficult to implement.

How to prevent these issues?

In my experience, too often, organisations choose support models that don’t reflect real operational needs. Setting SLAs in the contract is one thing, but you must also ensure your company receives the level of support it genuinely needs. This depends on:

whether there is a strong internal team
how critical access-related processes are
how quickly issues must be resolved.

Concerned about hidden migration risks? We help organizations pressure-test their vendor proposals and build realistic migration plans before signing. → Book a free vendor review consultation.

Post-sale support: what changes after you sign

Once the ink dries on a contract, the relationship with an identity vendor changes instantly. In a standard SaaS model, a vendor simply pushes a code fix to the cloud when something breaks. But during an on-premise transition, a system failure triggers an immediate blame game. Is the root cause a bug in their software, a recent OS patch, or a specific SQL database version?

Failing to verify post-sale support realities is a massive on-premise IGA licensing pitfalls. Community discussionshighlight that buying the software is just the baseline. Organizations frequently end up trapped in a cycle of paying for endless IAM consultants, custom workflow rewrites, and dedicated administrative staff just to manage brittle, manual connections that vendors promised would be automated.

Cleaning up after the previous vendor

The reality of inadequate post-sale support is clear in how often organizations have to bring in expert engineering teams to rescue a failed deployment. It is incredibly common to step into an environment where a previous provider completed an implementation years prior, yet the system has never functioned correctly. Internal teams end up saddled with endless manual work just to fix corrupted or misaligned data because the original architecture was fundamentally flawed. When an identity system breaks on internal infrastructure, it rarely causes an isolated issue. The dependencies trigger a massive avalanche of connected failures across the network.

The 16,000-user account deletion: a real-world warning

A major warning story regarding on-premise maintenance involved an environment where a sync mechanism failed during a routine data transfer, leaving a critical database table completely blank. Because the legacy platform was configured to assume the source data was always accurate, it immediately began a mass deletion, wiping out 16,000 active user accounts in a single automated cycle.

[Sync Component Fails] ──> [Generates Empty Table] ──> [System Executes Mass Deletion]

Preventing this exact type of catastrophic failure requires two non-negotiable operational safeguards that sales teams rarely include in a standard deployment package:

Strict safety thresholds. The system must be configured with hard operational circuit breakers. For example, if a sync cycle attempts to delete more than 200 users at once, the system must immediately halt the operation and flag the queue for human verification.
Proactive monitoring and alerting. A safety threshold is useless if it stops a process silently. Without continuous monitoring and active alerting protocols, a system block will go completely unnoticed until business operations grind to a halt. Teams cannot rely on a strategy of logging in daily to check for errors manually.

How an independent IAM advisor protects your vendor decision

Replacing MIM is a tedious, but one-off project for any company.

The most common migration paths we see organizations evaluate are:

Microsoft Entra ID Governance (strongest fit for Microsoft-centric environments),
enterprise IGA platforms such as SailPoint, Saviynt,
or Omada (better for complex governance requirements and multi-platform environments),
and open-source options such as midPoint (for organizations prioritizing flexibility and avoiding per-user licensing).

None of these is the right answer for every organization – which is exactly the point.

Having an independent perspective on where to move next can make a major difference for the company’s IAM future. Working with an external team isn’t meant to replace internal decision-making, but to sense-check it. A vendor-neutral partner can help bring clarity to areas that are otherwise easy to overlook.

At Qwey, that’s typically how we get involved. We’re not a software provider ourselves, and we help teams validate their IAM/IGA choices before they become commitments.

If you need help assessing where your organisation can move from MIM or any other solution that no longer meets your need, get in touch.

Frequently asked questions about MIM vendor selection

What is MIM replacement?

MIM replacement is the process of migrating from Microsoft Identity Manager to a newer IAM or IGA platform. Organizations usually replace MIM because of legacy architecture limitations, increasing operational overhead, and evolving security or compliance requirements.

What questions should I ask a MIM replacement vendor before signing?

Ask four key questions: (1) Which IAM processes are supported out of the box vs. require customization? (2) How flexible is the platform when requirements change? (3) What will total cost look like over 2–4 years, including add-on modules? (4) What assumptions is the vendor making about your environment? These questions directly expose the gap between the sales pitch and deployment reality.

What is a “connector gap” in IAM vendor selection?

A connector gap occurs when a vendor lists an integration in their catalog, but the connector only handles basic functions – missing entitlement management, role mapping, or automated deprovisioning. Buyers must distinguish between native connectors (vendor-built, most stable), partner connectors (third-party, variable SLA), and “on the roadmap” connectors (do not yet exist).

What platforms do most companies consider for their MIM replacement?

Organizations evaluating MIM replacement vendors frequently compare platforms such as Omada, One Identity, and Saviynt. The decision usually depends on governance maturity, connector stability, cloud strategy, customization requirements, and operational support capabilities.

Why is MIM migration more expensive than vendors quote?

Vendors scope projects assuming clean data and standard workflows. Real environments contain duplicate identities, orphaned accounts, custom scripts, and undocumented logic. Internal costs – policy rewriting, coexistence management, change management, and helpdesk surge capacity – are routinely omitted from vendor quotes.

What is the difference between native and partner connectors in IAM?

Native connectors are built and maintained by the vendor – most stable but sometimes limited in depth. Partner connectors are developed by third parties — they extend reach but often carry separate licensing, fragmented SLAs, and upgrade delays. “On roadmap” connectors don’t exist yet and should never be included in migration planning timelines.

How long does a MIM migration usually take?

Most enterprise MIM migrations take several months rather than several weeks. Timelines depend heavily on connector complexity, data quality, coexistence requirements, approval workflow redesign, and the amount of custom logic embedded in the old environment.

Should I choose SaaS or on-premises for MIM replacement?

SaaS removes infrastructure management but embeds those costs in higher subscription fees. On-premises can be more cost-effective long-term, especially in environments with strict regulatory constraints or complex customization needs. The right answer depends on your internal capabilities, compliance requirements, and how much the platform needs to be customized.

What to ask your MIM replacement vendor before signing: a practitioner’s checklist