MIM replacement plan before end of support

Microsoft Identity Manager end of support falls in January 2029

If your estate runs Microsoft Identity Manager 2016, the replacement decision and the connector inventory need to start now, because scope drives the timeline more than any other factor. Extended support for MIM 2016 ends in January 2029, and some of its surrounding pieces, including BHOLD, hybrid reporting and MFA Server integration, are already out of support. That means the work is not only a future migration but also a clean-up of components you may still be relying on today. List every management agent, rules extension, Portal workflow, SharePoint dependency and scheduled sync run, and record which HR source, directory and target system each one feeds. That list is the input to every later decision, including how much of the estate can move in one wave.

The short answer is that self-hosted midPoint is the main open-source route for MIM provisioning, because it covers provisioning and deprovisioning, role-based access control, auditing, self-service access requests and certification-style governance in one platform, and it connects to Active Directory, LDAP, Microsoft Entra ID and SCIM targets through ConnId connectors. Apache Syncope fits narrower estates that mainly synchronize identities and run self-service password reset, with less need for governance workflow. The choice depends on your constraint. If provisioning must stay on premises, in an air-gapped network or under EU control, midPoint or Syncope are the open-source candidates to evaluate. If the constraint is only licensing and Microsoft is acceptable as the destination, Microsoft Entra ID Governance is the vendor path to price against. Confirm the constraint in writing with your security and compliance owners before you choose a platform.

What the 2029 deadline requires from your identity estate

Replacing MIM is less a single migration than a set of parallel decisions that have to be closed before the cutover. Each card below is a requirement your team owns, and together they determine whether the replacement can run alongside MIM without gaps in provisioning or audit evidence.

Fix the January 2029 end date

MIM 2016 extended support ends in January 2029, so that date sets the outer limit for every other workstream. Confirm the exact end-of-support terms for your licensing with Microsoft, since your agreement may differ from the general lifecycle. Work backward from that date to set internal milestones, leaving room for parallel running and a rollback window.

Inventory agents, rules and Portal workflows

Write down every management agent, every custom rules extension and every Portal workflow that touches a connected system. Record the source and target, the attribute flows and the schedule for each. Without this inventory, the team cannot tell which provisioning paths the replacement must reproduce and which ones can be retired.

Confirm the platform and database stack

midPoint recommends Java 25 for version 4.11 and later, with Java 21 supported, and uses PostgreSQL as its native repository, ideally on a separate database server. Check your Linux, Java, PostgreSQL and backup standards against these requirements now, because they affect hosting, patching and skills. Ask Evolveum or your partner to confirm the support status of any connector you depend on.

Decide where provisioning runs

Decide whether provisioning must stay on premises, in an air-gapped network or under EU control, or whether a cloud route is acceptable. This decision drives the hosting design, the connector set and the support model. Record the decision, its owner and the regulatory basis for it, because auditors will ask why the platform sits where it does.

Assign an owner and change control

Name one accountable owner for the replacement and a change control process for each cutover step, including which connected systems switch first and who approves each switch-off of MIM sync runs. Define how identity changes are reviewed during parallel running so that joiner, mover and leaver events are not duplicated or dropped. This owner also signs off the audit evidence that shows provisioning behaved as before.

What to retire now, before the deadline

Start with an inventory of every dependency on the components that are already gone or no longer supported, before you choose a replacement. Hybrid reporting and MFA Server integration have already ended, so check whether any scheduled jobs, reports, or authentication flows still call them. These failures can be silent. BHOLD is no longer recommended, and its Silverlight modules must be removed. List the BHOLD components, the Silverlight web content, the attestation requests, and the reviewers who use them. Confirm the current status of each item with Microsoft and in your own environment, since support statements change.

For each dependency, record the owner, the connected systems, the data it reads or writes, and the decision that applies. Attestation that must stay on premises, in an air-gapped network, or under EU control is a candidate for midPoint roles and certification campaigns. Reviews that will move to Entra ID access reviews need a different target, and that decision belongs to the identity owner, not the migration team. Treat any role model built from BHOLD attestations as a starting point to validate. midPoint models roles and assignments in its own way, so review the existing entitlements against current business needs before you import them.

Remove dead components before the migration starts, not during cutover. Carrying them into midPoint means rebuilding flows that no one uses. Run each removal in a non-production copy first, and record it in your change process. Export the MIM and BHOLD configuration and keep the attestation history that your retention rules and auditors require. Ask your compliance lead which records must survive decommissioning and who signs off the removal. Set a cutoff date after which no new BHOLD campaigns are opened, so the final review cycle is complete before the old system is switched off.

