Migrate from One Identity Manager to midPoint

Migrate from One Identity Manager to midPoint: what the move involves

Moving from One Identity Manager to midPoint is a process and connector rebuild, not a data copy. The identity data in One Identity Manager reflects decisions made over years of approvals, attestations and rule tuning, and midPoint models those decisions differently, so the work is to re-express each rule in midPoint's terms and prove that it produces the same access outcomes. Renewal pressure, a licensing change, data residency requirements or concern about lock-in are common triggers, and each one raises the same question: which parts of the current configuration must survive the move, and which should be retired. Most teams handle this with an internal IAM group that owns the business decisions, supported by an implementation partner that carries the midPoint engineering. Because that split of work depends on who holds the knowledge of the existing Identity Manager configuration, the first decision is who will document it.

Effort and risk depend less on the platform than on how much custom code and how many target systems sit behind One Identity Manager. Plan the job by component: lifecycle processes (joiners, movers and leavers), attestation and entitlement request workflows, role and policy definitions, and each target system connector. Map each lifecycle and request process to midPoint policies, roles and approval steps, and record which current behaviors are business requirements and which are historical accidents. Rebuild connectors on the ConnId framework, starting with the systems that are already documented as supported, such as LDAP, Active Directory and Microsoft Entra ID, and treat any target system that needs a community or experimental connector as a separate risk item with its own test plan. Attestation has its own track, covered in the attestation topic of this series, because reviewer rules and remediation must match what auditors already accept.

Run both systems in parallel during cutover, and confirm that the parallel period is part of the written scope before work starts. Compare the access state that each system computes for a sample of identities, reconcile differences one by one, and keep One Identity Manager authoritative until the differences are explained and signed off. Ask any implementation partner to define the exit criteria for each component, the rollback path for each target system, and who approves the switch of authority. Confirm with Evolveum which midPoint release line you will standardize on, since midPoint release documentation lists support end dates that affect how long the platform stays in production without a major upgrade. Your internal team will carry the platform after the project ends, so the handover of runbooks, backup procedures and upgrade ownership should be a deliverable, not an afterthought.

Which One Identity Manager capabilities map to midPoint, and what needs rework

This table maps the main One Identity Manager capabilities to their closest midPoint equivalents and marks each row as clean, needs rework or gap. Read the status as a planning signal for effort, not a verdict on either product. Treat SAP and any custom target systems as items to confirm against the midPoint connector catalog before committing to a cutover plan.

Capability	In One Identity Manager	Status in midPoint
Provisioning and deprovisioning	Target system connectors and provisioning workflows tied to the Identity Manager data model	Clean for LDAP, Active Directory, Microsoft Entra ID, SCIM2 and CSV via ConnId; confirm each target
Identity lifecycle	Joiner, mover and leaver processes driven by HR source data and governance rules	Clean for core lifecycle; rebuild custom lifecycle logic as midPoint policies and object templates
Role-based access	Business roles, IT roles and role assignment rules in the Identity Manager model	Needs rework; map roles to midPoint roles and assignment rules, and use role mining to validate the model
Attestation	Attestation policies, approvers and recurring review runs	Needs rework; map to midPoint access certification definitions and reviewer rules, and confirm evidence formats with your auditors
Request and approval	Request catalog, multi-step approval workflows and escalation	Needs rework; self-service requests and approvals are available, but each approval chain must be rebuilt and tested
Auditing and reporting	Governance reports and audit history from the Identity Manager database	Needs rework; midPoint records audit events, so confirm that the reports auditors expect can be reproduced
Password reset	Self-service password reset and password policies	Clean for self-service password reset; confirm policy parity and integration with your directory
SAP coverage	SAP connector and SAP role provisioning	Gap to confirm; check the midPoint connector catalog for your SAP release and modules before committing
Custom target systems	Vendor and custom connectors built on the Identity Manager framework	Needs rework; rebuild each as a ConnId connector in Java, or confirm an existing connector first

How lifecycle, attestation and request processes become midPoint policies and approvals

