Should a 12.2.1.4 team upgrade Oracle Identity Governance to 14c or replace it?
A team on 12.2.1.4 facing the 14c project should know up front that 14c requires a new middleware home, JDK 17, a schema upgrade and an irreversible domain reconfiguration. The real choice is therefore between that project and a move to an open-source platform, most likely midPoint or Apache Syncope, rather than between two Oracle versions. Treat the upgrade as a migration of the whole stack, not a patch.
The short answer is this: midPoint is open source under EUPL-1.2 with Apache 2.0 as a secondary license, carries no license fee, and Evolveum sells support subscriptions only as an option. The decision then depends mostly on two things: whether you need Oracle-specific certification and segregation of duties features that you would have to rebuild or buy elsewhere, and how much of your current OIG customization sits in custom plug-ins and SOA workflows. Confirm both against your own inventory before you commit budget.
Before deciding, check Oracle's certification matrix and the 14c upgrade documentation for your exact 12.2.1.4 patch level, JDK and database versions, since supported paths and prerequisites change. Ask Oracle, in writing, which reconfiguration steps cannot be rolled back. Then ask Evolveum or a partner for a written scope covering connector coverage for your target systems, and compare that scope with the upgrade scope. Both paths carry effort, so the comparison should rest on the written scopes, not on license line items.
What the 14c move requires of a 12.2.1.4 estate
The 14c move runs four workstreams that all touch the same connectors, approval workflows and audit trail. Assign a named owner to each card before the project plan is baselined, because the domain reconfiguration depends on the other three being rehearsed first.
New middleware home
A 14c installation goes into a new Oracle home, so the 12.2.1.4 WebLogic and SOA Suite binaries are not patched in place. The platform team owns the directory layout, install media and host build for each node. Before cutover, confirm the supported WebLogic and SOA component versions in Oracle's upgrade documentation, then test every custom adapter, deployed composite, startup script and connector bundle against the new home.
JDK 17 runtime
The 14c stack requires JDK 17, so every JVM option, keystore format and bundled third-party jar needs review. The middleware team owns the JDK rollout on each node, and the security team checks TLS protocol and cipher defaults under the new runtime. Test connectors that ship older libraries, custom Java plug-ins and reconciliation jobs that call APIs removed between Java releases. Confirm the exact JDK build in Oracle's certification information before you order media.
Schema upgrade
The schema upgrade changes the OIG database objects that hold users, accounts, roles, request data and audit records, and it must run against a verified backup. The DBA owns the upgrade scripts, tablespace capacity and rollback point, while the IAM lead owns reconciliation counts taken before and after. Test that provisioning events still reach the audit tables, that pending approval requests survive the upgrade, and that scheduled reconciliations return matching counts on a copy of production data.
Irreversible domain reconfiguration
The domain reconfiguration is the point of no return, because the change cannot be reversed by undoing it inside the same domain. The platform owner signs off the go or no-go decision, and the change board records the backup and restore path. Before cutover, restore the 12.2.1.4 domain into a separate environment, rehearse the reconfiguration end to end, and confirm that connector endpoints, keystores and SOA composites resolve correctly afterward. Make the replace-or-upgrade decision before this step.
Why the irreversible domain step changes the decision
The reconfiguration of the WebLogic domain is the step that removes the option to go back, so it should be the point where the team decides between upgrading and replacing. Once the domain is reconfigured for 14c, the 12.2.1.4 domain and its managed servers cannot simply be restarted as they were. A rollback therefore means restoring from backup, not reversing a change. Before committing, confirm with Oracle or your implementation partner exactly which artifacts the reconfiguration rewrites (domain configuration, JDBC data sources, SOA and OIM partitions, deployment descriptors) and whether a documented downgrade path exists for your exact patch level.
A full backup is necessary but not sufficient. Take a consistent backup of the domain home, the middleware home, the OIM and SOA schemas in the Oracle Database, the keystores and the custom deployment artifacts, and then prove that a restore works on a separate host. Ask the vendor to confirm the supported backup method for the schema upgrade and whether RCU and schema changes are covered by the same restore point. Record the time the restore takes in your own environment, because that number, not a vendor estimate, is what your change window and rollback decision will depend on.
Connectors, scheduled reconciliation jobs and custom approval processes all bind to the current domain, so each one needs a rehearsal in a non-production copy of the domain and its database. Check that every connector bundle is certified against the 14c stack and the JDK 17 runtime, that scheduled reconciliation jobs resume and produce the same results after the upgrade, and that custom approval processes still run after the SOA composites are redeployed. Any gap found in the rehearsal is cheaper to resolve, or to resolve by choosing a different path, than after the domain has been reconfigured. Treat a failed rehearsal as a decision input, not a delay.
Which open-source options meet the same identity governance needs
This table compares staying on OIG through the 14c upgrade, self-hosted midPoint and Apache Syncope against the identity governance needs that drive the decision. Read the cells as a starting point for your own requirements list, since certification and segregation of duties depth must be verified against each option before you commit.
| Need | Stay on OIG through 14c | Self-hosted midPoint | Apache Syncope |
|---|---|---|---|
| Provisioning and reconciliation | Full provisioning and reconciliation through OIG's connector framework on the existing WebLogic and SOA Suite stack; confirm connector versions for each target after the upgrade. | Provisioning and deprovisioning through the ConnId framework, with LDAP, Active Directory, Microsoft Entra ID, SCIM2 and database connectors documented; confirm each target's connector status. | Provisioning across enterprise targets using ConnId connectors; a lighter model than midPoint, so confirm reconciliation behavior for your specific targets. |
| Role-based access control | Roles and entitlements managed within OIG; the 14c upgrade keeps existing role models but requires testing after schema change. | Role-based access control is a core midPoint feature; role mining is also available to help rationalize existing roles. | Role and entitlement management is supported; confirm that the role model covers your existing entitlement structure before migrating. |
| Auditing | Audit data is kept in OIG's own schema; plan how historical audit records are retained through the reconfiguration. | Auditing is part of the platform; confirm retention and export requirements against your audit evidence needs. | Auditing is available; confirm the depth and retention of audit records against your evidence requirements. |
| Self-service access requests and password reset | Request and password reset self-service is part of OIG; confirm that custom request forms and approval flows survive the 14c upgrade. | Self-service access requests and password reset are supported; approval workflows must be designed and tested against your current processes. | Self-service features are part of the platform; confirm workflow depth against your approval processes. |
| Certification and segregation of duties | Certification campaigns and segregation of duties rules are established OIG features; confirm they behave as expected in 14c. | Certification and segregation of duties must be verified against your requirements; ask Evolveum how the current release covers each control before deciding. | Certification and segregation of duties are not a focus of this lighter platform; verify each requirement directly before choosing it. |
| Access management and SSO | OIG is an identity governance product; access management and SSO sit in separate components. | midPoint is an identity management system, not an SSO or access management server, and does not implement the server side of OAuth2, OpenID Connect or SAML. Plan a separate access platform. | Apache Syncope is a provisioning platform; SSO and access management require a separate product. |
| Trade-offs | Lowest change to existing processes, but the upgrade requires a new middleware home, JDK 17, schema upgrade and an irreversible domain reconfiguration. | Open source with no license fee, a Java and PostgreSQL stack and a larger redesign of processes and connectors. Confirm support needs with Evolveum. | Lighter footprint and faster to stand up, but narrower certification and governance coverage. Suited to simpler provisioning estates. |
Which path fits which team situation
Teams whose approval processes, provisioning logic and event handlers live in Oracle SOA Suite or OIG plug-ins usually face the largest rework in either direction. An OIG 14c upgrade keeps that logic on the Oracle stack, so the workflow inventory mostly needs regression testing against the new middleware. A move to midPoint means re-expressing each workflow in midPoint's own approval and object model, which is design work rather than a configuration export.
- Workflow inventory: List every approval process, custom task and scheduled job, with its owner and the systems it calls.
- Customization dependence: Note which customizations depend on Oracle-specific APIs that a new domain or schema may change.
- Replacement effort: Ask an implementation partner to estimate the porting work for the top ten workflows in writing before comparing options.
- Parallel run: Plan whether both stacks can run against the same targets during cutover.
- Evidence to collect: Workflow diagrams, test cases with expected results and the list of SOA composites in use.
Confirm first whether the business still needs each custom workflow, because retiring some of them often shortens either project more than any platform choice.
Teams whose targets are common directories, databases and SaaS applications are the strongest candidates for midPoint, because midPoint uses the ConnId framework and documents connectors for LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID (Graph API), SCIM2 and SCIMv1. Connector coverage still needs checking one target at a time, since the integration catalog ranges from supported to community and experimental status.
- Connector mapping: Match every OIG resource to a documented midPoint connector and mark any gap.
- Connector status: Check whether each connector is supported, community or experimental before relying on it in production.
- Reconciliation scope: Count the accounts and entitlements each connector must reconcile on the first run.
- Custom connectors: Identify any in-house Java connectors that would need to be rewritten against ConnId.
- Evidence to collect: A resource-by-resource mapping sheet and a test reconciliation report from a non-production target.
Confirm the connector status and the target system versions with Evolveum and the target vendors, since these change between releases.
Teams in air-gapped networks or with strict data residency rules need every component, including the middleware, database and build artifacts, to run inside their own boundary. Both an OIG 14c upgrade and a midPoint deployment can be self-hosted, so the decision depends on which components must be mirrored, patched and documented inside the enclosed network. Both paths need an offline supply chain for updates.
- Component inventory: List every runtime, library, database and container image the platform needs, with its source and approval status.
- Offline updates: Confirm how security patches and release packages will enter the network and who approves them.
- Deployment model: midPoint runs on Linux in a virtual machine or from Docker images, so confirm which form your network approves.
- Data flows: Map where identity data, logs and backups are stored, and confirm that no connector sends data outside the boundary.
- Evidence to collect: An architecture diagram, data flow records and a signed-off component bill of materials.
Confirm with your security and compliance owners which control evidence they will accept, because DeployOpen prepares that evidence but independent auditors determine whether it satisfies a framework.
Teams whose staff know Oracle WebLogic and Oracle Database well but have limited Java or PostgreSQL experience face a skills gap in a midPoint move. The OIG 14c upgrade keeps the existing operating model, though it still requires JDK 17 and a new middleware home. midPoint is written in Java and uses PostgreSQL as its native repository database, so the team either builds that skill or relies on a partner or Evolveum support for operation.
- Skills audit: Record which people can operate Java application servers, PostgreSQL backups and connector code.
- Runtime requirements: midPoint recommends Java 25 for version 4.11 and later and Java 21 for 4.10 and older, so confirm which version your team will standardize on.
- Support model: Compare internal operation with an Evolveum Product Support subscription, with its 8x5 next-business-day or 24x7 SLA options, and a DeployOpen retainer.
- Training: Price training and handover as a separate line item in any quote.
- Evidence to collect: A skills matrix, a runbook for the first month of operation and a recorded knowledge transfer plan.
Confirm the support tier and handover scope in writing, since the cost of a skills gap depends on how much operation the team keeps in-house.
How to deploy midPoint alongside OIG during the decision
This sequence lets a team run midPoint against the same targets as Oracle Identity Governance before committing to the 14c upgrade, so the decision rests on measured results rather than vendor documentation. Each phase ends with a check the team can review.
Inventory connectors, roles and approvals
Identity architects and OIG administrators list every connected target, the connector type and version used for each, the roles and entitlements provisioned, and each approval workflow with its approvers and escalation paths. Export the OIG configuration to support this inventory, and extract user, account and audit data separately, since the configuration export does not cover those. The step is done when every target and workflow appears in one document with an owner and a pilot candidate marked. Ask Oracle or your own licensing contact to confirm which OIG components your current entitlement covers before you plan any parallel run.
Select a midPoint release and matching Java version
Platform engineers choose a midPoint release from the release page, weighing long-term support against feature releases, and then pick the Java version the system requirements page lists for that release. Note that midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028, that midPoint 4.10 (Braille) is a feature release supported until 26 November 2027, and that midPoint 4.9 support ends 18 October 2026. Record the chosen release, Java runtime and PostgreSQL version in a short decision record. The step is complete when the record has been approved by the architecture owner and the team confirms the Java runtime is available in its build pipeline.
Stand up PostgreSQL on a separate server
Database administrators provision PostgreSQL as midPoint's native repository database on a dedicated database server, separate from the midPoint application hosts. They apply the backup, access control and monitoring standards already used for production databases in the organization. The step is done when the database accepts connections from the midPoint test host only, a restore from backup has been tested, and the connection settings are stored in the secrets manager, not in plain configuration files.
Deploy midPoint on Linux VMs or Docker
Platform engineers deploy the chosen midPoint release either on a Linux virtual machine or from the official Docker images, inside the same network zone as the target systems used for the pilot. Confirm the deployment method against the system requirements before choosing it. A single node is enough for the pilot. The step is complete when the midPoint web interface loads over HTTPS, the administrator account is secured, and the initial configuration has been backed up. If the team plans a multi-node deployment later, the design must include a sticky HTTP load balancer, a shared central database for all nodes, cache invalidation between nodes over HTTPS and Quartz for distributed task scheduling, and these components should be tested before the pilot is treated as production-like.
Connect a pilot target through ConnId
Integration engineers choose one low-risk target, such as a directory or a CSV or database table that the team already maintains, and configure a ConnId connector in midPoint for it. Check the connector status in the Evolveum connector catalog, since some connectors are supported while others are community or experimental. Run reconciliation in read-only or simulation mode first and compare the results with the same accounts in OIG. The step is done when the midPoint view of the pilot target matches OIG for a defined sample of accounts, and every gap is logged with an owner.
Run both systems against the same targets
Identity operations staff run OIG and midPoint against the same pilot targets during a controlled window, with a written rollback plan and a named owner for each system. Provisioning changes from requests should be compared, and any difference in entitlements, approvals or audit output should be recorded. Keep midPoint changes limited to the pilot set so that production access is not altered by the parallel run. The step is complete when the parallel run has produced a comparison report covering provisioning results, approval outcomes, reconciliation discrepancies and audit records.
Set cutover criteria and decide
The CISO, identity governance lead and application owners agree written cutover criteria before the decision meeting. Criteria should cover matching results from the parallel run, approval and certification coverage for the in-scope workflows, audit evidence that compliance owners accept, support arrangements for the chosen path, and the cost of the OIG 14c upgrade compared with the midPoint migration, based on written quotes. Record whether the decision is to upgrade to 14c, to migrate to midPoint or to pause. The step is done when the signed decision record names the chosen path, the owner and the next review date.
Evidence to keep for the upgrade or replacement decision
An upgrade or replacement decision for Oracle Identity Governance is only as defensible as the records behind it. The five items below are what auditors and steering committees usually ask to see, and each one answers a different question about the decision.
Requirements inventory
A dated list of every connected target, role, approval workflow, certification campaign and report that OIG 12c performs today, with an owner for each. It shows what the new platform, whether OIG 14c or midPoint, must reproduce, and it is the baseline every later test is measured against. Check that the inventory covers workflows that run only as custom code or scheduled jobs, since those are the ones most often missed.
Connector and reconciliation test results
Test runs showing that each target system is provisioned, updated, disabled and reconciled correctly against the inventory. For midPoint, record which ConnId connectors are supported, community or experimental, because that status affects the support position. Keep the comparison of account counts and attribute values from before and after each run, not only a pass or fail result.
Rollback and backup evidence
Verified backups of the OIG database, the WebLogic domain and the configuration taken before the schema upgrade or domain reconfiguration, with proof that each can be restored. The reconfiguration step is irreversible, so this record is the only way back. Keep the restore test log and the time it took, and confirm that the backup set includes the audit tables your retention policy requires.
Approval and access review records during parallel running
While both platforms run against the same targets, keep the request, approval and certification records from each side. Compare who approved what, how long approvals took and which access reviews reached the same decision. Differences here show where approval logic was ported incorrectly and where a reviewer relied on a step that has no equivalent yet.
Decision record
A written record of the options considered, including staying on 12.2.1.4 with the cost and support position that implies, the OIG 14c upgrade and the move to midPoint. It states the criteria, the people who approved the choice, the risks accepted and the conditions for revisiting it. Record the support dates for each release you evaluate, taken from the vendor's own documentation at the time of the decision.
Questions teams ask before choosing between 14c and midPoint
What does an Oracle Identity Governance 14c upgrade cost in effort, and what drives it?
The upgrade cost is mostly effort, and the main drivers are the size of your connector estate, the number of custom plug-ins and approval workflows, and how much testing your change process requires. The 14c move needs a new middleware home, JDK 17, a schema upgrade and a domain reconfiguration that cannot be reversed, so each of these is a separate work package. Cost components to separate in a quote are Oracle license and support changes, WebLogic and database work, specialist staff time, test environments and your own internal review. Ask the implementer for a written scope listing each package, the environments included and the rollback plan, since those items set most of the total.
How long does a migration to midPoint take, and what sets that duration?
No duration is fixed by a researched fact, so treat any timeline as a estimate to be confirmed in writing. The main variables are the number of target systems, how many attributes and entitlements each one carries, how much approval logic must be ported, and whether you run old and new systems in parallel during cutover. Connector coverage matters too: midPoint documents connectors for LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID, SCIM2 and SCIMv1, and anything outside that list needs a connector assessment first. Ask for a phased plan with reconciliation checkpoints, not a single end date.
Can our own team run the work, or do we need outside help?
Your team can run the work if it has people who know midPoint's object model and Java connector development, plus operations skills for PostgreSQL and multi-node Java services. Many organizations split the work: internal staff own the identity data, access policy and sign-off, while an implementation partner handles installation, connector work, hardening and documentation. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with the scope agreed in writing before work starts. Decide the split before you request a quote so the scope matches your staff.
What skills and staff does midPoint need after go-live?
midPoint needs Java and Linux operations skills, PostgreSQL administration on a database server that is ideally separate from the application, and someone who owns the connectors and the reconciliation schedule. Evolveum's system requirements recommend Java 25 for version 4.11 and later and Java 21 for 4.10 and older, and midPoint can run on a Linux virtual machine or from Docker images. Multi-node deployments add a sticky HTTP load balancer, a shared central database and cache invalidation between nodes. Confirm these needs against your own platform standards and budget for on-call coverage, since identity services are rarely allowed to stay down.
Are Evolveum support subscriptions required to run midPoint?
No. midPoint is open source with no license fee, and Evolveum states it has no enterprise edition, so a production system can run without a subscription. 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. Its support page lists no prices, so request the figures in writing. Also ask an implementation partner to confirm which midPoint release line your support would cover, since midPoint 4.8 is a long-term support release supported until 17 October 2028.
Is Apache Syncope enough to replace Oracle Identity Manager?
Apache Syncope can replace Oracle Identity Manager if your needs are mainly provisioning, ConnId-based connectors, self-service and workflow for a moderate estate. It is an Apache Software Foundation project under the Apache License 2.0, and version 4.1.3 was released on September 11, 2026. Check it against the features your OIG deployment uses heavily, especially certification campaigns and segregation of duties, which midPoint covers as part of its governance scope along with role mining and simulations. The sibling comparison of Oracle Identity Governance and Apache Syncope walks through this gap in detail.
What should we request in a written quote for the 14c upgrade or a midPoint move?
Ask for a written scope that lists every deliverable, environment, connector and workflow in or out of scope, with acceptance criteria for each. For the 14c upgrade, require separate lines for the middleware home, JDK 17, schema upgrade, domain reconfiguration, testing and rollback. For a midPoint move, require connector mapping, reconciliation checks, approval process porting, parallel running and WebLogic and SOA Suite retirement. Also ask for the handover documents, the backup and upgrade approach, the support model after go-live, and any third-party costs such as Evolveum subscriptions or infrastructure, so you can compare offers on the same basis.
How DeployOpen approaches an OIG 14c or midPoint decision
DeployOpen helps teams on Oracle Identity Governance 12.2.1.4 compare an in-place upgrade to 14c with a move to self-hosted midPoint, using a written scope before any work starts. The work runs inside your own cloud accounts, data centers or air-gapped networks, and the outcome is documented for your own decision.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We inventory your current OIG connectors, roles, approval workflows and audit data to size the decision accurately.
- The written scope states whether it covers an OIG 14c upgrade, a midPoint build, or a side-by-side comparison of both.
How we build
- For an upgrade path, we plan the new middleware home, JDK 17 move, schema upgrade and irreversible domain reconfiguration as separate steps.
- For a midPoint path, we map ConnId connectors, reconciliation rules and access request flows against your target systems.
- We test provisioning, deprovisioning and certification flows in a non-production environment before any cutover decision.
How we hand over
- You receive documented configuration, connector inventory, runbooks and test evidence for your own audit and operations teams.
- Each deliverable is reviewed against the agreed scope, with open risks and decisions recorded in writing.
- Compliance readiness work prepares systems, controls and evidence; independent auditors and certification bodies issue any assessment outcome.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover midPoint release upgrades, such as tracking the 4.8 long-term support line and later feature releases.
- Ask for the support scope, response expectations and testing cadence to be written into the quote before you commit.
