Oracle Database Migration Service (DMS) on OCI is the managed cloud service for migrating Oracle databases into OCI and heterogeneous migrations from Oracle to open-source databases like PostgreSQL and MySQL. The service's billing structure is straightforward — the commercial complexity lies in understanding the Oracle license implications of migration source and target configurations, maintaining compliance during the transition period when both source and target databases are simultaneously active, and whether OCI DMS genuinely supports your Oracle license reduction strategy or creates compliance gaps that expose you to audit risk.
Oracle Database Migration Service (OCI DMS) is a managed cloud service that orchestrates the movement of Oracle databases from on-premise or other cloud environments into OCI targets — Oracle Autonomous Database, Oracle Database on OCI compute instances (BYOL), and Oracle Database Cloud Services (DBCS). OCI DMS also supports heterogeneous migrations from Oracle Database to open-source targets including PostgreSQL on OCI and MySQL HeatWave on OCI.
OCI DMS billing is compute-based: migration jobs are executed on managed compute infrastructure that Oracle provisions automatically, and the customer is billed for the OCPU-hours consumed by the migration job execution. A migration job's duration — and therefore its total compute cost — depends on the database size, network bandwidth between source and target, the complexity of schema and data transformations required (particularly for heterogeneous Oracle-to-PostgreSQL migrations), and whether an initial data load migration or a continuous replication migration is configured.
OCI DMS supports two migration modes that have different cost profiles. Offline migrations perform a one-time data extraction, transfer, and load — the migration job runs for the duration of the initial load, then completes. The compute cost for an offline migration of a 5TB Oracle database over a 1 Gbps network connection might be 8–12 hours of migration compute, generating a modest one-time DMS charge. Online migrations (logical migrations with continuous replication) use Oracle GoldenGate or LogMiner-based change data capture to replicate ongoing database changes from source to target, allowing near-zero-downtime database cutovers. Online migrations consume compute for extended periods — the initial load plus the ongoing replication phase, which may run for days or weeks during testing and validation. The extended duration of online migration compute consumption can result in meaningful DMS charges for large-scale database migrations.
Online Migration Duration Management: Online OCI DMS migrations that run for extended periods — particularly those where the cutover date is delayed due to application testing issues or business constraints — continue accumulating compute charges throughout the replication phase. Establish a clear migration cutover deadline before starting an online migration job and treat slippage as a commercial cost, not just a project timeline concern.
Enterprises migrating Oracle databases from on-premise to OCI using BYOL — bringing their existing perpetual Oracle Database licenses to cover OCI compute instances — must maintain their current license entitlements during the migration. The OCI DMS orchestration service does not change or create Oracle Database license requirements: the source Oracle Database and the target Oracle Database on OCI are both Oracle Database deployments that require valid Oracle license entitlements.
During an online migration's replication phase, both the source database (on-premise) and the target database (OCI BYOL instance) are simultaneously active. Oracle's license metric for on-premise Database Enterprise Edition is Processor (per physical core, with the Core Factor Table applied). Oracle's license metric for OCI BYOL is OCPU-based. An enterprise migrating a 4-physical-socket server (12 cores per socket, Intel x86 at 0.5 Core Factor) — representing 24 Processor licenses — to an OCI compute instance provisioned at 24 OCPUs must have 24 Processor licenses for the target BYOL deployment. If those 24 Processor licenses are the same licenses being "moved" from the on-premise deployment to OCI, then during the migration replication period, the enterprise is technically running 48 Processor-equivalent deployments against 24 licenses.
Oracle's position on license continuity during database migration is not straightforward. Oracle's BYOL policy allows customers to use on-premise licenses on OCI, but it does not explicitly authorize running both the source and target databases simultaneously with the same license set as a migration right. Enterprises conducting LMS audits during or shortly after an Oracle database migration to OCI may face questions about the license coverage of the source environment during the period when both systems were active. The conservative compliance position is to have sufficient license entitlements to cover both the source and target during the migration window — or to negotiate an explicit migration right with Oracle's license management team before initiating the migration.
Our Oracle Compliance Review service includes a pre-migration license position assessment — verifying your entitlements cover both source and target during the migration window and identifying any compliance gaps that need to be resolved before an Oracle LMS audit opportunity arises.
The highest-value use of OCI DMS for many enterprises is heterogeneous migration from Oracle Database to PostgreSQL — either OCI PostgreSQL (Oracle's managed PostgreSQL service) or self-managed PostgreSQL on OCI compute. The strategic motivation is Oracle license cost reduction: PostgreSQL is an open-source database with no license fees, and a successful migration eliminates the Oracle Database Enterprise Edition license cost and the 22% annual Oracle support cost for the migrated databases.
OCI DMS supports Oracle-to-PostgreSQL heterogeneous migrations through its schema conversion and data migration capabilities, supplemented by Oracle's SQL Developer with Migration Workbench for schema and code conversion. The migration involves three distinct phases: schema conversion (Oracle DDL to PostgreSQL DDL, Oracle procedural code PL/SQL to PL/pgSQL), data migration (initial data load via OCI DMS), and application validation (verifying application behavior against the PostgreSQL target). The complexity and timeline of each phase depends on the database's use of Oracle-specific features.
The Oracle license cost reduction from an Oracle-to-PostgreSQL migration is only realized when the Oracle source database licenses are formally terminated — Oracle support contracts cancelled, licenses removed from the CSI (Customer Support Identifier), and Oracle's records updated. Until this administrative termination is completed, Oracle continues charging 22% annual support even for databases that have been migrated away. Enterprises that complete the technical migration but delay the support cancellation — due to post-migration validation periods, contractual minimums, or administrative delays — continue paying Oracle for licenses they are no longer using.
Oracle's contracting process for support termination requires formal written notice and is subject to the notice period terms in your Oracle support contract — typically 30–90 days. Oracle's sales teams may use the support renewal conversation as an opportunity to explore whether the migration is complete and whether alternative Oracle products (Oracle Autonomous Database, Oracle Database Free Edition upgrades, additional Java SE subscriptions) can be introduced. Independent advice before initiating the support termination process ensures you approach that conversation with a clear position on what you are entitled to terminate and Oracle's playbook for retaining support revenue. See our Oracle Support Reduction service for how we navigate these negotiations.
The case study of an automotive manufacturer's Oracle-to-PostgreSQL migration on this site illustrates how properly structuring the migration with a clear license exit strategy delivered $7M in Oracle cost reduction over 5 years — including both license and support savings — after migrating 14 Oracle databases to PostgreSQL using OCI DMS.
Oracle Zero Downtime Migration (ZDM) is Oracle's free CLI-based tool for migrating Oracle databases to OCI targets with minimal downtime. ZDM is distinct from OCI DMS — it is a downloadable tool rather than a managed cloud service, and it uses Oracle Data Pump, Oracle Recovery Manager (RMAN), or Oracle GoldenGate for data transfer depending on the migration method selected. ZDM is commonly used for Oracle-to-Oracle BYOL migrations where enterprises want more control over the migration process than OCI DMS provides.
ZDM itself is provided at no additional license cost as part of Oracle's cloud migration program. However, the migration method ZDM uses may have license implications:
Oracle's RMAN and Data Pump are included with Oracle Database Enterprise Edition — no separate license is required. GoldenGate, however, is priced separately at Processor metric or Named User Plus metric, and its license cost for a migration-only use case should be evaluated against the alternative of using OCI DMS's managed replication capability (which handles the change data capture internally without requiring a customer-side GoldenGate license).
The period between starting an online migration replication and completing the cutover to the target database — during which both the source Oracle Database and the target Oracle Database are simultaneously processing transactions — is the highest-risk compliance window in any Oracle database migration. Oracle's LMS team has issued compliance findings against enterprises that ran source and target databases simultaneously without sufficient license entitlements to cover both environments.
The compliance risk is highest for enterprises migrating databases with Oracle-specific features enabled. A source Oracle Database EE deployment with Diagnostics Pack, Partitioning Option, and Advanced Security Option generates separate license requirements for each enabled option. The target OCI BYOL deployment running the same Oracle Database version with the same options also requires the same option licenses. During the dual-active period, technically both instances are running licenceable Oracle software — both require license entitlements.
Pre-Migration Compliance Assessment: Before starting any Oracle database migration involving an online replication period, conduct a formal assessment of the source database's deployed Oracle options and features. Identify every licenceable Oracle product active in the source environment — not just the Database edition, but every management pack, database option, and Oracle product that is enabled or has been used. Your target environment must be licenced for the same product set during the dual-active period. Discovering an unlicenced Diagnostics Pack or Partitioning Option in the source environment after Oracle LMS has initiated an audit following the migration is a far worse outcome than resolving the compliance gap before migration begins.
Our Oracle License Optimization service identifies which Oracle Database options can be disabled before migration — legally reducing your license footprint and the target BYOL license requirements. Disabling unlicenced options before migration eliminates the compliance gap and reduces the cost of the BYOL deployment.
Oracle database migration — whether to OCI or to open-source alternatives — is one of the most effective mechanisms for reducing Oracle license exposure, but only when the migration strategy is designed with license exit as an explicit goal from the outset. Enterprises that migrate databases to OCI BYOL without a defined license optimization plan frequently discover that their Oracle total cost of ownership on OCI is similar to or higher than on-premise, because they have replicated their on-premise license footprint into OCI without taking the opportunity to right-size.
Oracle Database migrations create a natural opportunity to conduct a comprehensive assessment of which Oracle Database options and management packs are actually required by the target deployment. Many enterprises run Oracle Database EE with Diagnostics Pack, Tuning Pack, and other management packs enabled by default — packs that the DBA team may not actively use but that are enabled because they were included in the original database installation. Disabling these options before migrating to OCI BYOL reduces the option license count required for the target deployment, lowering the license cost of the BYOL instance.
This rationalization requires careful analysis — disabling Diagnostics Pack means losing access to AWR (Automatic Workload Repository) and ASH (Active Session History), which are features some performance monitoring tools depend on. The decision to disable any Oracle option must be preceded by a documented assessment of what depends on that option, signed off by the application and DBA teams. Our Oracle Compliance Review service includes this feature dependency mapping as part of pre-migration license optimization.
Migrating from on-premise to OCI BYOL also creates an opportunity to evaluate whether the Named User Plus (NUP) metric would result in lower license counts than the Processor metric for the target OCI deployment. On-premise Oracle Database EE at Processor metric must be licenced for all physical cores subject to the Core Factor Table. On OCI BYOL, the Processor metric is based on OCPUs — and Oracle permits BYOL Processor-metric licenses to cover OCI at a 2:1 OCPU-to-Processor-license ratio (one Processor license covers two OCPUs on most OCI compute shapes). This means a database server using 48 Processor licenses on-premise can be covered by a 24-OCPU OCI instance under BYOL. Right-sizing the OCI instance during migration — rather than provisioning the same capacity as the on-premise deployment — maximises this BYOL ratio benefit.
Oracle's LMS team views database migration periods as a license audit opportunity. The combination of new OCI deployments (visible to Oracle through your OCI tenancy usage data, which Oracle has access to as part of its cloud management functions), the termination of on-premise support contracts, and gaps in formal license transfer documentation creates conditions that Oracle's audit team can exploit.
Oracle's most common post-migration audit claims include: the source environment was not fully decommissioned within the claimed timeline (Oracle may claim the source ran in production after the migration was declared complete, requiring license coverage for both periods); Oracle Database options were active in the source environment that were not included in the BYOL coverage declaration; the OCPU count of the OCI BYOL deployment exceeds the Processor license count divided by two; and Oracle GoldenGate was used for migration replication without an appropriate license. Each of these claims requires evidence-based rebuttal — which is why independent compliance documentation throughout the migration process is essential.
Our Oracle Audit Defense service has successfully defended against post-migration audit claims by demonstrating decommission documentation, feature usage records from the source environment, and BYOL deployment configurations that were clearly compliant with Oracle's published BYOL policy. The key to defending a post-migration audit claim is the same as defending any Oracle audit claim: contemporaneous documentation of what was running, when it was decommissioned, and what licenses covered each deployment at each point in time.
Oracle's migration tools and OCI DMS are genuinely capable services for moving databases to OCI. The commercial risk is not in Oracle's migration tooling — it is in Oracle's agenda for the migration outcome. Oracle's preferred outcome for an Oracle-to-Oracle migration is that the customer increases their OCI Universal Credits commitment (to cover the BYOL OCPU costs), maintains Oracle Database support, and potentially adopts additional Oracle cloud database services (Autonomous Database, Exadata Cloud Service). Oracle's preferred outcome for an Oracle-to-PostgreSQL migration is that it doesn't happen, or if it does, that Oracle can retain support revenue through other Oracle product lines (Java SE subscriptions, OCI infrastructure, Fusion Cloud modules).
An independent migration strategy assessment — before engaging Oracle's cloud migration team or accepting Oracle's migration tooling recommendations — gives you the commercial clarity to use OCI DMS and ZDM on your terms rather than Oracle's. That means: knowing which databases are realistic PostgreSQL migration candidates versus which genuinely require Oracle EE features, understanding the BYOL license economics for each migration target, having a defined license exit plan for every migrated Oracle database, and knowing Oracle's likely audit posture in your specific situation.
The $500M+ in verified client savings our team has delivered includes a significant component from migration-based license reduction — enterprises that used Oracle database migration to Oracle or open-source targets as a strategic mechanism for right-sizing their Oracle license estate, not just a technical exercise in moving data from one place to another.
Migration compliance updates, OCI BYOL policy changes, and Oracle commercial tactics — direct to your inbox. Independent analysis for Oracle enterprise buyers.
We assess your migration compliance position, BYOL economics, and license exit strategy before you start — ensuring the migration delivers cost reduction rather than creating audit exposure. Not affiliated with Oracle Corporation.
Related Resources