Migrate from Oracle Identity Governance to midPoint

Migrate from Oracle Identity Governance to midPoint without losing control of access

Moving from Oracle Identity Governance to midPoint is a planned project with a clear sequence: inventory what OIG actually does, rebuild it connector by connector, prove the results side by side against the same targets, then cut over and retire the WebLogic and SOA Suite stack. A renewal, a licensing change or a residency requirement sets the deadline, but the sequence is what keeps access under control. Most teams run the work as an internal IAM team with an implementation partner, with the partner carrying specialist knowledge of midPoint connectors, reconciliation tuning and approval design. The platform install is the smallest part. The effort sits in the connectors, the reconciliation rules and the approval logic that OIG has accumulated over years of change.

Start with the exported configuration and a written inventory of resources, roles, entitlements, provisioning adapters and approval workflows. Export is only the starting point: identity, account and audit data must be extracted separately, and some OIG behavior lives in custom Java plug-ins or event handlers that the export will not explain. For each target system, confirm whether a midPoint connector exists in the ConnId catalog, check its status in the Evolveum connectors documentation, and decide whether a supported connector, a community connector or a scripted connector is acceptable for that system. Plan reconciliation carefully: the correlation rules that decide which account belongs to which identity are where most migrations lose accuracy, so test them against a copy of production data before any target is switched.

Run the two platforms in parallel for a defined period, with midPoint in read and simulation mode first, then in controlled provisioning for low-risk targets. Compare entitlements, certification outcomes and access request results between OIG and midPoint for the same population. Ask your implementation partner and Evolveum to confirm the supported midPoint release and Java version for your target, using the midPoint releases page, because support windows differ between long-term and feature releases. Retire WebLogic and SOA Suite only after audit evidence from both runs has been reviewed and the rollback path has been tested.

Which Oracle Identity Governance capabilities map cleanly to midPoint

This table compares the main Oracle Identity Governance capabilities with their midPoint equivalents and marks each as clean, needs rework or gap. Use it to decide which areas can move with configuration effort and which need design work or a different tool. Treat every mapping as a hypothesis until your own roles, connectors and approval flows are tested against midPoint in a non-production environment.

Capability	midPoint equivalent and status	What to confirm in your environment
Provisioning and reconciliation	Clean: midPoint provides provisioning, deprovisioning and reconciliation against resources through ConnId connectors.	Confirm that each target's reconciliation schedule, matching rules and correlation logic reproduce your OIG outcomes on a copy of production data.
Connectors	Needs rework: midPoint uses ConnId connectors, and LDAP, Active Directory, SCIM2, Microsoft Entra ID and database connectors are documented. Connectors for other OIG targets may be community or experimental.	Check the Evolveum connector status for every OIG target, and plan custom ConnId development or testing for any target without a supported connector.
Role-based access control	Clean: midPoint supports role-based access control, with roles, assignments and policy-driven provisioning.	Map your OIG role catalog, role hierarchies and entitlement assignments to midPoint roles, and verify the result with role mining outputs and simulations.
Request and approval workflows	Needs rework: midPoint offers self-service access requests and approvals, but OIG approval flows built in SOA Suite must be redesigned rather than copied.	Document each approval chain, escalation rule and SLA-like timeout in OIG, then rebuild and test them in midPoint with the approvers who use them today.
Certification and attestation	Gap or needs rework: certification campaigns must be confirmed against your review requirements, including reviewer assignment, remediation and evidence retention.	Confirm with Evolveum documentation which campaign features match your OIG certification design, and list any review workflow you must build or accept as a manual control.
Segregation of duties	Needs rework: midPoint supports policy rules, but rule sets built on OIG SoD definitions require re-expression and validation.	Export your SoD rule inventory and test each rule against known conflicting role combinations before retiring the OIG rules.
Password management	Needs rework: midPoint provides self-service password reset, and password policies apply through resources and connectors.	Confirm password synchronization and policy enforcement for each target, and test helpdesk and self-service flows with your existing identity sources.
Auditing and audit trail	Needs rework: midPoint records changes and operations, but the retention, format and export of audit history differ from OIG tables.	Define which audit events your assessors need, extract historical OIG audit data separately, and confirm where midPoint stores its records and how long they are kept.