Which replacement path meets the timeline and the constraint

This table compares self-hosted midPoint, Apache Syncope, Microsoft Entra ID Governance and a MIM bridge on extended support against the January 2029 end date. Read each row against your own connected systems and whether provisioning must stay on premises, in an air-gapped network or under EU control.

Decision factor	Self-hosted midPoint	Apache Syncope	Entra ID Governance or MIM bridge
Fit to the 2029 date	midPoint 4.8 is a long-term release supported until October 17, 2028, so plan a move to a supported release before that date	Version 4.1.3 was released on September 11, 2026; confirm Syncope's own support window with the project before committing	MIM 2016 extended support ends January 2029; Entra ID Governance timing depends on your licensing and tenant plan, so confirm with Microsoft
Provisioning and lifecycle	Covers provisioning, deprovisioning and identity lifecycle through ConnId connectors	Covers provisioning through ConnId connectors; confirm connector coverage for your target systems	Confirm with Microsoft which MIM-era connected systems and HR-driven flows are supported in the cloud service
Governance features	RBAC, auditing, self-service access requests, password reset and role mining	Self-service password reset and an end-user UI and REST API; confirm the depth of approvals and certification with the project	Confirm with Microsoft whether access reviews and entitlement management meet your attestation needs
Where it runs	Your Linux or Docker hosts, PostgreSQL repository, usable in air-gapped networks	Your own infrastructure under the Apache License 2.0	Microsoft cloud tenant; confirm options for on-premises or sovereign requirements before you rely on it
Main trade-off	Your team operates the Java platform and connectors; Evolveum support is optional	Narrower governance scope than midPoint for certification and role mining; check fit against your MIM Portal workflows	Lower self-run effort, but a cloud dependency and licensing that you must confirm with Microsoft
Use as a bridge	Run in parallel with MIM Sync per connected system while the cutover is staged	Suits MIM shops that mainly synchronize and run password reset, so the bridge is shorter	Keep MIM on extended support only until the chosen target runs in production, and confirm the end date in writing

Which midPoint release line to plan on

midPoint 4.8 (Curie) is the long-term support release in this set, and it is the line most likely to cover a plan that runs through 2028. Its support runs until 17 October 2028, which falls before the January 2029 end of MIM extended support. It covers the cutover window only if the move to production finishes during 2028, so the plan should not depend on it for any later phase. Current support dates are listed in the midPoint releases documentation.

Support window: Supported until 17 October 2028. A cutover scheduled after that date runs on an unsupported release unless you upgrade first.
Java baseline: Java 21 is recommended for 4.10 and older, with Java 17 supported. Confirm the exact runtime for 4.8 before building images.
Upgrade work: Any later move requires regression testing of connectors, object templates and task schedules, so start the upgrade design while 4.8 is still in production.
Best fit: Organizations that can finish the cutover in 2027 or 2028 and want a long-term support line through the parallel run.

Confirm the 4.8 Java and PostgreSQL versions against the system requirements, and ask Evolveum how security fixes are provided for the long-term line.

Migration steps in phases, from inventory to decommission

This sequence moves MIM provisioning to a self-hosted midPoint or Syncope environment one connected system at a time, with each phase closing on a check that the old and new paths agree before the next one starts.