The first step is to inventory what One Identity Manager actually does for each process, not what the configuration suggests it does. For lifecycle events (joiners, movers and leavers), list the trigger sources, the attribute changes that start a change, the approval steps and the target system actions for each one. In midPoint, these map to object templates and mappings that derive user attributes, assignment policies that decide which roles and resources an identity receives, and policy rules that enforce constraints such as separation of duties. Request approvals are rebuilt as midPoint workflows that route approval work items to approvers. Confirm with your own configuration exports which approval paths are still in use, because long-lived Identity Manager environments often carry approval chains that nobody has exercised for years. Retire those rather than porting them.

Attestation is where the translation needs the most design work. One Identity Manager attestation policies bundle the object set, the approver and the schedule into one object, while midPoint splits these concerns across access certification definitions, campaigns and reviewer rules. Treat the reviewer rules as new design. Decide who reviews which access, what happens when a reviewer does not respond, and how revoked access is remediated: whether midPoint removes the assignment directly or raises a ticket in your service desk. Map each attestation policy to a certification definition only after you have agreed these answers with the audit and business owners. The detailed mapping, including how existing approvers and review evidence carry over, is covered on the attestation page for this migration path. Plan a parallel run in which both systems produce review results for the same population, and compare the outcomes before switching the reviewer workflow over.

What data and integrations to move, and which export paths to use

A One Identity Manager migration moves five distinct things: identities, accounts, roles, entitlements and history. Each needs its own export path and its own check, because midPoint models them differently and the target system connectors have to be rebuilt on ConnId before any data moves.

Identities and their attributes

Identities are the people and non-human owners that midPoint will hold as users. Map each One Identity Manager person attribute, its source system and its update rules to a midPoint user object and its mappings. Confirm in your own One Identity Manager version which export options expose the person table and its custom columns, and decide which attributes midPoint should own and which stay in the authoritative HR source.

Accounts on target systems

Accounts are the per-system identities that One Identity Manager currently links to each person. Export the account-to-person correlation for every target system, then decide whether midPoint should adopt existing accounts through correlation or recreate them. Adoption avoids disruption, but it needs a verified matching rule for each system before cutover.

Roles and business roles

One Identity Manager organizes access in roles, application roles and business roles tied to departments and cost centers. In midPoint these become roles, organizations and assignment policies. Export the role definitions and their membership rules first, then rebuild them in a simulation against production data before any assignment reaches a target system.

Entitlements and group memberships

Entitlements are the individual permissions, such as directory group memberships or application roles, that accounts hold on each target. Inventory them per system, because some are granted directly and others only through a role. Confirm which entitlements One Identity Manager manages and which it only reads, since midPoint will reconcile whatever it manages on every run.

Target system connectors on ConnId

midPoint reaches each system through a ConnId connector, and the documented set includes LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID (Graph API) and SCIM2. Map each One Identity Manager connector to one of these or to a catalog connector, and mark any system without a supported connector as a custom build. Check each connector's status in the integration catalog before committing to it.

Audit history and attestation records

History covers past provisioning events, approvals and attestation decisions that auditors may ask for. These records rarely transfer cleanly into a new platform. Agree with compliance which history must be archived read-only from One Identity Manager, how long it is retained, and where it is stored, before the first production run.

The migration sequence: inventory, pilot, parallel run, cutover and decommission

The sequence moves identity governance from One Identity Manager to midPoint in controlled stages, so each stage has evidence that the new platform matches the old one before the next stage begins.

