midPoint migration from legacy identity management

What a midPoint migration involves

Teams usually start a midPoint migration when the current identity management tool stops fitting the way they work. Common triggers include a licence change that alters cost or entitlements, custom provisioning scripts that nobody on the current team maintains, a vendor that has reduced support for the version in use, or audit findings about joiner, mover and leaver processing or about access that cannot be traced to an approver. Each trigger should be written down with the control or business outcome it affects, because that record becomes the acceptance criteria for the new design.

In practice, the work changes four things. Provisioning rules move from the old tool's logic into midPoint object templates, mappings and expressions, so every attribute that is derived today needs a documented source and target. Roles and entitlements must be re-expressed in midPoint's role model, which often means consolidating overlapping groups. Connectors to target systems such as directories, databases and SaaS applications are rebuilt on the ConnId framework, and each one needs its own test plan. Account ownership is the most sensitive item: existing accounts must be correlated to identities, and any account that cannot be matched needs a named owner before cutover.

midPoint is open source with no enterprise edition, so the purchase decision is not a licence comparison. The real cost sits in build and run effort: designing the configuration, building and testing connectors, operating the platform, and paying for vendor support if you choose it. Ask any partner to split its quote into one-time build work and recurring operations, and to show which items depend on the number of target systems and the state of existing data. Evolveum's support subscriptions are a separate, optional line item.

Teams with an engineer who has run an IGA product, a Java and PostgreSQL operations capability, and time to run a parallel period usually build in-house. Teams without that experience, or facing a deadline driven by a licence or audit date, often engage a partner for the design, connector build and cutover, then take over operations. Confirm in writing which of the two models you are buying before comparing quotes.

What the work includes

A migration moves provisioning logic, accounts and approvals from the legacy tool into midPoint in controlled stages. Each work package below produces a artifact the client keeps, so the team can verify the move and run the result without the partner.

Inventory of rules, roles and approvals

Every provisioning rule, role assignment, approval step and scheduled job in the legacy tool is listed with its owner, its triggers and the systems it touches. Many rules exist only as undocumented scripts or database triggers, so this inventory is where hidden behavior surfaces. Confirm early who signs off on retiring each rule.

Mapping legacy logic to midPoint constructs

Each inventoried rule is translated into midPoint objects such as object templates, mappings, roles, archetypes and assignment policies. Some legacy logic will not map one to one, and those cases need an explicit decision on whether to redesign the rule or keep it outside midPoint. Ask for the mapping document that records each decision.

Connector setup for each target system

Each target system gets a ConnId connector configured against the account types, attributes and groups it must manage. Service account permissions, TLS settings and secret storage are set per connector, and each one is tested against a non-production copy of the target. Confirm connector status and version in the Evolveum connector catalog before committing to a target.

Account correlation of existing accounts

Accounts that already exist in each target are matched to identities in midPoint using agreed correlation rules, such as employee identifier or mail address, before any new provisioning runs. Accounts that match ambiguously or not at all are reported for review rather than guessed. The correlation report lists match rates per system and the unresolved exceptions with an owner for each.

Parallel running and comparison

Midpoint runs alongside the legacy tool in a mode that calculates changes without applying them to production targets, or applies them only to test scopes. Differences between the two outputs are logged and classified as defects, legacy errors or accepted changes. Agree the comparison period and exit criteria in writing before parallel running starts.

System-by-system cutover and rollback

Target systems move to midPoint one at a time, each with a defined cutover window, a rollback step and a named approver. Legacy provisioning for a system is disabled only after its parallel results are accepted. Dependencies between systems determine the order, so confirm them during the inventory.

Deliverables and handover

At the end, the client receives the rule and role mapping document, the configured environments, correlation reports, test evidence, operational runbooks and a handover session with the team that will run midPoint. Ask for each item to be listed in the statement of work with its acceptance criteria, so that handover is verifiable.

What drives cost and duration

This table lists the main drivers of cost and duration in a midPoint migration, why each one matters and what to reduce before a quote is written.

