Migrate from SailPoint IdentityIQ to midPoint

Migrate from SailPoint IdentityIQ to midPoint: what the move involves

Moving from SailPoint IdentityIQ to midPoint is a project of export, redesign, connector rebuild and parallel running, and it is usually led by identity engineers with compliance staff providing the control requirements. Teams facing a renewal or the 9.0 upgrade decision should treat the move as a question of scope before they treat it as a question of license cost. SailPoint announced IdentityIQ 9.0 on October 6, 2026 as the modernization path for hybrid and on-premises customers, so the upgrade and the migration both require the same inventory of what the deployment actually does today.

midPoint is developed by Evolveum, licensed under the EUPL-1.2 with Apache 2.0 as a secondary license, and carries no license fees. Evolveum sells support subscriptions, consulting and training, so the recurring cost of running midPoint is the staff, infrastructure and any support contract you choose, not a per-identity license. Ask Evolveum or a partner for a written estimate that separates connector work, rule and workflow redesign, testing and operations, because those components move the total far more than the platform does.

Effort depends on the number of rules, workflows, applications and certification campaigns in your IdentityIQ instance, and on how many of them still reflect current policy. Count them first. Identify which rules are simple attribute mappings, which encode business logic that midPoint expresses differently, and which campaigns exist only because an old process required them. An illustrative case: an instance with a few applications and one campaign will move faster than one with dozens of custom connectors and years of accumulated rules. Confirm your own counts before you accept any timeline, and plan a parallel run through at least one audit cycle before you retire IdentityIQ.

Which IdentityIQ capabilities map cleanly to midPoint and which need rework

This table pairs each IdentityIQ capability with its closest midPoint equivalent and a migration note marked clean, needs rework or gap. Read it as a planning aid: clean rows can usually be rebuilt from exports, rework rows need redesign, and gap rows need confirmation with Evolveum before you commit to a target design.

IdentityIQ capability	midPoint equivalent	Migration note
Provisioning and lifecycle	Provisioning, deprovisioning and identity lifecycle with resource-driven synchronization	Needs rework: lifecycle rules and joiner, mover and leaver logic must be redesigned, not copied from XML
Roles and role mining	Role-based access control and role mining, with simulations against production data	Needs rework: role models should be rebuilt from mined candidates and validated with simulations before cutover
Certifications (Compliance Manager)	Certification campaigns with definitions, stages, reviewers and remediation	Needs rework: map campaign schedules, reviewer rules and remediation steps one by one and confirm feature parity with Evolveum
Password management (Password Manager)	Self-service password reset and password policy handling	Needs rework: confirm which password flows and questions your policies require and test each one
Access requests	Self-service access requests with approval flows	Needs rework: approval logic in IdentityIQ workflows must be rebuilt as midPoint approval processes
Connectors	ConnId connectors, including LDAP, Active Directory, SCIM2 and Microsoft Entra ID, plus catalog connectors	Needs rework: each connector must be validated against the target system, and connector status ranges from supported to experimental
Rules and workflows	No direct import of IdentityIQ rules or workflows	Needs rework: treat rule and workflow logic as specifications to redesign and test, not code to port
File Access Manager	No clear midPoint equivalent identified	Gap: confirm with Evolveum whether any file access governance capability is covered or whether a separate tool is needed

What can be exported from IdentityIQ and what must be rebuilt

IdentityIQ gives you a reference copy of its configuration, but the copy is not a migration package. Each card below covers one part of the estate, what the export gives you, and what your team must redesign or reimplement on midPoint before the first parallel run.

Role and rule XML exports

Roles, rules, workflows and applications can be exported as XML through the IdentityIQ console export command. Treat the files as a readable record of what the system does today, not as objects that load into midPoint unchanged. Each rule's logic, such as correlation or provisioning decisions, has to be read, understood and rewritten as midPoint configuration. Confirm with your SailPoint administrators which export scope covers all custom objects in your instance.

Identity and entitlement extracts

Identity and entitlement data is the most reliable input for a midPoint build, because it shows who holds which access today. Extract it from the source systems and from IdentityIQ's own records, then compare the two to find accounts that were never correlated. Plan to load this data through midPoint's import and reconciliation tasks, and check how many identities and accounts are orphaned before you design roles against them.

