Oracle Data Integrator (ODI) is licensed as a standalone Fusion Middleware product and is also bundled - often with restricted-use rights - inside Oracle Business Intelligence, Oracle applications, and several engineered systems, which means most estates own ODI in more than one form without realising it. ODI is Oracle's bulk and batch data-integration platform, and its licensing complexity comes less from the metric and more from the many places ODI rights appear. Getting it right means separating what you bought standalone from what arrived bundled, and knowing the boundary of each grant. For the broader framework of Oracle metrics and contracts, start with our complete Oracle licensing guide.
ODI editions and what they include
Historically Oracle offered ODI in more than one packaging. The product most enterprises hold today is Oracle Data Integrator Enterprise Edition, which includes the ELT (extract-load-transform) engine, the declarative design studio, knowledge modules, and the agent runtime. Older estates may still carry legacy SKUs from the Sunopsis acquisition lineage or component licences tied to a specific application. The practical point is that "ODI" on an install report does not tell you which entitlement authorises it - the ordering document does.
The licensing metrics
Standalone ODI is licensed on the same two metrics as most Oracle middleware. The Processor metric counts physical cores running the ODI agents and engine, multiplied by Oracle's core factor for the chip family. The Named User Plus (NUP) metric counts authorised individual users plus non-human-operated devices, subject to per-processor minimums. For unattended, server-to-server batch integration with no human user population, Processor is usually the only defensible metric because there are no countable named users to license. Confirm the current core-factor table for your exact processor before modelling cost - the same x86 server can be 8 or 16 Processor licences depending on the factor applied.
| Acquisition form | Typical right | Boundary |
|---|---|---|
| Standalone ODI Enterprise Edition | Full use | General-purpose integration across any source/target |
| Bundled with Oracle BI Foundation | Often restricted | Integration supporting the BI deployment only |
| Bundled inside an Oracle application | Restricted use | Data movement for that application only |
| On an engineered system | Depends on order | Read the specific ordering document |
The restricted-use grants buyers miss
This is where ODI audits are won or lost. Several Oracle products ship a restricted-use ODI entitlement so the host product can move its own data. The classic example is Oracle Business Intelligence, which has historically included ODI rights limited to populating the BI environment. Those rights are real but bounded: they authorise integration in service of the bundled product, not as a general enterprise integration platform. The moment ODI built under a restricted grant starts loading a data warehouse for unrelated systems, or feeding applications outside the bundle, the usage exceeds the grant and full-use ODI licences are required.
The boundary is the host product, not the software. A restricted-use ODI grant bundled with another Oracle product lets you integrate data for that product. Using the same ODI installation to serve other sources and targets converts it into general-purpose use and triggers full-use licensing. Keep restricted-use ODI mappings and topologies clearly scoped to the host product, and document that scope, so an auditor can see the boundary you are respecting.
Agents, topologies and where cores get counted
ODI's runtime architecture matters for Processor counting. ODI executes through agents - standalone agents or Java EE agents running on WebLogic. Every server that runs an agent performing transformations is in scope for Processor licensing. A common sizing error is licensing only the design-time studio server while leaving production agent nodes uncounted. If the ELT pushes transformation down into the target database (ODI's design philosophy), the target database cores are licensed under your database entitlement, not under ODI - but the agent orchestration nodes still require ODI Processor coverage. Where agents run on WebLogic, confirm the WebLogic rights too; the same restricted-use-versus-full-use question covered in our WebCenter licensing guide applies.
Virtualisation exposure
ODI on a soft-partitioned hypervisor inherits the same exposure as any Oracle program: Oracle's policy counts the physical cores Oracle software could run on across the cluster, not the cores assigned to a particular virtual machine. An ODI agent VM on a large VMware cluster can therefore imply a far larger Processor requirement than the VM's footprint suggests. The mitigation is the same as for the database estate, and the mechanics are detailed in our analysis of Oracle VMware and soft-partitioning risk.
A buyer-side checklist
Before renewing or expanding ODI, answer five questions. How many ODI entitlements do you hold by ordering document, and which are full-use versus restricted? Which installations run under a restricted grant, and is their integration scope still limited to the host product? Which servers run ODI agents, and are all of them counted for Processor? Is any ODI runtime on a virtualisation platform Oracle treats as soft partitioning? And is your chosen metric still defensible given the user population?
ODI in the cloud and as a managed service
Two newer deployment patterns change the ODI licensing conversation. The first is running ODI on infrastructure-as-a-service - your own ODI licences deployed on cloud compute. Here the bring-your-own-licence rules and the way cloud vCPUs map to Oracle's licensing apply, and the count can differ from on-premise cores; confirm the current cloud-computing policy for your provider before sizing. The second is Oracle's cloud data-integration services, which are subscription offerings rather than perpetual licences and sit outside the Processor and NUP model entirely. If you are weighing a move from perpetual ODI to a subscription integration service, treat it as a distinct commercial decision: the subscription removes the perpetual-licence audit surface for that workload but introduces ongoing subscription commitments and a different lock-in profile. Model the multi-year cost of each before assuming the cloud service is automatically cheaper.
Working these through before a renewal turns ODI from an audit risk into a planned line item. For sibling middleware sizing that shares ODI's mechanics, compare Oracle GoldenGate licensing and Data Masking and Subsetting. For a defensible entitlement review before your next Oracle conversation, see our Oracle licensing experts service and the Oracle vendor hub.