Oracle Data Integrator 12c to 14c: the repository upgrade

Who this is for

The administrator who owns the ODI master and work repositories and the load plans that run against them, and the IT director sequencing ODI inside a wider Fusion Middleware 12c-to-14c program. If your integration jobs feed the ERP, the warehouse or the reporting layer, this is the piece of the program where a mistake is not undone by trying again.

The dates and the target release

The rest of the 12c family is on the same timeline, and the full table is on the support dates tool.

What makes this upgrade different

The mechanics of the Upgrade Assistant run are straightforward. The risk sits in four places.

The repository upgrade is one-way. The Upgrade Assistant upgrades the master and work repository schemas in place at the schema level. There is no downgrade path. A verified, restorable backup of both schemas taken immediately before the run is the only way back, which makes the backup and its restore test the most important planning step in the project.

Topology carries real dependencies. Data servers, physical and logical schemas, contexts and connection definitions all move forward with the repository, and each has to be validated against the 14c runtime so that mappings resolve to the right physical targets afterwards.

Agents and scenarios need re-validation. Standalone and Java EE agents, load plans, packages and generated scenarios are checked against the 14c runtime. Scenarios generated under 12c are regenerated and re-tested so scheduled and event-driven jobs behave identically after cutover.

ODI sits inside a wider estate. It usually shares WebLogic domains, database tiers and integration points with the rest of your Fusion Middleware footprint. The ODI upgrade belongs inside the broader 12c-to-14c sequence rather than on its own.

The procedure, step by step

1. Confirm the source version and inventory the estate. Verify ODI is on 12.2.1.4 (or 12.2.1.19). If it is on an earlier 12c update, that move comes first. Inventory the master and work repositories, the topology definitions, agents, load plans, packages, mappings, and every scenario and schedule that depends on them.
2. Back up the master and work repositories. Take a verified backup of both schemas before anything else is touched, and confirm it restores cleanly in a non-production environment. Because the repository upgrade cannot be reverted, this backup is the recovery path.
3. Install Oracle Data Integrator 14c (14.1.2). Install the ODI 14c binaries and stand up the supporting Fusion Middleware 14c components. This is a full upgrade to a new release, not a patch set applied over 12c.
4. Upgrade the repositories with the Upgrade Assistant. Run it against the master and work repositories to bring the schemas to 14c. This is the one-way step, and the reason step 2 is non-negotiable.
5. Validate topology, agents and scenarios. Reconfigure and validate the topology so data servers and logical schemas resolve correctly. Reconfigure standalone and Java EE agents against the 14c runtime, regenerate scenarios, and re-run representative load plans and packages end to end.
6. Parallel-test and cut over. Run representative integration jobs against the upgraded environment, compare outputs to the 12c baseline, and rehearse schedule and agent behaviour before cutover. Promote to production only once every critical mapping, load plan and scenario has been validated.

Rehearse it before you run it for real

Because step 4 is one-way, the only sensible way to learn how your estate behaves under the Upgrade Assistant is on a copy. Restore the backup from step 2 into a non-production database, point a throwaway ODI 14c install at it, and run the whole procedure there first. That rehearsal earns three things you cannot get any other way.

A tested restore. A backup you have never restored is a hope, not a recovery path. Restoring it to build the rehearsal environment proves it works and tells you how long a real rollback would take.

A baseline to compare against. Before the rehearsal, capture what the 12c environment actually does: which load plans and packages run on which schedules, how long they take, row counts and output checksums for the targets they write, and which agents pick up which jobs. After the rehearsal upgrade, run the same jobs on the copy and compare. A mapping that resolves to the wrong physical schema through a context change, or a scenario that was never regenerated, shows up as a diff here rather than as a production incident.

A real timeline. The rehearsal tells you how long the Upgrade Assistant takes against your repository sizes, how much reconfiguration the topology and agents need, and how many scenarios have to be regenerated. That is the number the production cutover window is built from, not an estimate.

What goes into the inventory that feeds all this: both repositories (and every work repository, if there is more than one), the topology by context so that development, test and production resolve to the right data servers, every standalone and Java EE agent with the domain it runs in, every load plan and package with its schedule, and every scenario with the mapping it was generated from. Anything scheduled outside ODI that triggers an ODI job belongs on the list too, because it will need re-pointing at the 14c agents.

Agents and schedules: the piece that gets forgotten

The repositories get the attention because the upgrade is one-way. The agents are where the quiet failures live. Java EE agents run inside a WebLogic domain, which ties them to the WebLogic 14c work; standalone agents have their own installation to redo on the 14c side. Neither kind is "upgraded" in any meaningful sense: they are stood up again against the 14c runtime, re-pointed at the upgraded repositories, and re-tested for connectivity to every data server in the topology.

Then the schedules. Anything scheduled inside ODI moves with the repository, but it still has to be assigned to a 14c agent and confirmed to fire. Anything scheduled outside ODI, an enterprise scheduler or a cron job that calls an agent, has to be re-pointed by hand. The two failure modes we watch for at cutover are the job that never runs, because it was still bound to a 12c agent that is now off, and the job that runs twice, because the 12c agent was left on. Run the first production cycle in a quiet window with the 12c agents stopped and someone watching the operator log.

Sequencing ODI with the rest of the estate

Treating ODI as a standalone project is how shared WebLogic domains get upgraded twice and integration points get tested once. The ODI upgrade is sequenced with the WebLogic 14c upgrade it usually runs on, and with whatever SOA and WebCenter work sits on the same December 2026 date, so that domains, database tiers and integration points move as one plan. The whole-stack view, component by component, is on the Fusion Middleware 12c end-of-support hub.

Timelines depend on repository size, the number of mappings, load plans, agents and scenarios, and how tightly ODI is coupled to the rest of the estate. Scoping establishes the specific timeline for your environment before anyone commits to a cutover date.

How ECMWorks does this

We begin with a short scoping conversation: your ODI version, repository size, topology and agent setup, and how ODI relates to the rest of your Fusion Middleware estate. From that we size the work honestly and confirm the right delivery approach. Delivery then runs as part of one coordinated 14c plan across the stack: the inventory, the restore-tested backup, the 14c install, the Upgrade Assistant run, the topology and agent reconfiguration, the scenario regeneration, and the parallel test against the 12c baseline, in step with the WebLogic, SOA and WebCenter work on the same timeline.