Workflows and approvals as redesign work

IdentityIQ workflows for access requests, approvals and joiner-mover-leaver steps do not translate line by line. Document each workflow's approvers, escalation paths and conditions from the XML, then rebuild them with midPoint's self-service request and approval features. Expect this to need decisions from process owners, not only developers, because some steps may no longer be needed on the new platform.

Connectors to rebuild on ConnId

Each IdentityIQ application connector must be matched to a ConnId connector that speaks the same protocol. midPoint documents LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID (Graph API) and SCIM2 connectors, and an integration catalog lists further options with varying support status. For every application, record the protocol, the account attributes and the entitlement model, then confirm in the connector documentation whether a supported connector covers it.

Custom Java connectors to reimplement

Custom Java connectors written against IdentityIQ's connector interface cannot be ported as code. Each one needs a new implementation against the ConnId interface, where the connector is Java code that speaks the target system's protocol behind a uniform API. Budget testing against a non-production copy of each target system, and confirm the reimplementation covers every operation the old connector performed, including reads used for reconciliation.

Scripted integrations and custom code

Before-and-after scripts, custom rules and BeanShell or Java helpers in IdentityIQ often hold business logic that nobody has documented. Inventory every script referenced by applications and rules, note what each one reads and writes, and decide whether midPoint expressions, scripted connectors such as ScriptedSQL, or a separate service should replace it. Treat this inventory as the main scope risk, because it is the part most often underestimated.

How the migration sequence runs from inventory to decommission

The sequence moves IdentityIQ responsibilities into midPoint one controlled stage at a time, so each stage produces evidence that the next stage depends on. Nothing is switched off until the new platform has been checked against a full certification cycle.

Inventory applications, rules, workflows, campaigns and roles
Export the IdentityIQ objects as XML through the console export command, then list every application, rule, workflow, certification campaign and role with a named business owner and a technical owner. Mark each item as keep, redesign or retire, since many IdentityIQ rules encode logic that midPoint expresses differently. The output is a signed role catalog and an application inventory that the owners have reviewed, and a list of rules that need a redesign decision rather than a direct port.
Rebuild connectors on ConnId
For each application in scope, identify whether midPoint already has a ConnId connector (documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID and SCIM2) or whether a custom connector must be written in Java. Confirm the status of any connector from the integration catalog, since status ranges from supported to community and experimental, before relying on it. The output is a connector register with a status and an owner for each system.
Pilot on one or two connected systems
Choose one or two systems with stable connectors and a representative sample of identities, then model their accounts, entitlements and a small set of roles in midPoint. Run simulations against production-like data and compare the proposed access with what IdentityIQ grants for the same identities. The pilot is complete when the differences are explained and accepted by the application owners, and the reconciliation report shows no unexplained account or entitlement mismatches.
Translate certification campaigns and run both systems in parallel
Rebuild each campaign as a midPoint certification definition with its stages, reviewers and remediation rules, then run it alongside the IdentityIQ campaign for the same population through a full certification cycle. Reconcile reviewer decisions, revocations and evidence between the two systems and record every difference with its cause. The output is reconciled campaign results and an evidence pack that the audit team has reviewed before any cutover.
Cut over provisioning and campaigns
Move provisioning and deprovisioning for each connected system to midPoint in agreed waves, with a documented rollback path to IdentityIQ for every wave. Switch certification scheduling to midPoint only after the parallel run has closed without open findings. The output is a cutover record per wave showing the date, the systems affected, the approvers and the verification results, and IdentityIQ no longer issues provisioning requests for the migrated systems.
Retain evidence and decommission IdentityIQ
Before shutdown, export and archive the IdentityIQ database, XML objects, audit logs and historical campaign results in a format your retention policy and auditors accept, and confirm with them what they require. Then disable IdentityIQ connectors, remove service accounts and decommission the servers. The output is an archived evidence set with a retention owner and an access record, plus a sign-off from security and compliance that the decommission is complete.

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