Inventory agents, rules extensions and Portal workflows
Your identity or IAM team, with the MIM administrators, lists every management agent in the Synchronization Service, each connected system it touches, every custom rules extension and script, and each Portal workflow, request form and approval path. Record the owner, the sync schedule, the attribute flows and any downstream consumer of the data. Confirm with the business owners which workflows still matter, because many older ones are never used. The step is done when the inventory is signed off and every connected system has an owner who has confirmed it is in scope.
Choose the platform and release line
Decide between midPoint and Apache Syncope using the sibling comparison pages, then pick the release line. For midPoint, the long-term support line 4.8 (Curie) is supported until October 17, 2028, while 4.10 (Braille) is supported until November 26, 2027, so confirm with Evolveum which line fits a go-live date before the first pilot. Check the Java and PostgreSQL versions that line requires. The step is done when the platform, release, support route (community or Evolveum subscription) and target go-live window are written into the project charter.
Build the target environment on Linux and PostgreSQL
Your platform engineers stand up the midPoint or Syncope environment on Linux, either in a virtual machine or from Docker images, with PostgreSQL on a separate database server. Plan for a sticky HTTP load balancer and shared database if you run more than one node. Apply your hardening baseline, backup policy and monitoring, and separate non-production from production. Test that a sample connector can read a directory. The step is done when a non-production instance passes a documented restore test and a connector health check.
Map metaverse attribute flows to resources and templates
Your identity architects translate each MIM attribute flow into midPoint resources, object templates and mappings, and document the source of truth for every attribute. Where a MIM rules extension held business logic, rewrite it as midPoint mappings, roles or policies, and test each rule against sample identities. Compare the resulting account state with what MIM produces for the same users. The step is done when a test set of identities produces identical target attributes in both systems, and every deviation has a recorded decision.
Run both systems in parallel against Active Directory
Operations staff run midPoint in read or simulation mode alongside MIM against a non-production Active Directory, then in a controlled production pilot for a small set of accounts. Compare the changes each system would make every cycle, and investigate each mismatch with the application owner. Keep a rollback path to MIM for each connected system. The step is done when several consecutive cycles show no unexplained differences and the service desk has runbooks for the new platform.
Switch off MIM sync runs per connected system
For each connected system in turn, your operations team disables the MIM management agent run schedule, confirms that midPoint now owns provisioning for that system, and monitors the first full cycles. Move the Portal request paths for that system to midPoint's self-service or access request functions as agreed in the inventory. Retain the MIM configuration and database backup for the agreed retention period. The step is done when the connected system has run on midPoint alone for a full review period with no open incidents.
Retire MIM and its dependencies
Once every connected system is migrated, the platform team decommissions the MIM Synchronization Service, Portal and any SharePoint site, then removes the SQL Server databases and Windows Server hosts that only supported MIM. Export and archive audit logs and configuration as your records policy requires, and remove service accounts and firewall rules. Update the asset register and access reviews. Confirm with your compliance team what evidence they need. The step is done when no MIM component runs, the licenses and servers are released, and the decommission record is filed.

How long a move to midPoint takes and what it costs

How long does a move from MIM 2016 to midPoint take?

No migration duration is supplied here, and the length depends mostly on your environment. The main drivers are the number of connected systems, how many custom rules extensions and Portal workflows MIM carries, how much attribute logic sits in the metaverse, and how long you need to run MIM and midPoint in parallel before switching off MIM sync runs per connected system. Start with an inventory of management agents, rules extensions and Portal workflows, since that inventory sets the scope. Ask any delivery partner for a fixed-scope quote with a written timeline, deliverables and acceptance criteria before work starts.

What costs recur after moving to midPoint, and what is one-time?

midPoint has no license fee, so the recurring costs are infrastructure, connector maintenance and staff time. Optional Evolveum subscriptions are the other recurring line. Evolveum offers Product Support subscriptions with an 8x5 next-business-day or 24x7 SLA for resolving product bugs, and Platform Subscriptions that add feature development and roadmap influence. The page lists no prices, so request current pricing directly from Evolveum. One-time costs include the inventory, design, connector build, data mapping, testing, parallel running and cutover. Recurring costs also include operating the PostgreSQL database, Java runtime upgrades and midPoint release upgrades.

What drives the cost of a midPoint migration up or down?

Cost moves with the same factors as duration. More connected systems, more custom connectors, heavier rules extensions and more approval workflows raise the effort, while a smaller, well-documented MIM estate lowers it. Other factors include how many environments you need (test, pre-production and production), how strict your change control and evidence requirements are, and whether your team already runs Java and PostgreSQL. Ask a provider to price each connected system and each workflow separately so you can see which items drive the total.

Can our own team migrate from MIM to midPoint without outside help?

Yes, some teams do this in-house, but it requires skills in identity data, directory schemas, Java, PostgreSQL and the ConnId connector framework. Your team will need to own the attribute mapping decisions, the approval logic and the testing evidence. Staff time is often the largest hidden cost, because the same people who run MIM today must also support production during the parallel run. If your bench is thin, a fixed-scope engagement can cover planning, implementation, hardening, documentation and knowledge transfer, which DeployOpen delivers in your own infrastructure. Confirm internal skills before deciding.

What does the work need from our team?

Expect to supply named owners for HR-driven provisioning, Active Directory administration, each connected system and security sign-off. You will need access to the current MIM configuration, a test environment that mirrors production, change windows for cutover and business owners who can approve role and access decisions. Documented MIM Portal workflows and approval rules save time, and if they are missing, your team must reconstruct them from interviews and logs. Agree these responsibilities in writing at the start so the schedule does not depend on unnamed people.

What happens if the cutover slips past January 2029?

