How to export your configuration from Oracle Identity Governance before the contract ends
The Export Configuration wizard in Oracle Identity Governance produces an XML file of configuration artifacts, with optional dependent entities that those artifacts reference. Identity, account and audit data are not part of that file and must be extracted separately. If a renewal, licensing change or exit decision means you need your OIG data outside Oracle, start by inventorying what the export covers and what it leaves out. Treat the XML as documentation and mapping input for midPoint. It cannot restore your deployment. Confirm the exact contents against Oracle's documentation for the OIG release you run, because artifact types and dependency options can differ between releases.
In a migration to midPoint, the exported XML is most useful as an inventory. Work through it to list the resources (target systems), the roles, the approval and provisioning workflows, and the attribute mappings each one depends on, then note which of them are still used in daily operations. Each target system then needs a matching connector. midPoint documents LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID, SCIM2 and SCIMv1 connectors, and its integration catalog lists further connectors whose status ranges from supported to community and experimental. Mark every target whose connector is not fully supported early, so that the decision about it is made before the cutover plan is written.
Identity, account and audit data need their own extraction plan. Identity records and their attributes, the accounts held on each target system and the links between them are the data midPoint must be populated with, so confirm with your DBA which database tables hold them in your deployment. Audit data is different: it is history of changes and approvals that may be needed as compliance evidence after the platform is retired. Ask your records owner and internal or external auditors which audit records must be preserved, in what format and for how long. Start these extractions well before the contract end date, because imported identities and accounts must be reconciled against the live targets before anyone trusts the new system.
What can you export from Oracle Identity Governance, and how
This table separates the three kinds of data a migration to midPoint needs from OIG and shows how each one leaves the system. Configuration artifacts come from the Export Configuration wizard as XML, while identity, account and audit data need separate extraction. Read each row against the export method and confirm the element list and any limits in Oracle's documentation for your release.
| Data type | Export method | Format | Limits and what to confirm |
|---|---|---|---|
| Resources, connectors and IT resource definitions | Export Configuration wizard, with optional dependent entities | XML file of configuration artifacts | Confirm which element types the XML covers for your release and whether dependent entities are included. |
| Roles and policies | Export Configuration wizard, with optional dependent entities | XML file of configuration artifacts | Role membership is identity data and is not part of the configuration export. Confirm how role definitions reference users. |
| Request and approval workflows, and forms | Export Configuration wizard, with optional dependent entities | XML file of configuration artifacts | Workflow logic may be partly code or SOA process definitions held outside the XML. Confirm with Oracle what the export captures. |
| Identity records and account links | Separate extraction from the OIG database or documented interfaces | Database extract or interface output, format set by your query | The wizard does not export user records. Confirm the supported interfaces and the schema for your release before you build the extract. |
| Entitlements and role assignments | Separate extraction from the OIG database or documented interfaces | Database extract or interface output, format set by your query | Entitlement data is tied to target systems and needs reconciliation with the live targets. Confirm the joins with your database team. |
| Audit and certification history | Separate extraction from the audit and certification schemas | Database extract, format set by your query | Retention rules and legal hold apply. Confirm with your compliance owner which records must be kept in a readable form after OIG is retired. |
What the export does not carry, and how to recover each item
The configuration XML describes how OIG is built, but it does not hold the live state, the secrets or the evidence behind it. Each item below needs its own extraction, inventory or archive step before you decommission anything.
Identity and account data
The wizard exports configuration artifacts, not the users, their role assignments or the links between each identity and its accounts on target systems. Extract these with a read-only query against the OIG schema, or with an export path Oracle documents for your release. Ask your DBAs which tables hold user, role and account linkage data, and confirm with Oracle whether the supported tooling covers them. Reconcile the extract counts against the source systems before you load anything into midPoint.
Passwords and credential material
Passwords, connector credentials and keys are encrypted with keys held by your OIG installation, and they should never leave it in clear text. Plan to re-enter service account credentials in midPoint from your password vault, and rotate any credential that a migration exposed. Confirm with Oracle and your security team how encryption keys and keystores are stored, and whether any value must be decrypted for the move. Record each connector's credential owner before cutover.
Custom Java plug-ins and scripts
The XML refers to custom adapters, event handlers, scheduled task classes and scripts by name, but the code lives in JARs and script files on the server. Inventory every deployed artifact in the managed server classpath and every script the configuration calls. Map each one to a ConnId connector, a midPoint expression or a custom task, and check the mapping against the ConnId framework documentation. Treat any logic you cannot map as a design decision to review with the business owner.
Certification and attestation evidence
Campaign definitions, reviewer decisions, sign-offs and revocation records are audit evidence, and the configuration export does not include their history. Export the completed campaign results as reports, and archive the original records in a read-only store that you control. Ask your compliance lead and external auditor how long each record must be kept and in what form they will accept it. Do not assume that a midPoint certification history replaces the OIG records without that agreement.
Runtime state and scheduled tasks
Pending approval requests, queued provisioning operations, failed operations awaiting retry and scheduled reconciliation jobs are runtime state, not configuration. Drain the request and provisioning queues before the cutover window, and export the list of anything still open. Record each scheduled job's frequency, target and owner from the OIG console, then recreate them in midPoint as tasks. Confirm the queue and schedule details with your OIG administrators, because they vary by deployment.
Audit history and server logs
Audit tables and server logs record who changed what and when, and they are often needed for investigations and assessments long after the migration. The configuration export does not include them. Export the audit tables and the WebLogic and SOA logs for your retention period, store them in a format your SIEM or archive can read, and document where each copy sits. Confirm the retention period and the required format with your compliance team before you plan the decommissioning date.
Sequence for a complete OIG export, with verification at each step
This sequence turns an Oracle Identity Governance estate into a documented, verifiable set of artifacts that a midPoint migration team can use to map resources, roles, workflows and history. Each step closes with a check so gaps are found while the source system is still available.
Freeze a baseline and record versions
The OIG administrator records the exact OIG release, bundle and patch level, the WebLogic and SOA Suite versions, the database version and the date of the snapshot, and agrees a change freeze on configuration with the application owners for the export window. Store this record in the migration repository as the reference for every later comparison. Done when a second person can read the record and confirm which environment the artifacts came from.
Run the Export Configuration wizard twice
Run the Export Configuration wizard once without dependent entities and once with them, then save both XML files under the same name and version control branch. The first file gives a clean list of top-level objects, and the second shows what each object pulls in, such as lookups, process forms and scheduled tasks. Verify that each XML file parses with a standard XML parser, that the root element and namespace are as expected, and that the files differ only where dependent entities were added. Store the files unchanged, because later edits belong in a separate working copy.
Extract identity and account data separately
The wizard does not carry user records, account links or entitlement assignments, so run documented database queries or the supported OIG interfaces to extract identities, accounts per target resource, role and entitlement memberships, and organizational structure. Keep the extraction scripts in version control so the run can be repeated. Verify the row counts against the OIG console for a sample of resources and reconcile total accounts per target system against each target's own count. Record every difference before continuing.
Export audit and certification history
Extract the audit trail for the period your retention rules require, along with certification campaigns, their decisions, reviewer assignments and segregation of duties policy violations. Confirm with your compliance lead which records must remain available for evidence, because midPoint will hold its own audit history from cutover onward. Verify that the exported records cover the agreed date range by checking first and last timestamps and comparing record counts with the OIG reports. Store a hash of each export file so later changes can be detected.
Inventory custom code and connector versions
List every custom Java plug-in, adapter, scheduled task, event handler and custom workflow step, together with each connector's name, version and target system. Note which connectors are vendor-supplied and which were built or modified by your team, since the second group will need a rewrite or an existing ConnId connector. Verify the inventory by matching it against the connector list in the OIG console and the deployment directory on the server, and flag any item that appears in one list but not the other. The output is the input for the connector mapping work in the migration plan.
Reconcile the export against the source
Compare the counts of exported objects, such as resources, process definitions, roles and lookups, with the counts shown in the OIG console for the same baseline. Check that every XML file parses, that no object referenced by a dependent entity is missing, and that account totals still match the targets after the freeze. Hold a short review with the owners of each target system to confirm that the account numbers are correct. The step is complete when the differences list is empty or each item has a named owner and a recorded decision.
Sign off the export package
Assemble the baseline record, both XML exports, the extraction outputs, the audit and certification files, the inventory and the reconciliation report into one package with an index. The application owner, the IAM lead and the compliance contact sign the index, and the package is stored in a restricted repository with access logs. Confirm with the team that will run the midPoint build which parts they will use first, so gaps can be fixed before the source environment changes.
How to verify that the export is complete enough to migrate from
The export is only useful if you can prove it is complete before the Oracle Identity Governance environment is switched off, so the first task is to agree acceptance criteria with the business owners of each connected system. Write down which object types must match (resource definitions, roles, policies, approval workflows, reconciliation schedules and lookup tables), which target systems must reconcile, and what counts as an acceptable gap. Keep the source environment running, including its WebLogic domain, SOA Suite and Oracle Database, until every check in that agreement has passed. A configuration export captures design, not the state of the estate, so a green result on the XML alone does not prove the migration will work.
Compare object counts between OIG and the export for each artifact type, then sample individual records and inspect their attributes, mappings and dependent entities by hand. Pay attention to the optional dependent entities you selected in the wizard, because anything you left out will be absent from the file without any warning. For identity and account data, reconcile totals against each connected target system: count accounts and entitlements in OIG, count them in the target directly or through its own reporting, and explain every difference. Confirm that the audit trail and certification history you need for the retention period are extracted separately, since the configuration file does not carry them.
Ask someone outside the original project to read the XML and walk through it without help from the people who built the deployment. If they cannot tell what a resource connects to, which role grants which access or where an approval step lives, the file is not yet a usable migration record, even if it is technically complete. Record every remaining gap in a single register with its owner, the reason it exists, the risk it carries and the decision needed to close it, such as rebuilding a custom approval process or accepting that a historic certification campaign will not be migrated. Share that register with the business owners and get their sign-off before anyone plans the decommissioning date.
Who runs which part of the export
The OIG administrator runs the Export Configuration wizard in the Oracle Identity System Administration console and is responsible for what the resulting XML contains. Because the wizard exports configuration artifacts with optional dependent entities, the administrator decides which dependencies to include and records those choices so the export can be reproduced later.
- Inputs: the OIG version and environment in use, the list of artifact types to export (resources, lookups, process definitions, roles, policies and scheduled tasks), and the decision on dependent entities.
- Outputs: the exported XML file, a short export log, and a mapping sheet that names each resource, role and approval process the XML contains.
- Approvals: sign-off from the IAM owner on the artifact list, and a documented record of who ran the export and when.
- Constraints: the XML describes configuration only. Users, account links, reconciliation history and audit records are not part of it and must come from the other groups.
Check that the XML is stored under the same change control as the source environment, and that a second person has reviewed it before anyone uses it as migration input.
The database team performs the extracts that the configuration export does not cover. These include user identities, account links to target systems, role assignments, pending requests and audit tables in the OIG schema. Extraction runs against the production database or a restored copy, so it falls under the same change control and access rules as any other production data read.
- Inputs: a written extraction scope listing schemas, tables and date ranges, read-only database credentials issued for the task, and the change ticket that authorizes the work.
- Outputs: extract files with row counts and checksums, a record of the query or tool used, and a note on any data masked or excluded.
- Approvals: change approval from the database owner, and data protection approval for personal data leaving the production boundary.
- Controls: store extracts encrypted in the organization's own storage, restrict access to named staff, and set a retention date for each copy.
Confirm with the database owner which schema version and table names apply to your OIG release, since they vary and the vendor documentation is the authoritative reference.
The audit or compliance team owns the evidence that controls operated during the period under review. Access certification records, segregation of duties decisions, attestation history and audit logs must stay retrievable after OIG is retired, because the auditors will ask for them whether or not the platform still runs. This team defines what evidence is needed before the export starts.
- Inputs: the list of controls and assessments in scope, the retention requirements set by policy or regulation, and the date range of evidence needed.
- Outputs: an evidence inventory that maps each control to the exported file or extract that supports it, and a retention plan for archived copies.
- Approvals: sign-off on the evidence inventory and on the retention period, recorded before the OIG environment is decommissioned.
- Controls: hash archived files, keep a chain of custody record, and document any gap where evidence cannot be exported.
Agree with your external auditor which formats they will accept. DeployOpen prepares systems and evidence for assessment, but the auditor or certification body decides what is sufficient.
Application owners know which target systems the exported resources point to and which workflows the business depends on. They confirm that the connector configuration in the XML still matches the live system, and they identify the approval processes that must be reproduced in midPoint. Their input is needed before anyone maps the XML to midPoint objects.
- Inputs: the resource list from the export, current connection details and service accounts for each target, and documentation of approval flows and escalation paths.
- Outputs: a confirmed list of connectors and target versions, the approval steps each workflow should keep, and a list of resources that are retired or out of scope.
- Approvals: written confirmation from each application owner for their resources, and acceptance of any change to the approval path.
- Checks: verify with the vendor or each system's documentation which connector a target needs. midPoint connects through the ConnId framework, and the connector catalog varies in support status.
Illustrative example: a directory resource that the XML labels with one connector may need a different connector in midPoint, which the owner should confirm before the mapping is built.
What to plan before the Oracle renewal or termination date
The export is the first step, but the timing around it is set by your Oracle agreement, not by the export itself. The four to six decisions below determine whether the export is useful evidence or an incomplete snapshot when the contract ends.
Set the export completion date
Work backward from your notice and termination dates to fix the date by which the configuration export, the identity and account extracts and the audit data must all be complete. Treat the export as a dated snapshot, because the environment keeps changing after it is taken. Confirm the notice period and renewal terms in your own Oracle agreement, since this page does not supply them, and agree the cut-off date with the business owners of each connected application.
Keep the source read-only for audit
Decide how long the Oracle environment stays available after cutover so that auditors and investigators can query historical approvals, certifications and provisioning events. Ask whether your agreement allows read-only access after termination and what it would cost to keep the WebLogic, SOA Suite and database tier running. If it does not, the exported audit data becomes the only record, so its format and integrity need to be checked before the environment is switched off.
Name the records owner for personal data
Exported identity and account data contains personal information, so someone in legal, privacy or records management must approve where the extracts are stored, who can read them and how long they are kept. Agree this before the first extract runs, not after. The owner should also confirm whether any retention obligations apply to historical access records that must be kept after the environment is retired.
Plan around Oracle support and patch windows
Find out which Oracle support and patch obligations remain in force until termination, and whether Oracle security patches or quarterly updates will be applied during the project. Schedule the export so it does not coincide with a patch window that could change the schema or the configuration. Record the version and patch level at the time of export, because that information will be needed to interpret the artifacts later.
Choose parallel run or cutover
Decide early whether midPoint will run alongside OIG against the same targets for a period, or whether it takes over in a single cutover. A parallel run needs both platforms licensed and operated for longer, while a cutover depends on a tested reconciliation and a rollback path. The choice affects how long the Oracle contract must be extended, so it should be made with the renewal terms in front of you.
Questions buyers ask before exporting Oracle Identity Governance
Can our own team run the Oracle Identity Governance configuration export?
Yes, in most organizations an internal OIG administrator can run the Export Configuration wizard, because it is a built-in console function. The wizard produces an XML file of configuration artifacts, with optional dependent entities. That file is a starting point, not a complete inventory. Identity records, account links, reconciliation history and audit data sit outside it and must be extracted separately, usually with read-only database queries. Confirm with your Oracle support contract and your own OIG version which export options are available to your administrators before you plan the work.
What makes an OIG export harder or longer to prepare?
The effort follows the size and shape of the deployment. The main drivers are:
- The number of connected target systems and the connector versions behind them
- Custom Java code, scheduled tasks and event handlers that the export does not explain on its own
- The volume of audit history you decide to keep, and how much of it is consistent
- Data quality, such as orphaned accounts, duplicate users or roles with no owner
Each driver adds analysis before any migration decision. Ask for a written count of connectors, custom components and audit tables during scoping, because those counts shape the plan more than the export file size does.
What access and people does the export need from our side?
The team needs three things. First, administrator access to the OIG console so the export can be run and checked against the live configuration. Second, read access to the OIG database schemas, so identity, account and audit data can be queried without changing anything. Third, a named business owner for each role, entitlement and approval workflow, because the XML shows how something is configured but not why it exists or who still needs it. Agree on who signs off each role before the export starts. Without owners, roles are often carried into midPoint unchanged, including the ones nobody uses.
How long does a complete export and analysis take to plan?
Plan this as a phase with its own deliverable rather than as a single export step. The duration depends on the drivers listed above: connector count, custom code, audit volume and data quality. Ask a provider to show how each driver was assessed and what assumptions the timeline depends on. Your own inventory of roles, connectors and approval processes will give the most reliable input. DeployOpen plans this work through a written, fixed scope, so the timeline and deliverables are agreed in writing before work starts.
Do we need a consultant for the export, and what should a fixed-scope quote include?
A consultant is not required to run the wizard, but an export alone rarely answers the migration questions. Someone must interpret the XML, map resources and roles to midPoint concepts, and confirm what the audit data is needed for. A fixed-scope quote should state the systems covered, the export and extraction method, the data sets included, the handling of custom code, the deliverables (such as an inventory and a mapping document), who approves them, and what is excluded. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for each deliverable to be listed separately.
What changes in the export if we later move to midPoint?
The export is useful in both cases, but its role changes. The XML documents what OIG does, which helps you decide what midPoint must reproduce. It does not convert into midPoint objects. Connectors must be matched to ConnId-based connectors, and each OIG resource becomes a midPoint resource with its own configuration. Approval processes must be redesigned in midPoint's workflow model. The extracted identity and audit data also needs a target format and a retention decision. Confirm the connector list against the midPoint connectors documentation early, because a missing connector changes the plan more than any other gap.
How DeployOpen scopes and delivers an OIG export and exit
DeployOpen treats the configuration export as the first deliverable of a written, fixed-scope engagement, not as a standalone file handover. We inventory what the Export Configuration wizard produces, extract the identity, account and audit data it does not cover, and turn both into a documented baseline for the midPoint design.
How we scope
- Agree in writing which OIG environments, connected targets and workflows the export analysis covers.
- Confirm which dependent entities are included in the export and which must be extracted separately.
- Define who owns the export files, extraction scripts and the resulting inventory before work starts.
How we build
- Parse the exported XML into an inventory of resources, roles, lookups and approval processes.
- Script extraction of identity, account, entitlement and audit data from OIG and its database.
- Map each inventory item to a midPoint object type, connector or open item for review.
How we hand over
- Deliver a documented inventory, gap register and data extraction runbook for your team to keep.
- Store extracted data in agreed locations with access limited to the named project roles.
- Walk your architects and governance owners through the findings and the open decisions.
How we support
- Offer ongoing support for the export baseline as a retainer when the migration timeline changes.
- Re-run the export and inventory checks before cutover so the baseline matches current OIG state.
- Confirm with your independent auditors which exported evidence they will need for their own assessments.