This table lists the factors that most change the effort of moving from IdentityIQ to midPoint, why each one matters, and what to do about it. Use it to scope a quote, since no figures for DeployOpen or Evolveum prices are given here, and the Evolveum support page lists no prices.

Driver	Why it matters	How to reduce it
Number of applications and custom connectors	Each connected system needs a ConnId connector or an existing one configured, tested and monitored. Custom IdentityIQ connectors must be re-implemented in Java, which is often the largest single effort.	Inventory every application and mark those with a documented connector, those using a generic connector (LDAP, CSV, database, SCIM) and those needing custom code. Retire unused applications before migrating.
Volume and quality of the role model	Roles, IT roles and business roles often grew without governance. Copying them unchanged carries duplicates and orphaned entitlements into midPoint.	Run role mining and simulations on current assignment data first. Agree a target role model with business owners before building any objects in midPoint.
Number and complexity of rules and workflows	IdentityIQ rules are Beanshell or similar scripts that encode business logic. Workflows often embed approvals and escalations that midPoint models differently.	Export rules and workflows as XML, classify each by purpose and rewrite the logic as midPoint mappings, policies and approval flows instead of line-by-line translation.
Certification campaign history auditors need	Assessors usually ask for evidence of past reviews, decisions and remediation. Losing this history, or failing to show the same campaign logic in midPoint, can extend the audit cycle.	Ask your auditor which past campaigns and evidence must be retained. Export reports from IdentityIQ before decommissioning and document how midPoint certification definitions replace each campaign.
Integration with HR and authoritative sources	Joiner, mover and leaver events depend on correct source data and attribute mappings. Gaps here show up as wrong access after migration.	Document each authoritative source, its attributes and its update frequency. Test mappings against a copy of production data and confirm the owner of each source.
Testing depth	Parallel running and reconciliation need test data, repeatable test cases and sign-off from application owners. Thin testing tends to move defects into production.	Define test cases per connector and per role, use a non-production midPoint environment and plan at least one full parallel run through an audit cycle before cutover.
midPoint support subscription choice	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 choice and cost depend on quotes.	Request written quotes for each option. Match the SLA to how critical IGA is to your operations, and decide whether a Platform Subscription is needed at all. Support is optional, since midPoint itself carries no license fees.

Running IdentityIQ and midPoint in parallel through an audit cycle

Run IdentityIQ and midPoint side by side for at least one full certification cycle, because auditors need to see that the new platform produced the same access decisions under the same controls before IdentityIQ is switched off. The parallel run is the evidence period, not a test you can shorten once the connectors work. Confirm the length of your own certification cycle with your auditor before you fix the cutover date, since that cycle determines how much evidence you must show. Define one authoritative system for provisioning at each stage and write it down per application. Until an application is cut over, IdentityIQ remains the only system that provisions to it, and midPoint runs in read-only reconciliation mode against the same target. After cutover, midPoint becomes the sole provisioner and IdentityIQ may only read or report. Reconcile entitlements nightly by comparing the account and entitlement set midPoint sees on each target with the set IdentityIQ holds, and log every difference with its owner. Campaign decisions need the same treatment: export the reviewer, item and decision fields from both systems for the overlapping campaign, and agree in writing how a mismatch is resolved and who signs off.

Keep the evidence in a form the auditor can read without either product running. Retain the XML exports taken from IdentityIQ, the midPoint configuration exported as XML objects, version-controlled change records for every role and rule edit, the reconciliation reports, and the signed decision exports from each campaign. Store them in write-once or access-controlled storage with retention periods set by your records policy. Test that a sample of decisions can be traced from the campaign item to the target change in both systems. Agree the cutover checks in writing before the parallel run begins. A practical set includes zero unexplained entitlement differences for a defined number of consecutive reconciliation runs, every high-risk application validated by its owner, a documented rollback path to IdentityIQ for each application, and sign-off from the control owner and the auditor on the test results. Ask your midPoint implementation partner and your auditor to state their acceptance criteria before work starts, and record them alongside the migration plan.

What usually goes wrong in an IdentityIQ to midPoint move

Most failed migrations break in the same few places: old logic copied without review, connectors underestimated, and evidence gaps discovered during an audit. The cards below pair each risk with one prevention step to settle before the first cutover decision.