MIM 2016 extended support ends in January 2029, so a late cutover means running an unsupported identity system in production, which raises security and compliance risk. Plan a buffer by starting the inventory and pilot well before 2028, and track the midPoint release dates for the version you plan to standardize on, including the long-term support release lifecycle. Ask your provider how they will keep MIM running safely during any overrun, and whether a phased cutover by connected system can reduce exposure. Confirm your support position with Microsoft directly, since their terms govern what remains available.

What should we ask for in a migration quote?

Ask for a fixed-scope quote with a written list of deliverables, including the inventory, target design, connector list, data mapping, test plans, parallel-run plan, cutover runbook, documentation and handover. Require the quote to state assumptions, out-of-scope items, acceptance criteria, the timeline and the change requests process. Also ask which Evolveum subscription, if any, is included or excluded, how infrastructure is sized and who operates it after handover. Compare quotes on the same scope rather than on headline totals.

What auditors ask to see for the MIM retirement

Auditors and internal risk teams rarely accept a migration on the strength of a project plan. They ask for dated records that show what MIM did, what replaced it, and when the old path stopped. The six items below connect one another: each one depends on the inventory being complete.

Dated inventory of connected systems

A dated list of every management agent, connected directory, target system and scheduled sync run in MIM, with the owner of each and the attributes it writes. It proves the scope of the retirement is complete. Check that the inventory also lists downstream dependencies such as reports, scripts, SharePoint workflows and the consumers of exported data, because a missed dependency is the most common gap auditors find.

Decommission record for removed components

A record showing when BHOLD, the hybrid reporting pieces and MFA Server integration were removed, who approved each removal, and where the Silverlight modules and related configuration were taken out of service. It proves that components already outside vendor support are no longer in the production path. Keep the uninstall logs and configuration backups together with the approval.

Parallel-run comparison results

For each connected system, a comparison of what MIM and midPoint produced over the same period: accounts created, attributes set, group memberships and disabled accounts. It shows the new process reaches the same outcome before MIM stops. Record every difference, its cause and its resolution, and keep the raw exports so a reviewer can repeat the comparison.

Change records for each cutover

One change ticket per connected system covering the switch from MIM sync runs to midPoint, the rollback plan, the test evidence and the window used. It proves each cutover was controlled and reversible until the point it was accepted. Auditors usually sample these records, so each one should name the approver and the post-change check.

Role and certification evidence in midPoint

Documentation showing that roles, access policies and any review campaigns from MIM were mapped into midPoint, with the mapping decisions and reviewer sign-offs. It proves access rights did not change silently during the move. Confirm which review features your scope requires, because the mapping differs when reviews move to a different tool.

Final sign-off that MIM sync is off

A signed record confirming that every MIM sync schedule is disabled, that the service accounts are removed or restricted, and that the servers are archived or decommissioned. It closes the retirement and gives the audit trail a definite end date. Attach evidence from the servers themselves, not only the project plan. DeployOpen prepares this evidence, but independent auditors give any opinion on whether it meets your obligations.

How DeployOpen plans and runs the MIM replacement

DeployOpen plans and implements the move off Microsoft Identity Manager as a fixed-scope engagement inside your own infrastructure, whether the target is self-hosted midPoint or another route your scope requires. We start from the systems MIM still touches, then agree in writing what gets built, tested and handed over before the cutover calendar is fixed.

How we scope

We inventory management agents, sync rules, Portal workflows and connected systems still running on MIM 2016.
The written scope lists which connected systems move, which stay on MIM for now and which are retired.
We agree deliverables, timelines and responsibilities in writing before any build or cutover work starts.

How we build

We map metaverse attribute flows to midPoint resources and object templates, with each mapping documented and reviewed.
We build ConnId connectors or confirm existing ones for each target system, and test them against non-production copies.
We run MIM and midPoint in parallel against Active Directory and switch off MIM sync runs one connected system at a time.

How we hand over

You receive architecture notes, configuration exports, runbooks and a record of every connector and mapping change.
Test results, parallel-run comparisons and cutover evidence are delivered so your team and auditors can review them.
Knowledge transfer sessions cover daily operations, troubleshooting and the decommissioning steps for Windows Server, SQL Server and SharePoint.

How we support

Post-cutover support, upgrades to newer midPoint releases and continuous testing are available as a retainer.
Upgrade planning follows the midPoint release schedule so your platform stays on a supported version.
Engagement ends with a closeout review of open items, so any later support is a separate, agreed decision.

Microsoft Identity Manager end of support in 2029: plan the replacement