How midPoint connects to the same targets OIG manages today

The first question for any OIG-to-midPoint move is whether midPoint can reach every target system that OIG provisions to today. midPoint connects to source and target systems through the ConnId connector framework. Each connector is Java code that sits behind a uniform interface and speaks the target system's own protocol, so midPoint sees every resource the same way regardless of what is on the other end. The documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID through the Graph API, SCIM2 and SCIMv1. Read the Evolveum connector list against your own inventory of OIG connector instances, and record each target as a one-to-one match, a match that needs a custom build, or a gap.

Do not assume that a connector listed in the catalog is equally mature for every target. The catalog's status for each connector ranges from supported to community and experimental, and that status determines who carries the risk if something breaks. For a supported connector, confirm the exact connector version against the midPoint release you plan to run, because the documented status applies to specific releases. For any connector that is community or experimental, plan a proof of concept against a non-production copy of the target, test create, update, disable and delete operations, and decide whether you will support that connector in-house or through a commercial agreement. Ask Evolveum or your implementation partner to confirm the status in writing for each connector on your list.

Custom targets are where migrations usually slow down. If an OIG target depends on a connector you built yourself, or on a vendor connector with no equivalent in the catalog, the work is to write a ConnId connector in Java, or to use a generic option such as ScriptedSQL or a SCIM interface where the target offers one. Estimate that effort per target from your own connector code and test results, not from general assumptions. Also confirm how each target's account correlation and attribute mapping will be reproduced in midPoint's resource definitions, because those mappings, not the connector itself, usually carry the business logic that must survive the move.

What to export from OIG and what must be extracted separately

OIG's Export Configuration output documents how the system was built, but it does not carry the identities, accounts or audit history that a migration must preserve. Treat the export as a blueprint for midPoint design and the other items as separate extraction projects with their own owners and checks.

Configuration export as design documentation

The Export Configuration wizard produces an XML file of configuration artifacts, with optional dependent entities. Use it to inventory resources, roles and workflows, then map each artifact to a midPoint object such as a resource, role, or approval flow. Confirm with your Oracle version which artifact types the wizard includes, because dependent entity selection changes what you get. Expect the XML to describe intent, not runtime behavior.

Resource and connector inventory

Each connected target, its connector type, its attribute mappings and its reconciliation schedule shape the midPoint resource definitions. The export shows the configured connector instances, but not always the credentials or runtime settings. Record the target versions and the connection parameters separately, and confirm which connectors midPoint supports for each target through the ConnId connector list before you commit to a mapping plan.

Role and entitlement membership data

Role definitions come from the configuration export, but the actual assignments of users to roles and entitlements live in the OIG database. Extract them with a query or a reporting path your DBA approves, then compare the counts per role against the target systems. Discrepancies usually reveal manual grants or orphaned entitlements that should be resolved before import, not copied forward.

Identity and account records

User profiles, account links and their status are operational data, not configuration, so they are not part of the export. Plan a controlled extraction from the OIG schema, with field-level mapping to midPoint users and shadow accounts. Ask the owner which attributes are authoritative and which are copies, and confirm the extraction method against your own Oracle version and schema documentation.

Request, approval and certification history

Open and completed access requests, approval decisions and certification campaign results are the evidence auditors ask about. The configuration export does not carry this history, and midPoint will start its own audit trail on cutover. Decide with compliance which records must be archived, where, and for how long, and confirm the extraction path for each record type with your Oracle release.

Audit and event logs

Audit logs and reconciliation run records sit in the OIG database and in the WebLogic and SOA logs. Export them to read-only storage with checksums so the chain of custody survives retirement of the domain. Confirm log retention settings in your environment, because default retention depends on how the platform was installed and configured.

The migration sequence from inventory to decommission