Driver	Why it changes cost or effort	How to reduce it before the quote
Identity sources and target systems	Each HR feed, directory and target adds mappings, testing and cutover steps.	Agree the source of truth for each attribute and retire unused targets before the quote.
Legacy provisioning rules and custom scripts	Logic hidden in legacy scripts or workflow rules must be re-expressed in midPoint and tested for each target.	List every rule and script with its owner and purpose, and mark which ones are still in use.
Role count and mapping to business roles	Legacy roles often mix job function with system access, so mapping them needs decisions from business owners.	Pull role membership counts and sample entitlements, then agree a draft business role list with owners.
Data quality and manual correlation	Accounts without a reliable matching key need manual review, which costs analyst time and risks wrong links.	Measure how many accounts match on employee ID or email, and clean duplicates in the source before migration.
Environments and parallel-run length	Each environment needs its own configuration, connectors and test data, and parallel running doubles administration work.	Limit environments to what the test plan needs and define exit criteria for the parallel run in advance.
Connector availability for each target	A target without a suitable connector may need a custom or scripted connector, which adds build and test effort.	Confirm each target's connector status in the Evolveum connector catalog and list any gaps early.
Compliance evidence requirements	Assessors may expect reconciliation reports, certification history and change records covering both the old and new systems.	Ask the auditor which evidence they need for the cutover period and agree retention and reporting before design.

Migration phases and outputs

The sequence moves identity records, provisioning rules and connected systems from the legacy tool to midPoint in controlled stages, with each phase closing on a named artifact.

Inventory the legacy identity estate
The team catalogs every source feed, target system, provisioning rule, approval step, scheduled job and role or group definition in the legacy tool, with the owner of each. Output: a signed inventory and a list of rules marked keep, replace or retire. Confirm with the partner whether they will deliver this inventory as a written deliverable and who on your side must validate it.
Design the target model and map roles
Architects define how HR-sourced identities, organizational structure, business and application roles, and assignment policies will be represented in midPoint. Legacy roles are mapped to midPoint roles with documented exceptions. Output: a target design document and a role mapping workbook approved by business and security owners. Length depends on how many legacy roles are unmanaged or duplicated.
Build and configure connectors in non-production
Engineers stand up midPoint in a non-production environment, configure ConnId connectors to each target system, and implement object templates, mappings and provisioning logic. Output: a tested non-production build with test runs for each connector and a defect log. Effort rises with the number of target systems and how many custom attributes or scripts the legacy tool used.
Correlate accounts and cleanse data
Existing accounts in each target system are matched to identities using agreed correlation rules, and orphaned, duplicate or inconsistent records are resolved by data owners. Output: a correlation report with match rates per system, a remediation list and sign-off on the records midPoint will manage. Plan for manual review time, which usually grows with the age and inconsistency of the source data.
Run in parallel and reconcile
midPoint and the legacy tool run side by side for a agreed period, with reconciliation jobs comparing the intended state in midPoint against the actual state in each target. Discrepancies are classified as defects, data issues or accepted differences. Output: reconciliation reports and a go or no-go decision per system. Ask the partner to define the exit criteria in writing before this phase starts.
Cut over system by system
Each target system is moved to midPoint as the sole provisioning authority in a planned change window, with the legacy job disabled and rollback steps rehearsed. Output: a cutover record per system, post-cutover reconciliation results and updated runbooks. Ask the partner to commit in writing to the rollback procedure and to the support window covering each cutover.
Decommission the legacy tool
Once every system is cut over and the agreed observation period ends, the legacy tool is shut down, its data is archived under your retention policy, and its credentials and connectors are revoked. Output: a decommissioning record, an archive of legacy configuration and logs, and an updated list of access granted to midPoint. Confirm with the partner how the archive is verified and who signs off its completion.

What stays in-house and what goes to a partner

This table shows which migration work your identity team should keep, which work a partner usually takes on, and the skills each part requires so you can match tasks to people.

Part of the migration	Usually kept in-house	Often outsourced	Skills it requires
Business ownership of roles	Business owners define which roles exist, who they are for and who approves them	Facilitating role workshops and documenting the decisions made	Business process knowledge, identity domain knowledge, role governance
Approval decisions	Approvers and risk owners decide which access is granted, changed or removed	Mapping approval paths into midPoint workflows once decisions are recorded	Access risk judgment, workflow configuration, audit preparation
HR source definitions	HR owns employee lifecycle states, job codes and the authoritative fields	Building the HR feed mapping and testing joiner, mover and leaver events	HR system administration, data quality analysis, identity domain knowledge
Rule inventory from legacy scripts	Application owners confirm which legacy rules are still valid	Reading legacy scripts, stored procedures and job schedules to list each rule	Legacy language reading (often Java, PowerShell or SQL), reverse engineering, documentation
midPoint object design	Architects agree the target model for users, roles, orgs and archetypes	Designing object templates, schema extensions and mappings in midPoint	Java, midPoint configuration model, XML or JSON object handling, PostgreSQL basics
Connector configuration	Target system owners provide service accounts, endpoints and change windows	Configuring ConnId connectors for LDAP, Active Directory and other targets	LDAP and Active Directory administration, TLS and certificate handling, Java runtime operations
Correlation logic	Identity team confirms which attributes are trusted as matching keys	Building correlation rules that link existing accounts to midPoint identities	Identity data analysis, SQL, PostgreSQL, understanding of account duplicates
Parallel-run reconciliation	Operations reviews discrepancy reports and decides which system is right	Running reconciliation tasks and producing comparison reports between legacy and midPoint	PostgreSQL queries, scripting, Active Directory and LDAP tooling, reporting
Cutover runbooks and final acceptance	Service owners approve cutover dates and sign off access rules as accepted	Writing step-by-step cutover and rollback runbooks for each system	Operations process design, midPoint administration, change management, audit evidence handling

