What an IdentityIQ 9.0 upgrade or a midPoint move actually changes
If your IdentityIQ renewal is due or you run an older release that now needs the 9.0 upgrade, the decision in front of you is between staying on IdentityIQ through a 9.0 project and moving governance to midPoint, which is open source with no license fees. Both paths start from the same inventory. You need to know every rule, workflow, application definition, connector, certification campaign and test case the platform carries today, because a 9.0 upgrade and a midPoint migration both depend on that list. The license decision is one line in a much longer scope.
Start the inventory with the objects that encode your business logic: custom rules, workflows, provisioning policies, identity and certification schedules, and the role model with its entitlements. Confirm with SailPoint which of these an automated 9.0 upgrade carries forward unchanged and which need manual rework. For a midPoint move, the same objects must be redesigned as midPoint objects, and the connectors behind each application must be mapped to ConnId. Ask each vendor for the assumptions behind any effort figure they give you, and check them against your own object counts.
midPoint is developed by Evolveum under the EUPL-1.2, with Apache 2.0 as a secondary license, and Evolveum funds development through support subscriptions, training and professional services. Those subscriptions and consulting fees are the recurring costs you would budget on the midPoint side, alongside your own platform staff. Ask Evolveum or an implementation partner for a written scope before you commit, and confirm which support tier matches your change windows and audit calendar.
What the decision has to cover before any option is chosen
Whether you upgrade to IdentityIQ 9.0 or move to midPoint, the same inventory applies. Each area below is something to pull from the current IdentityIQ environment before estimating effort, because it determines what is carried over, what is rebuilt and what must keep running during the change.
Custom rules and workflows
Export the custom rules, workflows, provisioning policies and forms your team has written over the years, and sort them by business purpose. Under an upgrade these mostly stay in place, but they must be retested against 9.0. Under a move, each one has to be redesigned as midPoint expressions, object templates or policies, because IdentityIQ BeanShell logic does not port line for line. Count how many rules touch joiner, mover and leaver events, since those carry the most audit risk.
Application and connector coverage
List every connected application, its connector type and its owner, and note any custom or unsupported connectors. For a move, check each target against the ConnId catalog: LDAP, Active Directory, CSV, database tables, Microsoft Entra ID and SCIM are documented, while other systems may only have community or experimental connectors. Those gaps set the real migration scope and should be confirmed with Evolveum or a partner before any commitment.
Certification campaigns and role models
Inventory active and scheduled certification campaigns, reviewer assignments, remediation rules and the role and business role model that drives them. Upgrading keeps this data in IdentityIQ, while a move requires mapping campaigns to midPoint certification definitions and rebuilding role structures. midPoint offers role mining and simulations against production data, which can help test a new role model before cutover, but the mapping still needs an owner who understands your entitlements.
Parallel running and audit evidence
Decide which audit evidence must survive the change, including past certification decisions, approval records and provisioning logs. Plan a period in which both systems run, and define how their outputs are compared, such as access counts per application or reviewer decisions per campaign. Ask your auditors which artifacts they will accept as evidence from each platform before the cutover date is set.
License and support position
Read your current IdentityIQ agreement for term, renewal date, module scope and any upgrade entitlements, and identify which modules you actually use. On the midPoint side there is no license fee, but Evolveum sells optional Product Support and Platform Subscriptions with stated SLA tiers, and those, along with hosting, operations staff and partner work, are the recurring costs to compare. Confirm the midPoint release you would target, since support windows differ by release.
How the IdentityIQ 9.0 upgrade scope compares with a midPoint move
An IdentityIQ 9.0 upgrade keeps the product's object model and modules, including Compliance Manager, Lifecycle Manager, Password Manager and File Access Manager, and carries existing customizations forward. The key question is which of your customizations SailPoint's upgrade tool migrates automatically and which need manual rework. The supplied material does not describe that tooling in detail, so ask SailPoint in writing for the list of supported object types, the customization types that fall outside automated migration, and the test environment expected for validation. Inventory your rules, workflows, custom forms, applications and any Java or BeanShell logic first, so you can sort each item into one of those two groups before the upgrade is scoped.
A midPoint move keeps the business intent but rebuilds the implementation. Roles, approval steps and certification rules are carried over as decisions, then expressed as midPoint objects such as roles, policy rules, certification definitions and tasks, and connected through ConnId connectors instead of IdentityIQ connectors. Custom Java and BeanShell-style logic cannot be copied directly, so each rule needs a redesign and a test case that proves the outcome matches the original. Treat the rebuild as a design exercise with named owners for each approval and certification flow, not as a file conversion. Note that IdentityIQ's own XML export gives you the configuration to study, but the migrated logic still has to be written again for midPoint.
Plan the two paths against the same checklist: every rule, workflow and connector in scope, the test evidence each one needs, and the audit period that must show consistent results. An upgrade may leave the business logic intact while still requiring retesting of each customization. A midPoint move adds connector development, role model work and a parallel run before the old platform is retired. Ask your SailPoint account team and any implementation partner for a written scope that names each object type and the effort assigned to it, and compare that with an inventory-based estimate for midPoint before you commit to either route.
Which option fits which constraint: upgrade, move or narrow scope
This table compares four paths for a customer on an older IdentityIQ release: finish the 9.0 upgrade, move governance to midPoint on either the feature or long-term support line, or narrow the open-source footprint to provisioning with Apache Syncope. Read each row against your audit calendar, your Java and ConnId skills, and how much SailPoint-style certification and role mining you must keep.
| Option | How it meets the need | Trade-offs |
|---|---|---|
| Stay on IdentityIQ and complete the 9.0 upgrade | Keeps existing rules, workflows, connectors and certification campaigns in the same product, with the upgrade delivered as SailPoint's modernization path for hybrid and on-premises customers. | Continues the SailPoint subscription and its module licensing. Depends on SailPoint's upgrade tooling and on the timeline you agree with the vendor. Confirm current support terms in writing. |
| Move governance to midPoint 4.10 (Braille) | Gives a self-hosted, EUPL and Apache 2.0 platform with provisioning, lifecycle, RBAC, auditing, access requests and role mining. Feature release supported until November 26, 2027. | Shorter support horizon than the long-term line, so expect an earlier upgrade. Requires Java 21 and PostgreSQL skills in house or through a partner, plus ConnId connector work for each target system. |
| Move governance to midPoint 4.8 (Curie) | Long-term support release supported until October 17, 2028, which gives the longest fixed window for a migration project and parallel audit cycles. | Runs on the older Java 17 and 21 requirement set, so confirm the platform baseline before you commit. Connector and rule porting effort is the same as for 4.10. Confirm support terms with Evolveum. |
| Use Apache Syncope for provisioning only, with certification and role mining handled elsewhere | Covers account provisioning, self-service and ConnId connectors under Apache 2.0, which suits a narrower scope than full IGA. | Syncope does not provide SailPoint-style certification campaigns or role mining, so those functions need a separate tool or a manual process. Splitting the stack adds integration and audit evidence work. |
Which midPoint release fits a long-term governance program
midPoint 4.8 (Curie) is the long-term support release in the current line. Its support runs until 17 October 2028, which gives a governance program a long fixed window to plan around. Teams that run audits on a fixed cycle and want fewer platform changes during that cycle usually look here first.
- Support end: Support for 4.8 (Curie) ends on 17 October 2028, according to the midPoint releases page.
- Java: Java 21 is recommended for 4.10 and older, with Java 17 supported, so confirm your JDK package before installing.
- Repository: midPoint uses PostgreSQL as its native repository database, ideally on a separate database server.
- Upgrade rhythm: A long-term track suits programs that schedule one major platform upgrade in the middle of a multi-year window rather than every feature cycle.
- Planning check: Ask Evolveum whether security fixes for the LTS line are delivered in patch releases and how they are scheduled.
Before choosing this track, check the midPoint releases page for the current support table, since dates can change. Confirm the Java and PostgreSQL versions your operations team supports today.
midPoint 4.10 (Braille) is the latest feature release listed for the project. It is supported until 26 November 2027, a shorter window than the long-term track. It suits teams that want newer functionality during a migration and can plan a further upgrade before the support end date.
- Support end: Support for 4.10 (Braille) ends on 26 November 2027, according to the midPoint releases page.
- Java: Java 21 is recommended for 4.10 and older, with Java 17 supported.
- Repository: PostgreSQL is the native repository database, ideally hosted on a separate server from the midPoint nodes.
- Upgrade rhythm: A feature track means at least one more upgrade before the support end, so budget that work into the program plan.
- Planning check: Confirm with your IdentityIQ migration team whether any feature you depend on is specific to this release.
A migration that starts now may land on this track and then need a second upgrade within about a year and a half. Verify the current status on the midPoint releases page before you commit.
midPoint 4.11 (Čapek) is a feature release planned for 21 October 2026, according to the midPoint releases page. Because it is a planned date, confirm the release has shipped and check its support window before you base a deployment on it. It also moves the recommended Java version up.
- Planned date: 21 October 2026 is the planned release date listed on the midPoint releases page.
- Java: Java 25 is recommended for 4.11 and later, with Java 21 supported, so test your runtime image on Java 25 early.
- Repository: PostgreSQL remains the native repository database, so plan the database server version alongside the JDK change.
- Upgrade rhythm: Teams that prefer to adopt new features promptly and can run a regular upgrade cycle may find this track fits.
- Planning check: Ask whether your ConnId connectors and any custom Java code build and run on Java 25 before adopting this line.
Wait for the release to be published and reviewed before you fix a production version. Check the midPoint releases page for the final support dates and requirements.
How to run midPoint in parallel through an IdentityIQ audit cycle
This sequence moves IdentityIQ scope into midPoint in stages while both systems run against the same identities, so the team can compare results through a full audit cycle before cutting over. Each step names what your team supplies and what proves the step is complete.
Inventory IdentityIQ objects as XML exports
Your IdentityIQ administrators export roles, applications, workflows, rules, certification definitions and identity data as XML using the console export command, and they keep the export under version control with a dated snapshot. Your security or compliance lead marks each object as copy, redesign or retire, because rules and workflows written in IdentityIQ's own constructs rarely translate line for line. The step is complete when every object in scope has a recorded disposition and a named owner, and the exports can be re-read by someone outside the original build team.
Install midPoint on Linux or Docker
Your platform team installs midPoint on a Linux virtual machine or from Docker images in a non-production environment, using the Java version that matches the release you chose (midPoint recommends Java 25 for 4.11 and later, and Java 21 for 4.10 and older). Confirm the release choice against the midPoint releases page first, since 4.8 is the long-term support line and 4.10 is the latest feature release. The step is complete when the web interface starts, an administrator can log in, and the version and Java runtime are recorded in your configuration baseline.
Set up PostgreSQL on a separate server
Your database team provisions a PostgreSQL server that is separate from the midPoint application host, with backups, encryption at rest and access limited to the midPoint service account, as your own policy requires. midPoint uses PostgreSQL as its native repository, so this server holds the identity model, audit records and task history. The step is complete when midPoint connects to the repository, a backup restore has been tested on a copy, and the database owner has signed off on retention settings.
Connect first target systems through ConnId
Your integration engineers configure the first connectors, typically the directory and HR-sourced systems in scope, choosing from documented ConnId connectors such as LDAP, Active Directory, CSV or Microsoft Entra ID, and check each connector's status in the integration catalog before relying on it. Your application owners supply service accounts, endpoint details and the attribute mappings they accept. The step is complete when read-only reconciliation returns account and entitlement counts for each target that match what IdentityIQ reports for the same systems.
Port a first set of roles and certifications
Your identity architects rebuild a limited set of roles and one certification definition in midPoint, starting with the population that auditors ask about most, and they document each rule that was replaced by a mapping, policy or workflow. Compliance owners review the reviewer assignments and remediation paths before anything runs. The step is complete when the ported roles produce the same membership as the IdentityIQ roles for the agreed population, and the differences are logged and approved.
Run both systems against the same identities
Your operations team keeps IdentityIQ as the system of record for the audit scope while midPoint runs in simulation or reporting mode against the same identities, and a designated analyst compares access decisions, certification outcomes and provisioning actions every cycle. Discrepancies go into a tracked register with an owner and a resolution. The step is complete when the comparison has covered at least one full audit cycle as defined by your auditors and the open discrepancies are either fixed or accepted in writing.
Add nodes for multi-node layouts if required
If your availability or load requirements call for more than one midPoint node, your platform team places a sticky HTTP load balancer in front of the nodes, points all nodes at the same central PostgreSQL database, and confirms that cache invalidation between nodes runs over HTTPS. Task scheduling uses Quartz across the cluster, so your team tests failover of scheduled reconciliation jobs explicitly. The step is complete when a node restart leaves certifications and reconciliations running without duplicate execution, as shown in the test log.
Cut over after the audit cycle closes
Once the audit cycle is complete and your auditors have accepted the parallel evidence, your team switches provisioning and certification ownership to midPoint, freezes IdentityIQ changes, and keeps the read-only IdentityIQ environment for the retention period your policy defines. Your compliance lead confirms the cutover record and the evidence set with the independent auditor. The step is complete when the signed cutover record and retained IdentityIQ exports are filed together.
How the license decision changes the total cost of the move
The license decision removes one cost line on the midPoint side and leaves the SailPoint side open until you have a written number. midPoint has no license fees and no enterprise edition. Evolveum states that every line of midPoint code is published under open source licenses and that the project is open source, not open core. Evolveum funds development through subscriptions, training and professional services, so the recurring cost you will see is for support and services you choose to buy, not for the software itself. Those services are the ones to price against your own operating model.
Evolveum sells two subscription types. Product Support covers resolution of product bugs under either an 8x5 next-business-day or a 24x7 SLA. Platform Subscriptions add feature development and roadmap influence. The support subscriptions page lists no prices, so request quotes for each option in writing and confirm the SLA tier, the midPoint versions covered and what happens to coverage when a release leaves support, such as midPoint 4.9, whose support ends on October 18, 2026 according to the midPoint releases page. Ask whether the quote covers only the core product or also the connectors you plan to run.
The SailPoint side depends on three things: the renewal quote, the modules you actually use (Compliance Manager, Lifecycle Manager, Password Manager, File Access Manager), and any upgrade services needed for the move to IdentityIQ 9.0. Before you compare totals, request the full renewal and upgrade scope in writing, including which modules are priced, whether connector licensing is separate, and whether professional services for the upgrade are included or billed on time and materials. Compare the two sides over the same period and with the same scope, or the comparison will mostly reflect differences in what each quote includes.
What auditors ask for when governance moves platforms
A move from IdentityIQ 9.0 or a rebuild on midPoint changes where governance decisions are recorded, so the evidence trail has to survive the cutover. The cards below list what assurance teams usually request, and what to prepare before the parallel run starts. DeployOpen prepares systems and evidence, but independent auditors decide whether the controls meet the standard.
Role and entitlement models
Keep a dated export of the role model as it stood in IdentityIQ, with role definitions, entitlement mappings and the applications they bind to. Pair it with the midPoint role and assignment model that replaces it, and document every role that was merged, split or retired. Auditors will compare the two sets to confirm that no access was granted or dropped silently during the move. Ask whether the old model can still be read after the cutover.
Certification campaign records
Retain the completed IdentityIQ campaigns with reviewer identities, decisions, comments and timestamps. Map each campaign type to a midPoint certification definition, and record which reviewer rules and remediation actions carried over. Where a campaign is still open at cutover, decide in writing whether it finishes in IdentityIQ or restarts in midPoint, and keep both outcomes.
Change and approval logs
Collect the approval history for role changes, access requests and rule edits made in IdentityIQ, including who approved each change and when. Rules and workflows ported to midPoint need their own change records, showing the source version, the reviewer and the deployment date. Confirm that log retention in both systems meets your policy before the old instance is retired.
Parallel run test results
Record the results of the parallel run, comparing provisioning actions, access decisions and reconciliation output between IdentityIQ and midPoint for the same identities. Each difference needs an owner, a root cause and a disposition, whether it is a defect fixed or an accepted change. Keep the test scripts and their versions so the run can be repeated during audit fieldwork.
Access removal evidence for leavers
Show that leavers lost access on every connected system during the transition, both in IdentityIQ before retirement and in midPoint afterward. Gather deprovisioning tickets, connector logs and target-system confirmations for a sample of departures. Confirm with your assurance team how many leavers they will sample and which systems count as in scope.
What buyers ask before moving off IdentityIQ
Can our own team run an IdentityIQ to midPoint migration in-house?
Yes, a capable identity team can do it in-house, but the work needs more than IdentityIQ administration skills. Expect to need Java for reading and rewriting rules and custom code, hands-on experience with ConnId connectors, PostgreSQL administration for the midPoint repository, and identity data modeling to rebuild roles, policies and certification definitions in midPoint's model. midPoint's documentation and Evolveum's support subscriptions are useful backstops if a gap appears. Ask a partner to assess your skills against your actual rule and connector inventory before you commit to an in-house plan.
What makes the migration effort go up or down?
The effort tracks the amount of custom logic you have to rebuild, not the number of users. The main drivers are the count of custom rules and workflows, since each one is redesigned rather than copied across; the number of connectors, and whether each one has a ready ConnId equivalent or needs new code; the complexity of your certification campaigns, including stages, reviewer rules and remediation paths; and the number of authoritative identity sources and how cleanly they reconcile. Clean role models and a well-documented connector estate shorten the work considerably. Ask for an inventory of these items before any estimate is discussed.
How long will the IdentityIQ 9.0 upgrade or midPoint move take?
No duration is available for either path from the sources behind this page, so treat any timeline you receive with caution until it is tied to a written scope. The schedule is driven by the same factors as effort: custom rules and workflows, connector count, certification complexity and identity sources. A move to midPoint also adds time for running both systems in parallel through at least one audit cycle, which is often the longest phase. Ask any provider to split the timeline into discovery, build, parallel run and cutover so you can see where the dependencies sit.
What does the 9.0 upgrade cost compared with moving to midPoint?
The two paths have different cost components, and only some of them are recurring. For the IdentityIQ 9.0 upgrade, you pay SailPoint for licensing and any subscription renewals, your own or a partner's upgrade work, test environments, and infrastructure to host the platform. For midPoint, the software has no license fee, so the costs are infrastructure, migration and connector work, operations staff who run PostgreSQL and the midPoint nodes, and an optional Evolveum support subscription. Recurring costs are licensing or subscriptions and operations staffing; migration is largely one-time. Request each component as a separate line in any quote, with the assumptions behind it.
Can midPoint meet our audit needs for certifications and role mining?
midPoint covers certification and role mining functions, but whether it meets your audit requirements depends on your specific controls and evidence needs. Review how your current campaigns, reviewer rules and remediation paths map to midPoint certification definitions before deciding. The SailPoint vs midPoint comparison and the certification migration guide in this content group go through those mappings in more detail. Ask your auditor which evidence formats and retention they expect, and confirm the outcome with them in your own environment.
What should a written quote for this work include?
A useful quote lists the written scope before any price, so you can compare providers on equal terms. Ask for the inventory assumptions: the number of rules, workflows, applications, connectors and identity sources in scope. Require separate line items for discovery, rule and workflow redesign, ConnId connector work, testing, parallel run support, cutover, documentation and handover. Ask which items are one-time and which are retainers, what acceptance criteria apply to each deliverable, what is excluded, and how change requests are priced. For a midPoint path, also ask whether the quote includes or excludes an Evolveum subscription and the infrastructure you must provision.
What technical checks should engineers run before choosing a path?
Engineers should start with an export and inventory of IdentityIQ objects, then test the riskiest pieces in a non-production midPoint environment. Check how each custom rule and workflow behaves when rebuilt, confirm that every connector target has a supported or community ConnId connector with the protocol and version you need, and verify correlation and reconciliation against your authoritative sources. Plan for midPoint's own platform needs, including a supported Java version for the release you pick, PostgreSQL on a separate server, and the multi-node pattern if you need high availability. Use the results to decide between the 9.0 upgrade and the move.
How DeployOpen works on this
DeployOpen starts with a written scope that separates an IdentityIQ 9.0 upgrade from a move to midPoint, because the two carry different rules, connectors and audit evidence. The work then runs inside your own infrastructure, with testing and documentation that your auditors and identity team can review.
How we scope
- Inventory the IdentityIQ objects in use, including roles, rules, workflows, applications and certification definitions, before any target decision.
- Agree in writing whether the scope is an IdentityIQ 9.0 upgrade, a midPoint migration, or a staged path that runs both in parallel.
- Confirm with SailPoint and your own environment which modules, connectors and integrations are in use, since these drive the work.
How we build
- Rebuild connectors on the ConnId framework for each source and target system, testing each against a non-production copy of the data.
- Redesign rules and workflows as midPoint configuration rather than copying IdentityIQ logic line by line, and test each role model against real access patterns.
- Run simulations and reconciliation checks against production-like data, and record the results as evidence for the audit cycle.
How we hand over
- Document the midPoint configuration, connector setup, role model, certification definitions and operating runbooks in a form your team can maintain.
- Train the identity, operations and security staff who will own the platform after handover, and walk them through the audit evidence trail.
- Deliver the environment with backup, upgrade and rollback procedures written for your own data center or cloud account.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, so the platform keeps pace with midPoint releases.
- Confirm with DeployOpen which Evolveum support subscription level fits your operating model, since that choice is separate from the engagement.
