Straight answers.

How long does a MIM to SailPoint migration take?

We scope to weeks, typically under two months, to a working IdentityIQ site that does what your MIM does. That is what we scope to and what we hold ourselves to, not an average of somebody else's past projects. The exact number depends on how many management agents you run, how much compiled logic sits behind them, and how tangled your joiner, mover and leaver process has become over the years.

The reason it is weeks rather than the usual multi-year program is that the expensive part of a MIM migration is discovery, not engineering. Working out what the current system actually does, spread across a synchronization service, a policy service, a portal, and compiled .NET assemblies nobody has opened in years, is where these projects normally lose their first year. That is the part we automated.

The demand on your own team is measured in days, not months. A working session, a guided wizard, and an export your administrators run themselves.

What do you need from us?

A few hours with the people who actually know your joiner, mover and leaver process. That is the one part nobody can do for you, and it is the part that decides whether the result behaves correctly rather than merely importing cleanly.

Then your configuration, exported by your own team using Microsoft's own tooling. The MIM Configuration Documenter sync and service reports, your portal sets and groups, your connector configuration, and your rules-extension source if you still have it. Everything on that list is produced on your network by your administrators.

Nothing leaves your network before there is an agreement in place. When it does, reports are processed in memory and never stored, nothing is written to disk, and nothing is logged.

We do not have the source code for our rules extensions. Is that a problem?

No. Most estates do not have it. The developers left, the project files went with them, and what remains is a compiled assembly in the extensions directory that has been running untouched for a decade.

We decompile those assemblies, recover the logic, and translate it like any other input. It is your own code, from your own binaries, recovered at your direction and on your instruction. What comes out the other side is readable BeanShell that your team can maintain, which is more than most organizations have today.

Where the recovered logic contains something IdentityIQ genuinely cannot honor, you get a clearly marked scaffold with the reason recorded, not a guess. Nothing is approximated.

How do we know the new system behaves the same as MIM?

We run MIM and IdentityIQ side by side, and during that parallel run MIM is the only system provisioning to downstream systems. IdentityIQ aggregates, evaluates, and produces the provisioning it would send, but nothing it generates reaches a connected system until you decide to cut over. Parallel running is how you get off MIM safely, not a period where two systems write to the same targets.

While both are live, Active Directory group membership is verified as unchanged. The groups a user ends up in through IdentityIQ roles are compared against the groups MIM actually put them in. Connector output is compared the same way, so a difference surfaces during parallel running rather than in production.

MIM stays up, still provisioning, until that comparison satisfies you. You decommission it against evidence, not because a project plan says the cutover date arrived.

Is this a fixed fee?

Yes. We quote a fixed fee because the scope is not a matter of opinion. It is whatever your MIM does today, moved. That boundary is exactly what makes a fixed price honest rather than a guess with a margin bolted on.

If you want IdentityIQ to do something MIM never did, that is a different project. It is billed hourly, it extends the schedule, and we will tell you plainly which one you are asking for before you sign anything. Get off MIM first, improve second. Trying to do both at once is how these projects turn into years.

What happens to our MIM portal?

Your RCDCs, navigation resources, search scopes and filter permissions are inventoried and mapped to Forms, QuickLinks, request authority, capabilities and scopes. You get a complete picture of what the portal does today and where each part of it goes.

No XML is generated for the portal, and that is deliberate. MIM describes its portal with a grid layout model and per-attribute filter permissions. IdentityIQ uses Forms and capability-based scoping. Those are different models, not different spellings, and generating Form XML from an RCDC would hand you something that looks importable and is not.

What you get instead is the inventory, including the losses worth knowing about up front. An honest worklist is a better deliverable than fabricated XML that fails on import three weeks into the build.

When does MIM support actually end?

Extended support for MIM 2016 ends January 9, 2029, extended from the previous date of January 13, 2026. Mainstream support ended January 12, 2021, so since then it has been security updates only, and Microsoft does not accept design changes or new features for products in extended support.

If you are still on FIM 2010 or FIM 2010 R2, those left support entirely on October 11, 2022 and are unsupported today.

Parts of the product have already stopped working regardless of the support date. The MIM hybrid reporting cloud endpoints went dark in November 2025. Entra MFA Server stopped servicing MFA requests on September 30, 2024, which breaks MIM SSPR and PAM approvals.

Do you only migrate to SailPoint?

No. We also move organizations off Okta to Entra ID, and the same discipline applies: establish what the current system actually does, prove the new one matches, then switch off the old one.

The expertise is identity, not one vendor. Entra ID architecture, Entra Connect synchronization, conditional access, passwordless, federation and modern authentication are all in scope, and several of those come up during a MIM migration anyway.

Still have a question?

Ask it on the call. There is no obligation attached to a scoping conversation, and we are not asking you to send configuration data at this stage.