Copying rules and workflows

IdentityIQ rules and workflows are Java and BeanShell logic written around IdentityIQ's own object model, so exporting them as XML does not give you working midPoint behavior. Teams that port each rule line by line often carry over workarounds for problems midPoint solves differently. Before writing code, list each rule by the business outcome it enforces, then redesign it as a midPoint mapping, policy rule or task.

Underestimating custom connector work

Out-of-the-box connectors cover common targets, but many IdentityIQ applications use custom connectors, rule-driven aggregation or proprietary APIs. Each one must be rebuilt as a ConnId connector, which is Java code behind a uniform interface, and tested against the target system. Inventory every application by connector type and owner early, and budget connector development and testing as separate line items.

Role model translation drift

Roles in IdentityIQ often encode years of exceptions, bundles and assignment rules that no one documented. When they are re-created in midPoint, entitlements can silently grow or shrink, and users may gain access they never held. Compare effective access for a sample of identities in both systems before cutover, and record every role decision in a mapping sheet that reviewers can sign off.

Certification evidence gaps

An auditor asks who approved an access decision, when, and what happened next. If IdentityIQ campaign history is not exported and linked to midPoint certification records, the evidence trail breaks at the migration boundary. Decide which historical campaigns must be retained as read-only archive, and confirm with your auditor and compliance team which evidence format they will accept.

Unclear cutover ownership

A migration spans identity architecture, application owners, the service desk and the audit function, and each group may assume another owns the go or no-go decision. Name a single accountable owner for cutover, define who approves each application moving to midPoint, and agree the rollback authority in writing before the parallel run starts.

Skipping the parallel run

Switching all applications in one step leaves no comparison baseline when a provisioning or certification result looks wrong. Run midPoint alongside IdentityIQ for at least one full certification cycle, comparing joiner, mover and leaver outcomes and review results for the same population. Make the comparison report a formal exit criterion for each application, and keep IdentityIQ read-only until the audit team has accepted the evidence.

How the migration differs by starting point

A single IdentityIQ deployment with a small number of connected applications is usually the most contained starting point. The inventory of roles, rules, workflows and connectors is short enough to review object by object, and the number of certification campaigns is often limited. Scope is driven mainly by how many systems each connector must reach and how many reviews the audit team relies on.

Connector inventory: List every application and the connector type it uses, then map each one to a ConnId connector such as LDAP, Active Directory, CSV or Microsoft Entra ID (Graph API).
Role model: Export the roles as XML and decide whether each one becomes a midPoint role, an organizational structure or an assignment rule.
Certification scope: Confirm which campaigns auditors actually use and rebuild only those as midPoint certification definitions.
Parallel run: Keep IdentityIQ read-only for one full review cycle while midPoint provisions to test targets.
Platform: Confirm the Java and PostgreSQL versions required for the midPoint release you choose in the midPoint releases documentation.

Before committing, confirm with your auditors that a single review cycle on midPoint will satisfy the evidence they expect.

Questions buyers ask before moving off IdentityIQ

What does a move from IdentityIQ to midPoint cost, and what drives it?

The cost is driven by scope rather than by a license line, because midPoint has no license fees. The main components are the people who export and rebuild roles, rules, workflows and certification campaigns, the connector work that replaces IdentityIQ applications with ConnId connectors, testing against production-like data, infrastructure for midPoint and its PostgreSQL database, and the staff who operate the platform afterward. Costs that recur include infrastructure, operations and any optional Evolveum support subscription. Ask any vendor, including DeployOpen, for a written quote that lists the number of applications, rules, workflows and campaigns in scope, the connectors to build, and who performs each task. DeployOpen fixes scope and deliverables in writing before work starts.

How long does an IdentityIQ to midPoint migration take?

The timeline depends on how many applications, custom rules and workflows you have, how many connectors must be built or validated, and how many certification cycles you need to run in parallel before you retire IdentityIQ. Every IdentityIQ estate is different, so no fixed duration applies. Your inventory of XML objects and connector types is the best input for an estimate. Ask for a schedule in the written scope that ties each phase to a deliverable, and confirm how the parallel run is planned around your next audit cycle.

