Oracle Identity Governance vs midPoint

Oracle Identity Governance alternative: when midPoint fits and when OIG still does

Most teams reach this question through a renewal notice, a support price change, a WebLogic or SOA Suite upgrade that lands on the roadmap, or a data residency or lock-in concern from risk or audit. Oracle Identity Governance fits when the organization already runs an Oracle estate, has in-house WebLogic and SOA Suite administrators, depends on Oracle-specific connectors and has workflows built on SOA that business owners rely on. In that case the cost of replacing working processes can outweigh the license spend. midPoint fits when the team wants no license fee, is comfortable operating Java services on a PostgreSQL repository, and prefers open source with optional paid support from Evolveum, which sells subscriptions rather than licenses.

The decision turns on three things. First, certification and segregation of duties: list the review campaigns, role conflict rules and attestation evidence your auditors expect, then confirm with Evolveum which of these midPoint covers natively and which need custom development in your own environment. Second, connector coverage: inventory every target system and check each against the ConnId connectors documented for midPoint, marking which are supported, community or experimental, and which would need a custom connector. Third, staffing: be honest about whether you can hire or retain people for Java, PostgreSQL and midPoint configuration, or whether you will need a partner for the migration and the first year of operation. A short proof of concept against two or three of your hardest connectors will answer more than any feature comparison.

Which platform fits which scenario

This table maps common buyer situations to the platform that usually fits better and the condition that decides it. Read each row against your own inventory of connectors, middleware and upgrade deadlines, because the right answer depends on what you run today and what your team can operate.

Scenario	Better fit	Condition that drives the choice
Renewal under review with no upgrade planned	midPoint, if the goal is to stop paying license and support fees	Confirm how many Oracle licenses and support lines you pay for, and whether the team can own a Java and PostgreSQL stack after cutover
Planned move from 12.2.1.4 to 14c	Decide before committing: midPoint if you can accept a migration project, OIG 14c if the existing processes must stay unchanged	The 14c path needs a new middleware home, JDK 17, schema upgrade and an irreversible domain reconfiguration, so compare that effort with a re-implementation
Move off WebLogic and SOA Suite	midPoint, since it runs on Java with PostgreSQL and needs no WebLogic or SOA Suite	Your approval workflows and custom plugins must be ported to midPoint's own workflow model, which is a rewrite rather than a configuration change
Heavy reliance on Oracle-specific connectors	Depends on the target: midPoint for LDAP, Active Directory, databases, SCIM and Entra ID, custom ConnId work for the rest	List every connector you use and check it against the documented ConnId catalog, where support status ranges from supported to community and experimental
Open-source mandate from the board or regulator	midPoint, which is open source under EUPL-1.2 and Apache 2.0 with no enterprise edition	Confirm with Evolveum which features you need are in the open-source code and which depend on a subscription or consulting
Need for certification and segregation of duties	Verify before choosing: midPoint covers auditing, role mining and simulations, but you must confirm the certification and SoD depth your reviewers need	Ask for a feature walkthrough against your own certification campaigns and SoD rules, using production-like data
Team with no SOA Suite experience	midPoint, because the Java and PostgreSQL stack is more common in typical operations teams	Staff need Java and PostgreSQL skills, plus knowledge of midPoint's own object model, which must be learned before any migration
Need to keep Oracle Database as the repository	Oracle Identity Governance, since midPoint's native repository is PostgreSQL	Your data residency or DBA standards may require a specific database platform, so confirm this before you start a migration
Access management or SSO must also be replaced	Neither product alone: midPoint is identity management and does not implement the server side of OAuth2, OpenID Connect or SAML	Pair midPoint with a separate SSO platform, and plan how the two integrate

Where the capabilities differ and what to confirm

The fastest way to avoid a bad migration decision is to treat provisioning and deprovisioning, request and approval workflows, certification campaigns and segregation of duties as proof of concept tests rather than settled claims. midPoint's documented coverage includes provisioning and deprovisioning, identity lifecycle, role-based access control, auditing, self-service access requests and password reset, simulations against production data, and role mining. Those capabilities map to much of what your OIG deployment does day to day, but coverage on a feature list does not show that your specific approval chains, role model or attestation rules will behave the same way. Take a representative sample of your OIG workflows and rebuild them in a test midPoint instance before you commit.