Inventory processes, connectors and entitlements
Your identity team, the One Identity Manager administrators and application owners list every lifecycle event, attestation policy, request workflow, approval chain, target system connector and entitlement that One Identity Manager handles today. Each item is tagged with its owner and the regulatory control it supports. The output is a process and connector inventory, plus a map showing which items midPoint will cover through policies, approvals, certification definitions or ConnId connectors. The step is done when the business owners sign off the inventory.
Pilot a bounded connector set
Select a small set of target systems and one lifecycle path, such as joiner and leaver for a single directory, and rebuild those connectors on ConnId in a non-production midPoint environment. Load a copy of production identity data and run midPoint simulations to compare the planned changes with what One Identity Manager would do. The output is a pilot connector set with documented gaps, test results and a list of mapping decisions that the governance owner has approved. Expand scope only after the pilot differences are explained.
Run both platforms in parallel
Keep One Identity Manager authoritative for production while midPoint runs in parallel against the same sources and targets in read or simulation mode, where your configuration allows it. Schedule regular reconciliation between the two systems for accounts, roles, entitlements and certification outcomes. Each difference is classified as a defect, a policy gap or an accepted change, with an owner and a resolution date. The output is a series of reconciliation reports that show the differences shrinking over successive runs. Parallel running ends when the remaining differences are either resolved or formally accepted.
Execute a signed cutover runbook
Write a cutover runbook that lists the freeze window, the final data load, the order of connector activation, the rollback trigger and the person who authorizes each step. Test the runbook against a full rehearsal in the staging environment. Confirm that midPoint is the system of record for provisioning, requests and attestation, and that One Identity Manager no longer makes changes to target systems. The output is a signed cutover runbook, the rehearsal log and the first post-cutover reconciliation report. Cutover is complete when the accountable owners sign the runbook.
Decommission and archive One Identity Manager evidence
After a stabilization period agreed in advance, disable One Identity Manager jobs and remove its connections to target systems, then retire its servers and database access according to your change process. Export attestation history, approval records, audit logs and policy definitions into a retained read-only archive, and confirm with your compliance team and auditors which records they need to see. The output is a retained read-only archive of One Identity Manager evidence and a decommission record. Ask your auditors early which retention period applies, because that period drives how long the archive must remain accessible.

How to run One Identity Manager and midPoint in parallel without double provisioning

During a parallel run, exactly one system should be authoritative for each target system at any moment. Assign authority per connector, not for the whole estate: for example, keep One Identity Manager writing to the Active Directory connector while midPoint runs in observation mode against the same directory, then flip the Active Directory resource to midPoint once its reconciliation is clean. Two systems writing the same account or group attribute produce conflicting changes, role drift and access that appears and disappears between runs, so the ownership table should be written down, signed off by the application owners, and reviewed before every switch. Confirm, in your own environment, how each midPoint ConnId connector you rely on handles existing accounts before you let it write.

Reconciliation is the control that proves the two systems agree. Export entitlements per identity from One Identity Manager and from midPoint's projected assignments for the same resource, then compare them by account, group and role membership and classify every difference as expected (a migration mapping gap), a defect in a role or policy, or a genuine change made in a target system. Keep the comparison output as evidence, because it is also the material your reviewers will ask for during attestation cutover. Set a clear rollback point for each resource: the last date on which One Identity Manager remains authoritative and its configuration is still exportable, and the exact step at which midPoint's resource is switched on for writes. Rollback should mean reverting the authority flag and re-running reconciliation, not rebuilding accounts by hand.

Before midPoint writes anything to a production target, run its simulations against production data. Use the simulation features to preview which projections, assignments and policy outcomes midPoint would produce, and compare those previews with the entitlements One Identity Manager currently holds. Treat any unexplained preview delta as a blocker. Ask Evolveum or your implementation partner to confirm which simulation modes apply to your midPoint version and which connectors support the preview you need, because support differs by connector status. Only after the preview matches, and the rollback steps have been rehearsed on a non-production copy, should the connector's authority change go into the change calendar.

What drives migration cost and duration, and how to keep each down

This table lists the main cost and effort drivers for moving from One Identity Manager to midPoint, why each one moves the budget, and what to do to limit it. Read it before scoping, since most of the variation in a quote comes from these rows rather than from the software itself, which carries no license fee.

