Who this is for
The identity or middleware lead running Oracle Access Management, Identity Governance and a directory tier on Fusion Middleware 12c, particularly where that identity estate fronts WebCenter Content, Imaging, EBS or Fusion. If the WebCenter and SOA tiers are already in a 14c program, this is the tier that has to move with them.
The timeline
Oracle Fusion Middleware 12c (12.2.1.4) — the platform under IAM 12c — reaches the end of Premier Support in December 2026 on the standard Lifetime Support schedule. Extended Support runs to December 2027 and includes eligible updates, fixes and security patches under Oracle’s support policy, subject to product exceptions and certification limits. For an identity tier that is, by definition, the security boundary, the difference between those tiers matters more than it does for most components.
Oracle Identity and Access Management 14c includes the 14.1.2.1 product releases. Oracle’s April 2026 Lifetime Support Policy lists the IAM 14.1.x families through December 2030 for Premier Support and December 2033 for Extended Support. Confirm the entry, exceptions and patch requirements that apply to each installed product.
What IAM 14c includes
| Component | Role | What carries into 14c |
|---|---|---|
| Oracle Access Management (OAM) | Single sign-on, authentication, authorization, risk-aware access | WebGates and agents, authentication schemes, authorization policies, federation trust relationships |
| Oracle Identity Governance (OIG) | Identity lifecycle, provisioning, access request and certification, connector-based reconciliation | Governance workflows, approval policies, connectors, custom event handlers and adapters |
| Oracle Unified Directory (OUD) | The elastic LDAP directory, storage and proxy tier | Directory data, schema, access control, replication topology |
| Oracle Internet Directory (OID) | The database-backed LDAP directory | Directory data and dependent integrations, alongside or in place of OUD |
Topology matters. Oracle’s OUD installation guide distinguishes a standalone directory from a collocated, WebLogic-managed directory. OUDSM has its own WebLogic and ADF requirements. Inventory the directory and its management interface separately, then check the certified database, operating system and JDK for each component.
The 12c PS4 to 14c upgrade, step by step
1. Confirm the 12c PS4 baseline
Confirm the installed release and patches for each identity product. For OUD, Oracle’s upgrade guide documents 12.2.1.4 to 14.1.2.1 and requires preserving the standalone or collocated topology. Use the corresponding product guide for OAM, OIG and OID; one IAM-wide procedure is not sufficient.
2. Read the existing identity estate
Document every OAM-protected application and agent registration, every OIG connector and customization, the OUD and OID directory trees and replication topology, and every downstream dependency: EBS, Fusion, WebCenter, custom applications. Anything that needs different handling on 14c is surfaced here, before change begins.
3. Prepare the required target runtimes
Prepare WebLogic and Infrastructure where the selected identity component requires them. Prepare standalone OUD independently when that is the source topology. Check the exact product prerequisites and certification matrix before installation. The WebLogic 14c upgrade guide covers the shared server tier.
4. Upgrade schemas and configuration
Follow the selected product’s documented sequence for binaries, schemas, configuration and directory data. Establish whether each step changes shared state and what outage it requires. A separate Oracle Home or target server alone does not preserve rollback after schemas or directory data have changed.
5. Validate integrations and directory data
Re-test OAM single sign-on and federation flows, OIG provisioning, reconciliation and approval workflows, and OUD and OID reads, writes and replication. Confirm that every downstream application authenticates and authorizes identically against the 14c estate.
6. Parallel run, UAT, cutover
Where out-of-place is used, run 12c and 14c side by side through UAT. Validate every SSO path, governance workflow and directory dependency, and hold a tested rollback position through cutover.
Component by component
Oracle Access Management. SSO integrations, WebGate and agent registrations, authentication schemes, authorization policies and federation trust relationships are re-established on OAM 14c, and risk-aware and adaptive authentication configuration is validated. The test that matters is simple to state: every application that trusted 12c OAM authenticates identically against 14c.
Oracle Identity Governance. Access request, approval, certification and reconciliation workflows, target-system connectors and any customizations are migrated and validated against 14c. Connector versions are checked for 14c certification; custom event handlers, adapters and UI customizations are reviewed for compatibility. The assessment separates what transfers as-is from what needs rework.
Oracle Unified Directory and Internet Directory. Directory data, schema and access control are carried into the 14c directory tier, and the replication topology is re-established and validated end to end. Whether the estate runs OUD, OID or both, directory behavior has to be proven identical before dependent SSO and governance flows are cut over.
In-place or out-of-place
Treat these labels carefully: installing into a new Oracle Home is different from creating an independent copy of the whole identity estate. Choose a supported procedure for each product and topology, rehearse on isolated copies, and define how database and directory changes will be restored or reconciled. Routing traffic back is sufficient only when the old environment and its data remain compatible and current.
What typically needs rework
Product upgrade tools handle documented portions of the move. The inventory must also cover:
- Custom OAM authentication plugins and custom login pages, which are compiled or templated against 12c interfaces and need to be rebuilt and re-tested on 14c.
- OIG custom event handlers, scheduled tasks and adapters, particularly anything compiled against 12c APIs or referencing internal packages.
- WebGate and agent versions on the OHS tier in front of WebCenter, EBS and custom applications, which must be at a release compatible with OAM 14c.
- LDAP authenticators in dependent WebLogic domains — the Content Server, Imaging, Capture and SOA domains that use OUD or OID as their identity store — whose provider configuration and group-to-role mappings are validated against the 14c directory.
- Certificates, keystores and trust stores for federation, WebGate-to-OAM and directory TLS, which are re-issued or re-imported into the 14c estate and expire on their own schedule.
- Load-balancer and virtual-host definitions, SSO cookie domains and logout URLs, which point at hostnames that change in an out-of-place build.
- Directory schema extensions and custom attributes, which must exist in the 14c directory before any data is loaded or replicated.
None of these are surprises if the inventory in step 2 was done properly. They become surprises when it was not.
Where the identity tier meets the WebCenter estate
In many estates OAM fronts the WebCenter Content and Imaging user interfaces, and OUD or OID is the identity store behind the WebLogic security realm that Content Server, Imaging, Capture and the SOA domain share. That means the identity upgrade is not independent of the WebCenter 14c upgrade: the WebGates on the OHS tier, the authentication providers in each WebLogic domain, and the group memberships that drive Content Server security groups and Imaging application permissions all have to be re-validated against the 14c identity estate. Sequence the identity tier so it is proven before the WebCenter domains cut over, or run both on 12c until the identity tier is ready — but do not cut WebCenter to 14c against an identity tier still mid-upgrade.
How ECMWorks does this
We read the running identity estate directly — OAM policies, OIG connectors and customizations, directory topology and downstream dependencies — and produce a component-specific plan. Delivery prepares the required runtimes, validates SSO, governance workflows and replication, and rehearses cutover and recovery. Where identity protects WebCenter, we coordinate both programs around the tested integration paths.