This sequence moves identity governance from Oracle Identity Governance on WebLogic and SOA Suite to midPoint in controlled stages. Each stage produces a written artifact, and no stage starts until the previous one has passed its stop criteria.

Inventory resources, roles and approval flows
Your team exports the OIG configuration with the Export Configuration wizard, then pairs that file with separate extracts of identity, account and audit data. The working group lists every connected target, every role and entitlement, every provisioning and approval workflow, and every scheduled reconciliation job. The output is a resource inventory with owners, plus a short list of customizations that have no obvious midPoint equivalent. Stop when every target has an owner and every workflow has a documented purpose.
Build and test a pilot connector
Pick one low-risk target, such as a directory or a database table, and build its connector in midPoint using the ConnId framework. Test create, update, disable and delete operations against a non-production copy of the target. The output is a tested resource definition and a reconciliation report showing which accounts match, which are orphaned and which attributes differ. Stop when the pilot reconciles cleanly on two consecutive runs and the mapping rules are signed off by the target owner.
Port approvals and role logic
Rebuild each approval path in midPoint's workflow and access request features, and translate OIG role membership rules into midPoint roles, assignments and policy rules. Each rebuilt flow is checked against the original OIG behavior using the same test identities, including edge cases such as delegated approvers and emergency access. Simulations against production data help show the effect of role changes before they are applied. The output is a mapping table from each OIG workflow to its midPoint equivalent, with gaps listed. Stop when every gap has a documented decision to accept, rebuild or drop it.
Run both systems against the same targets
For a defined period, OIG and midPoint both read from the same targets, but only OIG writes changes while midPoint runs in read-only or report-only mode. Each night, the team compares what midPoint would have changed with what OIG actually changed. The output is a parallel-run discrepancy log, reviewed by the owners of each target and by the security team. Stop when the discrepancies are either explained or fixed and the team agrees that midPoint's proposed changes match the intended policy.
Cut over provisioning to midPoint
Switch write authority for each target from OIG to midPoint in a planned order, starting with the pilot target and keeping OIG available to revert. Confirm audit logging, alerting and access for approvers work as documented in the migration runbook. The output is a signed cutover checklist per target, with the approver names, the date of each switch and the rollback steps. Stop when each target has run under midPoint for a period agreed with its owner without an unresolved incident.
Retire OIG, WebLogic and SOA Suite
Once no target depends on OIG, stop the OIG and SOA Suite services and keep the final configuration export, database backup and audit data in your records retention store. Decommission the WebLogic domains and the Oracle Database instances only after your compliance owner confirms that retained evidence can still be produced. The output is a decommission record listing every removed component and where its archived data is stored. Confirm with your auditors which records they need before you delete anything.

How the migration differs by OIG estate size and starting point

A smaller OIG deployment usually manages a handful of target systems, such as a directory, a few applications and a database, with a modest number of roles and simple approval paths. In this case the migration is mostly a mapping exercise. Each connector is matched to a ConnId connector in midPoint, and the work concentrates on reconciliation rules and a clean role model rather than on rebuilding large workflows.

Connector inventory: List every resource in OIG and confirm whether midPoint documents a matching connector, such as LDAP, Active Directory, CSV or Microsoft Entra ID, or whether a community or experimental connector is needed.
Role model: Check whether existing OIG roles and entitlements map cleanly to midPoint roles, or whether they need redesign first.
Reconciliation scope: Confirm which accounts must be reconciled on each target and how often.
Parallel running: A small estate is often quick to run against the same targets in read-only comparison before cutover.
Support decision: Decide early whether an Evolveum Product Support subscription is needed, since the platform is free to use without one.

Confirm the connector list and the approval paths against the live OIG configuration, not against documentation alone, because undocumented exceptions are common even in small estates.

What drives migration cost and duration

This table lists the main factors that raise or lower the effort of moving from Oracle Identity Governance to midPoint, with the reason each one matters and how to keep it under control. Read it before asking for a quote, because the same drivers appear in any written scope. The main takeaway is that connector count, custom Java plug-ins and approval complexity usually matter more than the raw identity count.