Driver	Why it moves cost or effort	How to keep it down
Number of target systems	Each system needs a connector mapped to midPoint resources, schema, and reconciliation rules. Connectors are the main unit of rebuild work.	Inventory every target system first, retire unused ones, and check ConnId coverage (LDAP, Active Directory, Entra ID, SCIM2, and others) before estimating custom work.
Custom One Identity Manager scripts and processes	Scripts in the Manager database and custom workflows usually have no direct equivalent. Each one must be re-designed as a midPoint policy, mapping, or approval, then tested.	Classify scripts into retire, replace with standard midPoint features, or rebuild. Ask the partner to quote each class separately.
SAP and Active Directory scope	SAP roles, authorizations, and Active Directory group structures often carry the most business logic and the most stakeholder review. Errors here affect many users at once.	Confirm early which SAP and AD objects must be governed by midPoint and which stay under their current owners. Narrow the first wave.
Attestation and approval complexity	Attestation campaigns, multi-level approvals, and delegation rules must be mapped to midPoint access certification and approval flows. Complex reviewer chains add design and test cycles.	Simplify reviewer chains before migration. Map each attestation policy to one certification definition and review the mapping with the risk owners.
Data quality of roles and entitlements	Duplicate roles, orphaned entitlements, and inconsistent role names increase cleanup effort before any data can be loaded into midPoint. Role mining in midPoint can help, but the output still needs owner review.	Run a role and entitlement cleanup before design starts. Agree on a role catalog with business owners and freeze it for the migration window.
Number of parallel run cycles	Running One Identity Manager and midPoint side by side means two platforms are operated, reconciled, and compared over several cycles, which adds infrastructure and staff time for each cycle.	Define exit criteria for each parallel run, such as reconciliation results and approval outcomes, and limit the number of cycles to what those criteria require.
Internal staff time	Your team provides process owners, approvers, and system administrators. This is usually the largest unseen cost and is paid through existing salaries rather than invoices.	Name owners for each process and connector up front, and protect their time during design and testing windows.
Implementation partner effort	Partner fees follow the written scope: connector count, custom logic, and testing depth. Fixed-scope agreements make the cost traceable to these drivers.	Ask for a quote that lists deliverables per target system and per process, with the assumptions behind each line.
midPoint subscription (optional)	midPoint has no license fees. Evolveum offers Product Support and Platform Subscriptions at prices it does not publish on its support page, and these are optional.	Decide whether you need vendor support and an SLA. Compare the 8x5 and 24x7 Product Support options against your operating model.
Infrastructure and testing environments	Separate environments for test, parallel run, and production add hosting, PostgreSQL database capacity, and Java runtime maintenance. Testing against realistic identity data also takes time.	Reuse infrastructure as code for environments, size the database per the midPoint system requirements, and automate regression tests for connectors.

What usually goes wrong in this migration and how to prevent it

Most failed One Identity Manager to midPoint migrations fail for reasons that are visible early: a copied data model, underestimated connector work, and weak reconciliation. The cards below cover six risks, each with a check you can run before cutover.

Copying the old model

Teams often map every One Identity Manager role, business role and policy one to one into midPoint, which carries forward years of exceptions. Illustrative example: a hundred direct entitlements that were granted by hand become a hundred midPoint roles that nobody owns. Before migrating, mine the current assignments, merge overlapping roles, and assign a business owner to each role midPoint will enforce. Use role mining in midPoint to test the proposed design against real assignments.

Underestimating custom connector work

One Identity Manager customizations, scripts and target system connectors often hold business logic that no inventory lists. Each one must be rebuilt as a ConnId connector or a midPoint mapping, and a custom target may need new Java code. Inventory every target system and script before estimating, and confirm with Evolveum's connector catalog which ones have supported status and which are community or experimental.

Weak reconciliation during parallel run

Running both systems at once only helps if their results are compared. Differences in account correlation, attribute mapping or disabled-account handling produce drift that grows silently. Set up a daily comparison of entitlements per identity between One Identity Manager and midPoint, and treat every unexplained difference as a blocker for cutover.

Attestation evidence gaps

Auditors accept review evidence only when it shows who reviewed what, when, and what was done with revoked access. A midPoint certification campaign that runs but leaves no retained decisions, reviewer records or remediation trail creates a gap. Before cutover, agree with your auditor which reports, retention periods and sign-off records they will sample, and test that midPoint produces them.

Orphaned accounts at cutover