Certification and segregation of duties deserve the most scrutiny. Compare how your current certification campaigns are scoped, who reviews what, how revocations flow back to target systems, and how separation-of-duty rules are defined and enforced at request time and during reviews. Then check each of those behaviors against the midPoint documentation and against a proof of concept run with your own roles and entitlements. Ask Evolveum directly, through the midPoint support subscriptions channel or your implementation partner, which of these behaviors are product features and which would need custom development, and record the answer in writing.

Finally, midPoint is an identity management system, not an access management or SSO server. It does not implement the server side of OAuth2, OpenID Connect or SAML, so the applications that OIG currently protects through federation or SSO will still need an SSO platform after the move. Confirm which of your applications rely on OIG for sign-on rather than only for account provisioning, and plan the SSO layer as a separate workstream with its own owner, test cases and cutover date.

Capability comparison from supplied facts

This table compares Oracle Identity Governance with midPoint on the points where published facts are available, and marks the cells that need confirmation with Oracle. Read the midPoint column as documented by Evolveum and the Oracle column as a checklist of questions to take to your Oracle account team and your own architects. The main takeaway is that licensing, connector coverage and support terms should be verified against current Oracle material before any decision is made.

Capability	Oracle Identity Governance	midPoint
Licensing	Commercial license with annual support. Confirm current license metrics and support terms with Oracle.	Dual-licensed under EUPL-1.2 and Apache 2.0 with no license fees, per Evolveum.
Source availability	Proprietary product. Source code is not publicly available.	Repository published on GitHub. Evolveum states there is no enterprise edition and no open core split.
Provisioning connectors	Connector catalog delivered through Oracle and partners. Confirm which connectors are current for your targets and their support status.	ConnId framework with documented connectors for LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID, SCIM2 and SCIMv1, plus an integration catalog.
Connector maturity labels	Confirm with Oracle how each connector is supported and certified for your versions.	Catalog status ranges from supported to community and experimental. Check each connector before relying on it.
Scale claims	Confirm supported identity volumes and topology limits for your version with Oracle.	Evolveum states midPoint scales to deployments of up to 100 million identities.
Release support windows	Confirm the support end dates for your OIG release and any upgrade path with Oracle.	midPoint 4.8 (Curie) LTS supported until October 17, 2028. midPoint 4.10 (Braille) supported until November 26, 2027. Source: midPoint release documentation.
Runtime	Oracle WebLogic and SOA Suite with an Oracle Database. Confirm current component and JDK requirements with Oracle.	Java (Java 21 for 4.10 and older, Java 25 recommended for 4.11 and later) with PostgreSQL as the native repository database.
Single sign-on scope	Confirm which access and SSO capabilities are included in your OIG deployment and which are separate Oracle products.	Identity management only. midPoint does not implement the server side of OAuth2, OpenID Connect or SAML, so SSO is a separate component.

How provisioning and reconciliation compare in practice

Provisioning, reconciliation, connectors and role modeling are where an OIG to midPoint move succeeds or stalls. The cards below name the decisions each area forces and the checks worth running in a pilot before any production cutover.

Provisioning and deprovisioning

midPoint drives account creation, attribute changes and removal from resource definitions, with lifecycle states on the identity deciding what happens when someone joins, moves or leaves. The key check is whether your joiner, mover and leaver rules map cleanly onto midPoint's lifecycle model, including how disabled versus deleted accounts are handled on each target. Document every OIG event handler or custom adapter you rely on today, because each one needs an explicit midPoint equivalent. Run a leaver scenario end to end against a non-production target and confirm the audit trail records each step.

Reconciliation against target systems

Reconciliation finds drift between midPoint's view of an account and what the target actually holds, which matters most where administrators have changed accounts directly. Plan how often reconciliation runs, how it is scheduled across nodes in a multi-node deployment, and how corrective actions are approved. Pick the largest target and measure how long a full reconciliation takes against your production volumes, since this shapes your maintenance window. Confirm that discrepancy reports reach the people who own each system, not only the IGA team.

Connector coverage and status

midPoint connects through the ConnId framework, where each connector is Java code that speaks one target protocol. Documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID, SCIM2 and SCIMv1. Connector status ranges from supported to community and experimental, so treat that label as a contract question, not a footnote. Inventory every OIG connector in use, including Oracle-specific ones, and mark each as supported, community or needing custom work. Test the community and experimental connectors against your target versions before you commit scope.

Custom connector development

Where no connector exists, the work is Java development against the ConnId interface, plus testing, packaging and ongoing maintenance when the target's API changes. This is the cost that most often surprises teams moving from a product with a large packaged connector library. Ask whether the target has a standard protocol such as SCIM or LDAP that a supported connector already covers, since that avoids custom code. For any connector you must write, scope the build, test harness and handover in writing before the pilot starts, and agree who maintains it after go-live.

