Teams should inventory the custom connectors, workflows, and certification campaigns that OIG currently governs, then map each one to the control it supports. That tells you which functions must be rebuilt, which can be retired, and which require deeper replacement testing before the support window closes.
What teams should inventory before OIG support ends
Start by building a complete inventory of every Oracle Identity Governance dependency that actually carries business control: custom connectors, approval workflows, certification campaigns, role models, provisioning logic, and any exception handling built around OIG. The point is not to document the product in the abstract, but to expose which identity and access decisions OIG currently enforces so replacement work can be sequenced correctly.
That inventory should be mapped to the control each item supports, such as access certification, entitlement review, separation of duties, or joiner-mover-leaver processing. That gives teams a way to separate core controls that must be preserved from local customisations that can be retired or redesigned.
For teams planning that cutover, the most useful reference is IAM and IGA Basics, which helps frame the difference between identity functions, governance functions, and the workflows that sit between them.
How to decide what gets rebuilt versus retired
Once the inventory is complete, classify each OIG capability into three buckets: preserve, replace, or retire. Preserve means the control still exists in the target state and only its implementation changes. Replace means the control is still required, but the current workflow, connector, or campaign logic will not survive the migration intact. Retire means the process no longer adds value, or duplicates a newer control elsewhere.
The hardest cases are usually custom workflows and certification campaigns, because they often encode local business rules that are invisible until migration starts. Those should be tested earliest, since they are more likely than standard connectors to hide approval dependencies, role assumptions, or stale entitlement logic.
A practical planning aid is Access Reviews and Certification Guide, which aligns well with the need to preserve review intent while redesigning the mechanics.
When role structure is part of the dependency chain, Role Mining and Role Design Guide is useful for deciding whether a migration should carry roles forward, simplify them, or redesign them around a cleaner model.
What makes the support deadline a control-risk issue
Support ending is not only a product-lifecycle event, it is a control continuity problem. If teams leave OIG functions unclassified until late in the program, they risk discovering too late that a certification campaign, entitlement workflow, or connector was the only place enforcing a material access control. That creates a window where identities may still be provisioned, reviewed, or recertified, but the supporting control path is no longer maintainable.
The failure mode is usually not immediate outage. It is a gradual loss of confidence in the control plane, especially if replacement testing starts after business users have already come to rely on the old process. The more customised the governance flow, the greater the chance that hidden dependencies will delay decommissioning or force an unsafe last-minute exception.
For teams that want the governance angle on this transition, IGA Buyer's Guide is a relevant navigation point because it covers the platform features and evaluation questions that matter when replacing a governed identity workflow. The broader lifecycle view in Identity Security Programme Guide also helps teams treat the migration as a programme, not a one-off software swap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OIG migrations often include credential and connector lifecycle decisions. |
| AC-2 — Account Management | OIG commonly governs provisioning, deprovisioning, and access lifecycle control. | |
| AC-6 — Least Privilege | Role and entitlement redesign must preserve least-privilege outcomes during migration. | |
| Recommendation — Map credential-handling dependencies and rebuild rotation and revocation paths before cutover. Preserve account lifecycle controls when replacing OIG workflows. Review role mappings to prevent privilege creep in the target design. | ||
Practitioner Guidance
What to prioritise: Inventory first, then trace each OIG component to the control it supports. If a workflow or campaign cannot be tied to a concrete control objective, challenge whether it still belongs in the target state.
What to verify: Confirm that each critical control has an owner, a replacement path, and a test case before the support window closes. Pay special attention to custom workflows that embed approvals, exceptions, or recertification logic.
Common mistake: Treating OIG as a software upgrade rather than a governance transition. The most expensive failures happen when teams replace the tool but not the control intent, or keep the control intent but fail to rebuild the mechanism that makes it auditable.
Practitioner takeaway: The first job is control mapping, not platform selection, because you cannot migrate identity governance safely until you know which business controls OIG is actually carrying.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org