When ownership of accounts moves from One Identity Manager to midPoint, accounts that fail correlation can be left enabled with no owner. These orphans often hold the most privileged access. Freeze provisioning changes during the switch window, export a list of uncorrelated accounts from each target, and assign each one a decision before the old system stops managing it.

Skills gaps in Java and PostgreSQL

midPoint runs on Java and uses PostgreSQL as its native repository database. Teams that have operated Windows and SQL Server for One Identity Manager may lack experience with JVM tuning, Quartz task scheduling in multi-node deployments, and PostgreSQL backup and upgrades. Confirm which skills your team has, check the recommended Java version for your chosen release, and plan training or a support subscription before go-live.

How the migration differs by estate size and starting point

When identities come from one directory and only a handful of target systems receive access, the migration is mostly about proving that midPoint produces the same accounts, groups and memberships as One Identity Manager. The work is concentrated in a small number of connectors, so teams can usually move one target at a time and compare results in a short window. Sequencing tends to start with the authoritative source and the directory connector, then move lifecycle events such as joiners, movers and leavers, and only then attestation and request workflows.

Connector sequence: Rebuild the directory connector first, since every other target depends on the identity data it supplies.
Lifecycle first: Move joiner, mover and leaver handling before self-service requests, because these events drive most account changes.
Short parallel run: Run both tools against the same identities and compare account and group output until differences are explained.
Attestation last: Review campaigns carry the most evidence risk, so they usually move once provisioning is stable.
Cutover by target: Switch write authority one target system at a time so a rollback affects a single system.

Before committing to a plan, confirm with your team which target systems are supported by ConnId connectors and which need custom work.

Questions buyers ask before moving off One Identity Manager

How much effort and cost does moving from One Identity Manager to midPoint involve?

The effort is driven by how much of your current One Identity Manager configuration must be rebuilt: custom processes, attestation policies, entitlement request workflows, and the number of target systems connected. midPoint itself has no license fees, so the cost is mainly the people and infrastructure needed for the move. Recurring costs include hosting midPoint, its PostgreSQL database, and operations staff, plus an optional Evolveum subscription. Ask any implementation partner for a quote built from a written scope that lists each process to map, each connector to rebuild, and the parallel run period. Inventory your current customizations first, since they usually determine the estimate.

How long does a migration from One Identity Manager to midPoint take?

No duration can be stated from the researched facts, so confirm timing against your own inventory. The main variables are the number of lifecycle, attestation and request processes, the count and complexity of target system connectors, the data quality of your current identity sources, and how long you need to run both systems in parallel during cutover. Organizations with a small number of connectors and few custom workflows generally move faster than those with heavy customization. Ask for a timeline tied to milestones in the written scope, not a single calendar date.

What does our internal team need to provide during the move?

Your team needs to supply business owners for each access process, people who can approve role definitions, and administrators who know each target system's protocol and account model. Engineers should own the Java and Linux or Docker hosting of midPoint, the PostgreSQL database, and the sticky load balancer if you run multiple nodes. Security and compliance staff must confirm which review evidence auditors expect. Plan for these people to be available during mapping, connector testing and parallel running, because those phases stall when subject matter experts are missing.

Can our own team migrate from One Identity Manager to midPoint without outside help?

Yes, a capable internal team can perform the migration, since midPoint is open source and its documentation covers installation, connectors and the ConnId framework. The harder part is the knowledge of your existing One Identity Manager processes and the decisions about how roles, policies and approvals should be redesigned. Teams without prior midPoint or IAM engineering experience often use an implementation partner for the design and cutover while keeping operations in house. DeployOpen plans, implements, customizes and documents self-hosted open-source platforms inside your own infrastructure under a written, fixed scope.

Does midPoint have a license fee, and what does the optional Evolveum subscription cover?

midPoint has no license fee. Its repository is licensed under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states that it has no enterprise edition. Evolveum offers Product Support subscriptions for resolving product bugs, with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions that add feature development and roadmap influence. The support page lists no prices, so request a quote from Evolveum for the tier you need. Subscriptions are optional, and you can run midPoint without one.