Role and entitlement modeling

midPoint expresses access through roles, organizational structure and assignments, and its role mining and simulation features help you test a model against production data before enforcement. Oracle deployments often carry roles built around OIG's own entitlement objects, so the mapping is rarely one to one. Run a role mining or simulation exercise on a copy of real assignments to see which roles are redundant, overlapping or missing. Confirm with business owners that the proposed roles reflect actual job functions before any automated provisioning uses them.

Running both systems in parallel

A pilot should run midPoint and OIG against the same targets for a defined period, comparing the accounts each one creates, changes and removes. Parallel running exposes differences in attribute mapping, timing and error handling that a design review will miss. Agree in advance which system is authoritative for each target during the overlap, and who signs off each discrepancy. Record every difference with its cause, because that log becomes the evidence base for retiring WebLogic and SOA Suite.

What each platform needs to run

Oracle Identity Governance runs as a set of Oracle middleware components. WebLogic Server hosts the OIG managed servers and administration server, SOA Suite runs the workflow and approval processes that many request and certification flows depend on, and Oracle Database holds the OIG schema and audit data. Each component has its own installation, patching and compatibility rules, so the stack is usually planned as one unit.

WebLogic Server domain: needs its own domain configuration, node manager and clustering decisions, all of which must be documented and backed up.
SOA Suite: must be installed and patched in step with OIG, because workflow changes can affect request and approval behavior.
Oracle Database: the DBA team owns backup, high availability and patch windows for the OIG schema and the SOA schemas.
JDK requirements: set by the Oracle release you run. Confirm the JDK version and patch level in Oracle's current compatibility documentation before you size hardware, because newer middleware releases often change this requirement.
Middleware skills: administering WebLogic, SOA Suite and Oracle Database together is a specialist skill set. Staff with it are often the largest recurring operating cost.

Confirm the exact component versions, supported operating systems and JDK requirements in Oracle's documentation for your release, and list every licensed component on the same inventory so that the infrastructure and licensing views match.

Data location, hosting and compliance implications

Identity and audit data, hosting placement and compliance evidence determine how much work a migration creates in a regulated environment. Both products run in infrastructure the client controls, so the questions are where each copy of data sits, which components run it and who must show that the controls work.

Identity and audit data location

In Oracle Identity Governance, identity records, account links, request history and audit tables sit in the Oracle Database schemas the product uses, while WebLogic and SOA Suite hold workflow state and logs in their own locations. In midPoint, the native repository is PostgreSQL, which Evolveum recommends running on a separate database server. For either product, confirm where audit trails, workflow payloads, connector logs and backups are written, who can read them and how long each copy is kept. Map every copy against your data residency rules before you choose a placement.

Self-managed hosting choices

Both products are self-managed, so the client chooses the placement: virtual machines, containers or physical servers in its own data center or air-gapped network. midPoint runs on Linux in a virtual machine or from Docker images. Multi-node deployments need a sticky HTTP load balancer, a shared central database, cache invalidation between nodes over HTTPS and Quartz for distributed task scheduling. The Oracle stack requires WebLogic domains, SOA Suite and Oracle Database to be placed and patched together, which changes how many components your operations team carries. Ask each vendor for its supported platform matrix before you size hardware.

Compliance evidence and assessor scope

Auditors judge controls, but the evidence has to come from your systems. DeployOpen prepares controls, configurations and evidence for compliance assessments, including access review records, provisioning logs and change history. DeployOpen does not issue audit reports, attestations or certifications: independent auditors and certification bodies do that work. Before a migration, agree with your assessor which evidence comes from the old system, which comes from midPoint and how long both must run in parallel. Do not assume a product's certification carries over to your deployment. Confirm any certification claim for either product directly with its vendor.

Vendor dependence and support terms

midPoint is licensed under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states that it has no enterprise edition, so the code remains available to your own maintenance team. Support is optional: Evolveum sells Product Support subscriptions with an 8x5 next-business-day or 24x7 SLA, plus Platform Subscriptions that add feature development. Oracle Identity Governance depends on Oracle licenses, support renewals and the middleware versions Oracle supports. Ask each vendor what happens to your data, configuration and upgrade path if you stop renewing.

What drives the cost of each option