Driver	Why it changes cost or effort	How to keep it down
Number and type of connectors	Each OIG connector must be matched to a ConnId connector or a custom one. Documented connectors such as LDAP, Active Directory, CSV, DatabaseTable and Microsoft Entra ID reduce work, while niche targets may need new development.	Inventory every target in the OIG resource list, then map each to a documented ConnId connector before scoping.
Custom plug-ins and scripts	OIG adapters, event handlers and Java plug-ins usually hold business rules that midPoint expresses differently, through mappings, expressions, object templates or custom code. Every rule needs rewriting and testing.	Classify custom code as retire, reimplement as midPoint configuration, or keep as a documented exception. Remove dead code early.
Approval process complexity	Multi-step approvals, delegations, escalations and SoD checks built in SOA Suite workflows must be redesigned on midPoint's workflow engine. Complex chains add design review and test cycles.	Document each approval path as a flow diagram with owners and exit conditions, and agree the simplified design with business owners before build.
Data volume and identity count	Larger populations increase the time for initial reconciliation, data cleansing and the first full load. Evolveum states midPoint scales to 100 million identities, but the load and reconciliation time depends on your own data and hardware.	Clean duplicate and orphan accounts in OIG before export, and run timed test loads on a copy to size the production window.
Number of target systems	Each target adds mapping, reconciliation, error handling and test effort. Shared targets used by several roles need the most careful testing because a change affects many users.	Group targets by criticality and migrate low-risk systems first, keeping shared directories for the final wave.
Testing and parallel run length	Running OIG and midPoint against the same targets is the main safeguard, but it means two systems are maintained at once and results must be compared, which extends the schedule.	Agree the comparison criteria, exit conditions and the parallel run length in writing before the project starts.
Internal staff availability	Identity owners, application owners, the SOA and WebLogic administrators, and security reviewers must provide decisions and test time. Delays here often extend the project more than technical work does.	Name decision owners and reserve their time in the plan. Ask the implementation partner which tasks depend on client staff.
Infrastructure and retirement scope	Running midPoint on Java and PostgreSQL, plus the parallel environment, adds work. Retiring WebLogic and SOA Suite also requires decommissioning, data retention and audit evidence.	Confirm the target midPoint release and Java version for your platform, and ask for the retirement steps and retention plan in the quote.

What usually goes wrong when moving off Oracle Identity Governance

Most OIG-to-midPoint projects stall on the same few problems: logic nobody wrote down, accounts that do not match a person, approvals that behave differently, and evidence that auditors cannot follow. Each card below names one risk and the check that prevents it before cutover.

Undocumented custom logic in OIG

Over years, OIG deployments accumulate custom Java plug-ins, event handlers, scheduled tasks and lookup logic that live outside the configuration most teams review. Because the Export Configuration output covers configuration artifacts, it will not show everything the system does at runtime. Before design starts, inventory every custom class, adapter and scheduled job on the WebLogic and SOA servers, and assign each one a keep, rewrite or retire decision with a named owner.

Orphaned and duplicate accounts

When midPoint first reconciles against live targets, accounts that were created by hand, by old connectors or by previous joiner processes often show up without a matching identity. Each one needs a correlation rule, a link to a person or an explicit exception. Run reconciliation in report-only mode against a copy of each target and count unmatched and multiply matched accounts per system, so that the cleanup list is known before any account is changed.

Approval semantics that drift

An approval step in OIG may mean one manager sign-off, a fallback to the application owner after a timeout, or an auto-approval for a specific role. Those meanings do not transfer automatically when the workflow is rebuilt in midPoint. Write each existing approval path as a short decision table, including escalation and rejection, and have the business owners sign it off. Then test each row with a request that should be approved, one that should be rejected and one that times out.

Certification evidence gaps