What does the migration need from our own team?

Expect to provide people who know the business meaning of your roles, the owners of each connected system, and the auditors or compliance leads who accept evidence from certifications. Engineers need access to the IdentityIQ console for XML exports, the target systems for connector testing, and a midPoint environment for the parallel run. Much of IdentityIQ's logic lives in rules and workflows that must be redesigned, not copied, so the people who understand approvals and exceptions are essential. Agree these responsibilities in writing before the project starts.

Can our internal staff migrate from IdentityIQ to midPoint without outside help?

Internal staff can do the work if they have Java and integration skills, experience with directory and target system protocols, and time to rebuild role models and certification logic. midPoint is open source and its documentation is public, so there is no license barrier to learning it. The risk is capacity and audit credibility: the parallel run must produce evidence an auditor will accept, and connector and role errors surface during that period. Many teams mix internal ownership with an external partner for the highest-risk parts, such as role redesign and connector testing. Compare that mix against your own staffing in a written plan.

Does midPoint require a paid support subscription?

No. midPoint is open source, Evolveum states it has no enterprise edition, and it is dual-licensed under EUPL-1.2 and Apache 2.0 with no license fees. 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 Evolveum support page lists no prices, so request a quote. Whether you need a subscription depends on your in-house capacity, your uptime requirements and how much you rely on a vendor for bug fixes. Support from DeployOpen is a separate, scoped engagement and is available as a retainer.

Does midPoint cover role mining and access certifications?

midPoint covers role-based access control, auditing and role mining, and it supports certification campaigns. What it does not do is reproduce IdentityIQ's Compliance Manager workflows out of the box, so your certification definitions, stages, reviewer rules and remediation paths must be rebuilt and tested. Confirm with Evolveum the exact certification features in your target release, and run a trial campaign on representative data before relying on it for audit evidence.

What happens to our IdentityIQ 9.0 upgrade plans if we move to midPoint?

SailPoint announced IdentityIQ 9.0 on October 6, 2026 as the modernization path for hybrid and on-premises customers, and it includes an automated upgrade tool. Customers on older releases face a real project either way. If you move to midPoint, the 9.0 upgrade effort is avoided, but the rules, workflows, connectors and testing work still has to be done. Compare both paths in writing: the upgrade scope, the connectors you would keep, the redesign effort and the license decision, with a date for when the current license expires.

What changes in licensing when we exit IdentityIQ?

Exiting IdentityIQ ends the SailPoint subscription and module licenses you pay for, while midPoint carries no license fees. You still pay for infrastructure, staff, connector work and any support subscription you choose. Check your SailPoint contract for notice periods, renewal dates and data return terms, and confirm what XML exports and configuration you are entitled to keep. Ask SailPoint for a written statement of those terms before you plan the cutover.

How DeployOpen works on this

DeployOpen plans and implements the move from IdentityIQ to self-hosted midPoint inside your own infrastructure, from the XML export inventory through connector rebuilds, certification translation and a parallel run. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How we scope

Inventory every IdentityIQ rule, workflow, role, application and certification definition exported from your environment
Agree in writing which objects are ported, redesigned or retired, and which connectors need rebuilding on ConnId
Define the parallel-run period and audit evidence you need, then fix scope, deliverables and timeline before work starts

How we build

Rebuild connectors for each source and target system and test provisioning and deprovisioning against non-production data
Translate certification campaigns, reviewer rules and role models into midPoint definitions, with each mapping documented
Deploy midPoint in your cloud account, data center or air-gapped network, with PostgreSQL and backups configured to your standards

How we hand over

Deliver runbooks for operations, connector maintenance, role change requests and certification cycles
Document the parallel-run results, reconciliation reports and control evidence that your auditors will ask to see
Train your administrators on midPoint so your team can operate the platform after the engagement closes

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after go-live
Plan midPoint upgrades against the release dates on the official release page, confirming support windows for your chosen version
Coordinate with Evolveum support subscriptions where you choose to add vendor product support to your DeployOpen engagement

Migrate from SailPoint IdentityIQ to midPoint