On the Oracle side, the largest recurring items are the Oracle license and annual support fees for Oracle Identity Governance, plus the WebLogic and SOA Suite licenses and the Oracle Database that hosts the schemas. Each has its own support line, so ask the vendor for a full list of processors or named metrics, the support renewal date and what each product's annual fee covers. Specialist staff are a recurring cost too: administrators who know WebLogic domains, SOA composites and OIG connector configuration are scarce, and their time shows up in every patch cycle. One-time costs include any upgrade project, such as the move to 14c described on a sibling page, and the effort to document current workflows and resources. Confirm your actual Oracle contract terms with your Oracle account team and your procurement records, because public references do not give your negotiated figures.

On the midPoint side, the software carries no license fee, so the cost sits in infrastructure, people and optional services. Infrastructure covers the application nodes on Linux virtual machines or Docker, a separate PostgreSQL server (which midPoint recommends running on its own database server), load balancing for multi-node deployments, and non-production environments for testing connectors. Evolveum's support subscriptions page describes Product Support with an 8x5 next-business-day or 24x7 SLA and Platform Subscriptions that add feature development and roadmap influence, but it lists no prices, so the subscription is a quoted, recurring line you choose to add or omit. The migration itself is largely one-time: connector mapping, reconciliation runs, porting approval processes, parallel running and retiring WebLogic and SOA Suite. Its effort depends on how many resources, roles and custom workflows you have. DeployOpen does not publish a price list; its fees follow from a written, fixed scope.

When you request quotes, separate one-time from recurring lines for each option and ask each party to state its assumptions. For Oracle, ask for the license and support fees by product, the renewal terms, and the cost of any required middleware or database upgrades. For midPoint, ask Evolveum whether a Product Support or Platform Subscription is recommended for your environment and what it includes, and ask any implementation partner for a written scope listing connectors, workflows, environments and cutover support. Ask every party to state the same count of identities, applications and approval flows, since that count drives connector work and reconciliation effort more than anything else. Also plan for the midPoint release calendar: check the releases page to choose a long-term support line, and budget for the upgrade cycle that follows.

What moving from Oracle Identity Governance to midPoint involves

The sequence moves configuration, connectors and approval logic from WebLogic and SOA Suite into midPoint, then proves the new platform against the same targets before OIG is switched off. The detailed procedure sits in the migration guide, and the effort depends mostly on how many connectors and custom workflows the current deployment carries.

Inventory resources, roles, workflows and connectors
Start by listing every connected target system, every role or entitlement model, every approval workflow and every custom Java plug-in or SOA composite that OIG depends on. Confirm which targets are business-critical, which are read-only feeds and which are scheduled reconciliations that nobody has reviewed in a long time. Export the OIG configuration to understand the resources and workflows, as described in the export guide, and record the owners of each item. The step is done when the inventory has one row per resource, role and workflow, with an owner and a status for each.
Map connectors to ConnId equivalents and gaps
For each resource in the inventory, identify whether midPoint has a documented ConnId connector for the target, such as LDAP, Active Directory, SCIM2, Microsoft Entra ID or database connectors, and whether that connector is supported, community or experimental. Where no connector exists, decide between writing a ConnId connector, using a generic connector such as CSV or scripted SQL, or keeping that target on a separate integration path. Confirm connector versions and status with Evolveum before you commit. The step is done when every resource has a named connector or a documented gap with a decision.
Port approval and certification processes
Translate OIG request, approval and certification logic into midPoint's workflow and access request configuration. Map each approval stage to an approver rule, document where OIG used custom logic that must be rebuilt, and check the certification campaigns and segregation of duties rules that auditors rely on. Confirm with your compliance team which evidence each campaign must produce, because midPoint's reports and audit records need to match it. The step is done when each approval path and certification campaign has a midPoint equivalent that the compliance owner has reviewed.
Run both platforms against the same targets
Connect midPoint to the same target systems while OIG stays in production, and run it in simulation or read-only mode first so that the proposed changes can be compared with what OIG does. Use midPoint's simulation capability on production-like data to find differences in account state, role assignments and naming. Keep the two platforms in agreement by reviewing discrepancy reports for each resource. The step is done when the discrepancy rate for each resource is understood and every remaining difference has an explanation or a fix.
Reconcile identities and cut over
Run reconciliation in midPoint against each target, compare the resulting accounts and entitlements with the OIG records, and resolve orphaned accounts, duplicate identities and correlation mismatches before any target changes ownership. Schedule the cutover resource by resource, with a rollback path for each, and move provisioning authority to midPoint only after the owners sign off. The step is done when every resource is managed by midPoint, reconciliation reports are clean or explained, and the owners have accepted the change in writing.
Retire WebLogic and SOA Suite
Once no workflow, connector or scheduled job depends on OIG, stop the OIG managed servers, archive the WebLogic domain, SOA composites and database schemas according to your retention policy, and remove the related access and backup jobs. Confirm with your auditors which OIG audit and certification history must remain readable, and keep an export of it in a form they can use. The step is done when the OIG components are stopped, the archive is verified and the retention decision is recorded.