Auditors look for who certified what, when, on which data and with what outcome. Moving campaigns to midPoint can break that chain if the old reports are not mapped to the new ones. Define the evidence set your assessors expect for each access review, such as scope, reviewer, decision and remediation record, and confirm that midPoint's audit and certification features produce each item. Keep exported OIG campaign records in read-only storage for the retention period your auditors require.

Role model that was never mined

Roles in OIG are often a mix of entitlements built for one application, shadow roles created for exceptions and roles nobody uses. Copying them one for one into midPoint carries the mess across. Use midPoint's role mining and simulation features against a copy of production data to see which assignments actually exist, and consolidate before importing. Record each retired role so that a later audit can see why an access path disappeared.

Under-tested cutover

Parallel runs are the safest way to find gaps, but they fail when both systems write to the same target without a clear owner for each account. Agree on which system is authoritative for each connected application and for how long, then run both against non-production copies with the same change feed. Define rollback steps for each target, rehearse them once, and keep WebLogic and SOA Suite available until the rehearsal and the first full reconciliation cycle have passed.

Questions teams ask before moving from Oracle Identity Governance to midPoint

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

The cost depends mainly on how many connected systems, custom approval workflows and provisioning rules you have to port, and on who performs the work. midPoint itself carries no license fee, so the one-time costs are the migration project, the connector work, testing and any subscription you choose. The recurring costs are infrastructure for midPoint and PostgreSQL, staff time to operate it, and an optional Evolveum support subscription. Your current Oracle license and annual support, WebLogic, SOA Suite and database costs stop only when you retire those components, so model both sides with the same timeline. Ask any implementation partner for a fixed-scope quote built from a written inventory of resources, roles, workflows and reports.

How long does an Oracle Identity Governance to midPoint migration take?

The duration depends on scope, not on a fixed template. The main factors are the number of target systems and their connector types, how much custom Java or SOA logic must be re-expressed, how many approval paths and certification campaigns exist, and how long you need to run both platforms in parallel. Reconciliation accuracy also takes time, because you need to compare identity and entitlement data between the two systems before you cut over. No duration figure is supplied for this migration, so ask any proposal for milestones tied to your inventory, and confirm the parallel run period your audit and risk teams require.

What do our internal teams need to contribute to the migration?

Your team owns the business knowledge that no export file contains. Identity and access owners need to confirm which roles are still correct, who approves which requests, and which entitlements are required for regulatory reasons. Application owners need to confirm target system behavior, service account ownership and reconciliation rules. Security and compliance staff define the evidence they will need for access reviews and audits, and platform engineers provide the database, Java runtime, load balancer and backup environment. Expect these people to be involved throughout testing, not only at the start. Confirm named owners and their time commitments in writing before the project starts.

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

A capable identity and platform team can do it alone if it has hands-on experience with Java application servers, PostgreSQL administration, LDAP or Active Directory connectors and identity lifecycle design. The harder parts are re-creating approval logic, validating reconciliation outcomes and proving to auditors that controls behave the same way. Many teams combine internal ownership with an external partner for testing, hardening and documentation. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms in your own infrastructure, under a fixed-scope written agreement, and does not issue audit reports or certifications. Decide the split of responsibilities before you request a quote.

Does midPoint require a license, and what does an Evolveum subscription add?

midPoint is open source and dual-licensed under EUPL-1.2 and Apache 2.0, and Evolveum states that it has no enterprise edition, so there is no license fee to pay. Evolveum funds development through subscriptions, training and professional services. Its Product Support subscriptions cover resolving product bugs with an 8x5 next-business-day or 24x7 SLA, and its Platform Subscriptions add feature development and roadmap influence. The subscription page lists no prices, so request a quote from Evolveum. A subscription is optional, and you can also buy support from other providers, which you should confirm before you rely on it.

Which Java and PostgreSQL versions does midPoint need?

midPoint recommends Java 25 for version 4.11 and later, with Java 21 supported, and Java 21 for version 4.10 and older, with Java 17 supported. It uses PostgreSQL as its native repository database and recommends a separate database server. Version 4.8 (Curie) is the long-term support release, supported until 17 October 2028, while 4.10 (Braille) is supported until 26 November 2027 and 4.9 support ends 18 October 2026. Feature release 4.11 (Čapek) is planned for 21 October 2026. Confirm the exact PostgreSQL major version against the system requirements page for the midPoint release you choose before you build the environment.