What usually goes wrong

Most midPoint migrations from legacy identity management stall for predictable reasons. The risks below are the ones to plan against before the first connector is configured.

Undocumented legacy rules found late

Legacy provisioning often depends on scripts, scheduled jobs and manual steps that nobody wrote down, such as naming rules, exception accounts or group memberships granted on a particular date. Inventory these from the running system, its job logs and its scripts before designing mappings. Ask the legacy owners to walk through a sample of real joiners, movers and leavers and compare the results with the written policy.

Correlation creating duplicate or orphaned accounts

If midPoint matches existing accounts to identities on the wrong attribute, it creates duplicates or leaves accounts with no owner, and those accounts keep their access. Choose a correlation key agreed with the HR source and the target system owners, then test matching on a copy of production data. Count matched, unmatched and ambiguous records per target before any account is linked.

Legacy roles copied one to one

Copying each legacy role into midPoint as-is carries over years of overlapping and unused access into the new model. A redesigned role model starts from business functions and application entitlements, then maps the legacy roles onto it. Review each proposed role with its business owner and record which legacy roles it replaces and which it retires.

Parallel runs without reconciliation

Running midPoint beside the legacy tool only helps if the two outputs are compared. Without a reconciliation method, differences in access accumulate unseen until cutover. Define a repeatable comparison of entitlements per account and per identity, assign each difference an owner and a resolution, and keep the comparison running until the differences reach an agreed level.

Cutover before owner sign-off

Switching a target system to midPoint before its application owner has approved the new access model leaves that owner unable to reverse unexpected changes. Make owner sign-off a written gate for each system, with the rollback step defined. Cut over one system at a time, and keep the legacy path available until that system's owner confirms the result.

Version and Java requirements unchecked

midPoint recommends Java 25 for version 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older, with Java 17 supported. The repository is PostgreSQL, ideally on a separate database server rather than co-located with the application. Confirm the selected release line, its support end date and the Java and database versions against your standard images before procurement and build.

How the work changes by starting point

Vendor workflows, approval chains and provisioning rules often live in the product's own model, so inventory must capture the behavior the product performs, not only the data it stores. Plan for that from the start.

Inventory: export workflow definitions, approval steps, attribute mappings and the reports auditors rely on, then decide which ones become midPoint roles, policies or archetypes.
Connectors: check each target against the ConnId catalog and confirm the support status of every connector before committing, since some are community or experimental.
Testing: replay sample joiner, mover and leaver events in a non-production instance and compare the resulting entitlements with legacy output.
Cutover: run both systems in parallel for a defined set of targets, then move authority system by system.
Target line: midPoint 4.8 (Curie) is an LTS release supported until 17 October 2028. Confirm the current line when work starts.

What your team needs to provide

Before a midPoint migration starts, your team has to make several inputs available and name the people who approve each phase. Without them, the inventory of provisioning rules and roles stalls, correlation of existing accounts cannot be tested, and cutover dates slip. The first input is read access to the legacy tool's configuration and exports, including its provisioning rules, role definitions, connector settings and any scheduled jobs. Ask for these early, because they define the scope of the inventory.

Correlation needs data that looks like production. Provide sample or production-like account exports from each target system, such as Active Directory, LDAP directories, databases and SaaS applications, along with the HR source extract that will drive lifecycle events. Confirm with your identity team which attribute is the authoritative employee identifier, and decide now whether the HR system or the legacy tool is the source of truth during parallel running. Also provide a test environment that matches production in target system versions, connector endpoints, network paths and authentication, since results from a different setup rarely carry over to cutover.

For each application and role, name a business owner and a technical owner. The business owner approves role content and access decisions, and the technical owner approves connector configuration and cutover. Give administrator access to each target system for both test and production, scoped to the accounts midPoint will use, and agree on approval authorities for changes to roles and assignment policies. Change windows for each system cutover should be booked with the operations team before the plan is signed.