Does midPoint cover SAP and Active Directory the way One Identity Manager does?

midPoint connects to Active Directory and LDAP through documented ConnId connectors, and it lists Microsoft Entra ID, CSV, DatabaseTable, ScriptedSQL, SCIM2 and SCIMv1 among its documented connectors. SAP coverage depends on the connector status in Evolveum's integration catalog, which ranges from supported to community and experimental. Confirm the exact SAP module, version and provisioning scope you need against that catalog before committing to a design. If a connector is missing or experimental, you may need to build or harden one, and that work belongs in the scope.

Will midPoint evidence satisfy our auditors?

midPoint provides auditing, access certification and role-based access control, but whether its evidence meets your auditors' expectations depends on your control framework and your assessor. Confirm early which reviews, logs and reports the auditor expects, and map each one to a midPoint capability and retention setting. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination.

What to confirm with the vendor and in your own environment before you commit

Start by confirming what you are migrating from. Record the exact One Identity Manager version you run, because the upgrade path and the export options depend on it. Ask One Identity, or check your own support portal, which data can be exported in bulk: the object model for identities, roles, policies, attestation history and request history, and whether the attestation evidence can be extracted in a form an auditor will accept. Attestation records are the hardest to rebuild, so confirm now whether you must keep read-only access to the old system for the retention period your auditors expect. Also check the licence terms that govern exported data and any contractual notice period for ending the subscription.

Next, verify connector coverage against your actual target list rather than the general catalog. Use the Evolveum connectors documentation to check each target system and whether its connector is marked as supported, community or experimental. SAP is the item most likely to need a formal answer: confirm with Evolveum and any SAP-specialist partner which SAP connectors your release supports and what SAP authorization objects they need. For each custom One Identity connector or script, decide whether it must be rewritten as a ConnId connector in Java, and estimate that work from the code, not from the catalog. Confirm the target midPoint release and Java version as well. midPoint 4.10 and older expect Java 21 (Java 17 supported), while 4.11 and later recommend Java 25 (Java 21 supported). Check the midPoint system requirements against your operating system and container platform, and confirm that your release is still within its support window in the midPoint releases notes.

Finally, decide who will host PostgreSQL, the native midPoint repository, and at what support level. midPoint recommends running the database on a separate server, so confirm with your database team whether it will be a managed PostgreSQL service in your own cloud account or a self-managed cluster, and who owns backup, patching and failover. Then choose the support tier. Evolveum's support subscriptions page distinguishes Product Support, which covers resolving product bugs with an 8x5 next-business-day or 24x7 SLA, from Platform Subscriptions, which add feature development and roadmap influence. Ask Evolveum for the current price in writing, and ask a separate implementation partner for a fixed-scope quote covering connector rebuilds, policy mapping and parallel running. Record each answer, its source and its date in your migration decision file.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans and implements the move from One Identity Manager to a self-hosted midPoint deployment inside your own infrastructure, from lifecycle and attestation mapping to connector rebuilds and parallel running. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory of One Identity Manager processes, including lifecycle events, attestation runs and entitlement request workflows, agreed in writing.
Target system list with the connectors each one needs, flagged as supported, community or custom to be built.
Written deliverables, acceptance criteria and timeline for each phase, with no work starting before sign-off.

How we build

midPoint deployment in your own cloud accounts, data centers or air-gapped network, with PostgreSQL and the Java version the chosen release requires.
Mapping of attestation policies, approvers and request workflows to midPoint policies, approvals and certification definitions.
ConnId connector builds or configuration for each target system, tested against non-production copies of the systems they manage.

How we hand over

Documentation of the configured roles, policies, connectors, approval flows and the parallel-run results that justified cutover.
Runbooks for cutover, rollback, decommissioning of One Identity Manager components and evidence retention for reviews.
Knowledge transfer sessions with your platform, security and compliance staff, scoped and recorded in the written plan.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Upgrade planning across midPoint releases, including checks of the support end dates published for each release line.
Confirm with Evolveum which support subscription, if any, your team needs alongside DeployOpen's services.

Migrate from One Identity Manager to midPoint