Migrate from Microsoft Identity Manager to midPoint

Double-provisioning happens when MIM and midPoint both have an active connector that can create, modify or disable the same object. The two engines then compete over attributes, group memberships and account state, and each run can reverse the other. Before enabling any midPoint resource for writes, record one owner per connected system and per attribute set. During the parallel run, MIM should remain the write owner for every system that is not yet migrated, and midPoint should read those systems without writing to them.

• Build an ownership register: list each management agent, its connected directory or database, the attributes it writes, and the MIM run profiles that trigger writes.
• Mark one owner per system: for each target, state whether MIM or midPoint may write, and store that decision in change control.
• Separate attribute ownership where needed: a single system can have fields owned by different engines, so document field-level ownership for Active Directory attributes such as userAccountControl, memberOf and proxyAddresses.
• Block accidental activation: confirm that no scheduled MIM run and no midPoint task can write to a system outside its assigned window.
• Review ownership at each cutover: update the register whenever a system changes owner.

Check that every connected system has exactly one named owner in the register before the first midPoint task runs.

Once ownership is recorded, midPoint can be configured so that it reads production sources and computes what it would change without applying those changes. Use the resource and task settings in midPoint to keep write operations disabled while the connector still reads real data. Confirm the exact configuration keys and task options in the midPoint documentation for your release, since the available controls depend on the version you deploy. The midPoint releases page lists the current LTS and feature versions.

• Disable writes on the resource: keep midPoint resources in a mode that reads and reconciles but does not push changes to the target.
• Use reconciliation tasks in preview: run reconciliation in a non-applying mode and capture the proposed deltas as output.
• Use separate service accounts: give midPoint read-scoped credentials for the parallel run, and grant write permissions only at cutover.
• Log every proposed delta: keep the output with timestamps so you can trace a difference back to a source change.
• Verify the connector version: confirm that the ConnId connector for Active Directory in your environment behaves as expected in read mode.

Confirm with your own test directory that a read-only reconciliation produces no changes in Active Directory before you rely on it.

midPoint supports simulations against production data, which lets you compare the outcomes of its policies with what MIM currently does, without writing to target systems. Start with a sample of accounts that cover typical cases: joiners, movers, leavers, accounts with manual exceptions and accounts in nested groups. Then extend the sample to the full population in batches. The goal is to explain every difference, because each unexplained difference is a potential write during cutover.

• Select representative cohorts: include accounts from each organizational unit, service accounts that must stay unmanaged, and disabled or expired accounts.
• Record MIM's current state: export the attributes and group memberships that MIM manages for the same cohort, so each comparison has a baseline.
• Classify each difference: label it as a mapping gap, a missing rule, a data quality issue in the source, or an intended change.
• Resolve gaps in object templates and mappings: correct the midPoint configuration, then rerun the simulation until the differences are either removed or documented.
• Repeat after source changes: HR feed or directory changes can alter results, so rerun the comparison before each cutover window.

Ask your security or compliance lead to approve the list of accepted differences before any system moves to midPoint writes.

Cutover should be done one connected system at a time. For each system, stop MIM run profiles that write to it, confirm that midPoint has the only active write path, and watch the first midPoint writes closely. MIM's management agents should be disabled rather than deleted during the transition, so that the original configuration remains available for rollback. Plan the window with the people who own the target directory and the HR source, since both can trigger changes during cutover.

• Disable MIM run profiles first: stop the scheduled and manual run profiles for the system, and confirm that no queued run will start.
• Enable midPoint writes for that system only: change the resource from read-only to read-write and run a small, controlled reconciliation.
• Monitor the first cycles: compare Active Directory changes against the simulation baseline and check for unexpected disables or group removals.
• Keep a rollback path: retain the MIM management agent, its run profiles and a recent export of the connector space, and document the steps to re-enable MIM writes and disable midPoint writes.
• Set a rollback decision point: agree in advance on the observations that would trigger rollback, and who has authority to call it.

Confirm that the rollback steps have been rehearsed in a non-production environment before the first production system is switched.

When MIM mainly moves identities from an HR source into Active Directory, the migration centers on the metaverse attribute flows and a small number of connected systems. Most of the work is mapping inbound HR attributes, join and projection rules, and the attribute precedence that decides which source wins. In midPoint this becomes resource definitions for Active Directory through the ConnId LDAP or Active Directory connector, with object templates and mappings that express the same logic. Because the scope is narrower, the inventory step is usually shorter, but the parallel run needs careful checks on every joiner, mover and leaver case.

• Attribute flows: Export each MIM sync rule and map it to a midPoint mapping on the resource or object template, then compare results for a sample of users per department.
• Leaver handling: Confirm how disables, moves out of scope and account deletions behave in both systems before switching any run profile off.
• Fewer rules extensions: Simple AD-centric setups often carry few custom rules, so the code to port is usually limited.
• Parallel comparison: Run both systems against the same test OUs and diff the resulting AD attributes, group memberships and account states.
• Ownership of the HR feed: Confirm with HR and the source system owner who signs off on mapped attributes before cutover.

Check that every HR event type your business depends on, including rehires and contractor conversions, is covered by a test case in midPoint.

When the MIM Portal carries request workflows, approvals and self-service screens backed by SharePoint, the migration grows mainly on the workflow side. Portal workflows, custom activities and forms do not transfer as code. In midPoint you rebuild the equivalent with self-service access requests, approval processes and the built-in user interface, so each approval path needs a design decision and a test pass. Expect more stakeholder time for requirements and acceptance than for connector work.

• Workflow inventory: List each Portal request type, its approvers, escalation rules and the systems it fulfills, then decide which ones midPoint should own.
• SharePoint content: Identify which SharePoint lists, libraries or forms hold approval data or reference data, and where that data should live afterward.
• Approval design: Map each approval step to a midPoint approval or access request flow and document any step you choose to drop or replace.
• User training: Plan help material for requesters and approvers, because the screens and steps will differ from the Portal.
• Audit trail: Confirm what history auditors need from old Portal requests and how it will be archived or referenced.

Confirm with the Portal owner which workflows are still in use, since long-unused forms are often the cheapest to retire.

When MIM feeds many systems beyond Active Directory, such as databases, SaaS applications, LDAP directories or file shares, the migration grows with the number of connectors and their custom code. Each management agent needs a matching ConnId connector or a supported option from the connector catalog. Some connectors will be documented and supported, while others may be community or experimental, so confirm each one before committing. Custom management agents that call scripts or external code will need a fresh design rather than a line-by-line port.

• Connector coverage: Match every management agent to a midPoint connector and check its status in the integration catalog before scheduling work.
• Custom code: Identify rules extensions and scripts that call external systems, and plan rewrites as midPoint scripts or connector configuration.
• Per-system cutover: Switch off MIM sync runs one connected system at a time, starting with the lowest-risk target, and keep rollback steps for each.
• Credentials and service accounts: Recreate each target's service account in midPoint and test its permissions against a non-production copy.
• Testing effort: Plan a separate verification run for each system because a successful AD comparison does not prove the others.

Ask the vendor or community for the support status of every non-standard connector you rely on.