Sign-off works per phase. Typically the sponsor signs the scope and inventory, the identity team signs correlation results and the test environment, and each owner signs the cutover for their system. Agree on a delegate for every owner and a time limit for responses. If an owner is unavailable, the delegate decides within the agreed limit, and any unanswered item is escalated to the sponsor and logged. Cutover for that system stays on hold until someone with approval authority signs, so do not assume silence means approval.

Frequently asked questions

Can our team migrate from our legacy identity tool to midPoint without outside help?

Yes, a capable team can run the migration in-house, but the work is more than installing software. The effort depends on inventorying provisioning rules and roles, correlating existing accounts to identities, and running old and new systems side by side until each target system cuts over. Teams new to provisioning platforms often underestimate the mapping and correlation work. Before committing internal staff, have an experienced reviewer check the inventory and the parallel-run plan.

Does midPoint have a paid enterprise edition we must license?

No. Evolveum states that midPoint has no enterprise edition, and every line of its code is published under open source licenses. The repository is licensed under EUPL-1.2, with Apache 2.0 as a secondary license, and the project describes itself as open source. Your costs therefore sit in people, infrastructure, subscriptions and any implementation partner. Confirm the current license terms in the repository before you document them internally.

What do Evolveum subscriptions cover compared with implementation work?

Evolveum subscriptions cover the platform vendor side, while implementation work covers your environment. Product Support subscriptions cover resolving product bugs, with an 8x5 next-business-day or 24x7 SLA option. Platform Subscriptions add feature development and roadmap influence. Neither includes designing your role model, mapping your HR source, building connectors for your target systems, or cutting over your applications. Evolveum's support subscriptions page lists no prices, so request current pricing from Evolveum directly.

How long should a parallel run last before cutover?

The length of a parallel run is set by risk and verification, not by a fixed number in the plan. Confirm the duration with your change board and the business owner of each target system. Drivers include how many systems cut over at once, how often joiner, mover and leaver events occur, how well correlation matched existing accounts, and how quickly reconciliation reports show drift. Each system needs an agreed exit test and a rollback path before the legacy tool stops provisioning it. Record the entry and exit criteria in the written scope.

How is a fixed-scope midPoint migration quote structured?

Most DeployOpen engagements are fixed-scope, so the quote follows a written scope agreed before work starts. It should list the legacy inventory of rules and roles, the HR source and identity model, the connector for each target system, the correlation approach, the parallel-run exit criteria, the cutover sequence, documentation and knowledge transfer. It should also state assumptions, client dependencies and the change-request process. Ask which items are one-time and which recur, such as subscriptions or a support retainer.

What must our team provide before a migration project starts?

Your team must provide access, data and decisions, and the project stalls without them. Expect to supply read access to the legacy tool's configuration, roles and account data, an agreed HR extract or feed, administrator contacts for every target system, and test accounts or sandboxes for each connector. Named business owners must approve role definitions and cutover order. Confirm where midPoint will run, since it operates on Linux virtual machines or Docker images inside your infrastructure, and who approves change windows.

How DeployOpen delivers this service

DeployOpen plans and builds the move from your legacy identity management tool to midPoint inside infrastructure you control, working from a written scope agreed before work starts. We inventory what the legacy system does today, rebuild it in midPoint, and cut over one system at a time.

How we scope

The written scope lists the legacy provisioning rules, roles, approval flows and target systems that move to midPoint.
Scope records which connectors each target system needs and whether each one is supported, community or experimental.
Scope states how existing accounts will be correlated, and which records are reviewed by hand before cutover.
Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before the migration starts.

How we build

We map each legacy rule and role to midPoint object templates, mappings, assignments and archetypes, and record every mapping decision.
Connectors to each target system are configured and tested against non-production copies before any live account is touched.
Existing accounts are correlated and compared with midPoint's view, and differences are logged for owner review.
Each system runs in parallel with the legacy tool until reconciliation results are accepted, then cuts over on an agreed sequence.

How we hand over

Handover includes the mapping inventory, role model, connector configuration and cutover runbook for your team to keep.
Test evidence covers reconciliation results, rollback steps and the parallel-run comparison for each cut over system.
Documentation names the midPoint version, Java and PostgreSQL versions and each external dependency in your environment.
We walk your identity team through administration tasks so they can operate midPoint after the project closes.

How we support

Ongoing support, upgrades and continuous testing are available as a DeployOpen retainer after cutover.
Confirm with Evolveum which midPoint release you will run and its support end date before choosing a release line.
Evolveum Product Support subscriptions cover product bugs with an 8x5 next-business-day or 24x7 SLA, so confirm which level you need.
Retainers can cover connector checks and configuration review before each midPoint upgrade in your environment.