What does moving from Oracle Identity Governance cost in effort?

What drives the effort of moving from Oracle Identity Governance to midPoint?

Effort is driven mostly by how much identity logic has to be rebuilt, not by the software itself. The main drivers are the number of connected target systems, how many custom connectors or adapters exist in OIG, how many approval workflows and certification campaigns must be reproduced, the quality of identity and role data, and how many separate environments (test, staging, production) need parallel running. Ask for an inventory of resources, roles, policies and workflows before you compare any quote, because an accurate inventory is what makes a written scope possible.

Can our team migrate from Oracle Identity Governance without outside help?

A team with strong Java, PostgreSQL and identity administration skills can run the work in-house, especially for a small number of standard targets such as LDAP, Active Directory or database tables. Teams with many custom connectors, complex SOA-based approval flows or regulated audit requirements often choose to add outside help for the design and cutover phases. Assess your skills honestly, then decide which phases you want to keep internal.

What skills and data does a midPoint migration require from our staff?

The work needs people who understand the following areas:

Java, because midPoint and its connectors are Java code, and the ConnId framework is the integration model you will work with.
PostgreSQL, because it is midPoint's native repository database and should ideally run on a separate database server.
Identity data and connector knowledge, meaning who owns each source of truth, how accounts are correlated, and how each target system's protocol behaves.
Governance knowledge, covering the approval and certification rules you must keep.

Confirm these skills in your own team before you start the migration.

How long does a migration from Oracle Identity Governance take?

No timeline is supplied for this migration, and any figure given without a written scope would be guesswork. Duration depends on the number of targets, the complexity of workflows and certifications, the amount of parallel running you require, and how quickly your owners can validate data. Request a written scope that breaks the work into phases with deliverables and dates agreed before work begins, and ask any vendor to show the assumptions behind their schedule.

Does the midPoint open-source license have any fees?

midPoint has no license fee. It is dual-licensed under the EUPL-1.2 and Apache 2.0, and Evolveum states that it has no enterprise edition, so every line of midPoint code is published under open source licenses. The costs that remain are infrastructure, such as servers, PostgreSQL and backups, and people, such as the staff or partners who plan and run the system. Confirm with your legal team how the EUPL applies to any modifications you plan to make.

When is an Evolveum subscription worth considering for midPoint?

An Evolveum subscription is optional. 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. Consider a support subscription when your operations team needs a contractual path for defect resolution, and a platform subscription when you need features that matter to your roadmap. The Evolveum page lists no prices, so request the current terms directly from Evolveum.

Can midPoint replace Oracle's access management and single sign-on?

No. midPoint is an identity management system, not an access management or SSO server, and it does not implement the server side of OAuth2, OpenID Connect or SAML. If your Oracle estate uses access management for SSO, you need a separate identity provider for that function. midPoint's own user interface can authenticate against external SSO services. Map each Oracle component you use to a replacement before you define the project scope.

How DeployOpen helps evaluate, implement or migrate midPoint

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including midPoint. We start with a written scope that covers your connectors, workflows and evidence needs, then build and hand over the platform so your team can run it.

How we scope

Inventory the Oracle Identity Governance resources, connected targets, roles and approval workflows that midPoint must cover
Agree which certification and segregation of duties evidence your auditors expect, and which parts need confirmation with them
Define deliverables, timelines and responsibilities in writing before work starts, since most engagements are fixed-scope

How we build

Deploy midPoint on Java and PostgreSQL in your cloud accounts, data centers or air-gapped network, with a separate database server
Map each target system to a ConnId connector and test provisioning and reconciliation against non-production copies first
Run security testing of the applications and APIs in scope, and document configuration changes as the build progresses

How we hand over

Deliver architecture, configuration and runbook documentation so your team can operate midPoint without us
Train administrators on role design, request and approval flows, and reconciliation review, using the agreed scope
Document the controls and evidence that compliance assessors will review, while independent auditors issue any audit conclusions

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover
Plan upgrades against midPoint release dates and Java version requirements, confirmed with Evolveum before each change
Keep backup and recovery procedures for the midPoint database and configuration under your control and tested