How do we retire WebLogic and SOA Suite safely?

Retire them in stages, and only after both systems have run against the same targets long enough to match your evidence requirements. Start by exporting configuration to document resources, roles and approval workflows, then re-create them in midPoint and compare results. Keep the Oracle environment read-only for a defined period so you can recover historical data and audit trails. Before shutdown, extract identity, account and audit data separately, because configuration exports do not carry it. Confirm backup retention, data disposal rules and the sign-off required from your risk and compliance owners, then decommission the WebLogic domain, SOA Suite and the related database schemas in a documented change.

Does midPoint replace our single sign-on server?

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 Oracle Identity Governance is your only identity platform, you will need a separate authentication service for applications, though midPoint's own user interface can authenticate against external SSO services. Confirm which applications rely on OIG for login or federation before you scope the migration, because those integrations are outside midPoint's scope and need their own plan.

Retiring WebLogic and SOA Suite after cutover

Retiring Oracle Identity Governance is a controlled shutdown, not a server switch-off. Before anyone decommissions the WebLogic domain or the SOA Suite components, archive the OIG configuration and audit data in a form your auditors can still read, then confirm that nothing in production still calls the old domain. Work through the inventory from the migration: every connector that was pointed at an OIG-managed endpoint, every scheduled reconciliation job, every approval workflow that was ported to midPoint, and every notification or integration that posted to OIG's APIs. Each item should be marked as either moved to midPoint or formally retired, with the owner's sign-off recorded.

Retention is the decision that takes longest, and it is not a technical one. Identify which OIG audit records, request histories, certification campaign results and reconciliation logs your regulators, internal audit or contracts require you to keep, and for how long. Export them to read-only storage that you control, and test that someone outside the migration team can search and open them without the old stack running. Keep the Oracle Database schema online until those retention needs are met, or until the archive is proven complete. Ask your compliance team to confirm the retention periods in writing, since they vary by jurisdiction, sector and record type.

Decommission the Oracle Database schema last, and only after the archive has been verified and the retention decision is documented. Stop the WebLogic and SOA Suite services in a staged order, keep a frozen copy of the domain and database backups for the agreed period, and record the hash or checksum of each archive so you can show integrity later. Review access to the retained copies, since they contain identity data and must stay under the same access controls as the live system. Confirm the exact dependencies, licensing end date and support terms with Oracle and your contract owner before you stop paying for them.

How DeployOpen scopes and runs an Oracle Identity Governance to midPoint migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a migration from Oracle Identity Governance to midPoint runs in your cloud account, data center or air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory the OIG connectors, resources, roles, approval workflows and audit data you rely on today
Map each resource to a midPoint connector, noting where ConnId coverage needs confirmation
Agree in writing which workflows, reports and certifications move, change or retire
Define cutover criteria, parallel-run targets and the rollback path before any build starts

How we build

Stand up midPoint on Linux or Docker with PostgreSQL, sized to your identity volume and nodes
Build connectors, reconciliation tasks and approval processes in a non-production environment first
Test provisioning, deprovisioning and reconciliation against sandboxed copies of each target system
Harden the platform and document configuration, access controls and backup procedures as you build

How we hand over

Deliver written runbooks for operations, connector changes, role updates and incident response
Train your administrators on midPoint objects, simulations and the reconciliation workflow
Provide evidence packs covering configuration, testing results and decommissioning steps for WebLogic and SOA Suite
Confirm with your auditors which control evidence they will accept, since DeployOpen prepares evidence but does not issue audit reports

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover
Plan midPoint upgrades against the published release and support dates you agree with us
Keep backup and restore procedures tested as part of routine retainer work
Ask for a written quote based on your scope, since DeployOpen does not publish a price list

Migrate from Oracle Identity Governance to midPoint