Oracle Database Cloud continues to evolve toward a simpler, more consistent portfolio built on modern infrastructure and the ECPU billing metric. As part of this shift, Oracle retired selected Base Database Service (Base DB) SKUs effective July 31, 2026 and is guiding customers toward replacement ECPU-based SKUs. If you’re using one of these retired SKUs, you might be asking, “What does this mean for me? Where am I going to run my workloads now?” Choosing a destination is the first step; planning how to move there comes next.
A database migration rarely hinges on a single technical step. The real challenge is coordinating application dependencies, testing, maintenance windows, budgets, and business priorities without creating unnecessary disruption. A clear plan helps you reduce those struggles. So, plan ahead to skip the last-minute scramble for a smoother, less stressful migration.
Choosing the right replacement
When moving your Base DB workload, you don’t have to replicate your current environment exactly. You can choose the destination that best fits your needs. But if you’re looking for the closest like-for-like options, here are my recommendations:
| Current workload | Recommended destination |
| Base Database Service SKU on VM.Standard.x86 | ECPU-metered Base Database Service SKU on VM.BaseDB.x86 |
| Enterprise Edition – Extreme Performance (EE-EP) | ExaDB-XS |
| OCPU-metered Base Database Service SKU | ECPU-metered Base Database Service SKU on VM.BaseDB.x86 |
These recommendations are a practical starting point, but they aren’t the only destinations available. You can also move to Autonomous AI Database for a more hands-off experience with a fully managed database service with automated routine maintenance. Or you can choose dedicated Exadata infrastructure if your workload requires infrastructure isolation and the ability to use both Exadata and Autonomous on the same infrastructure with the Multi-VM capability. Ultimately the right destination depends on your workload and what you want.
Match the migration method to the workload
After mapping a workload to its new destination, choose a migration method that fits its database architecture and your cutover window.
Pluggable database (PDB) cloning is the recommended path for most migrations that involve an individual PDB. It’s available through the OCI Console and supports all Base DB editions including Standard Edition. You can use a remote clone when a planned outage is acceptable, or a refreshable clone to keep the destination updated and reduce cutover time. The destination DB system has a new hostname and IP address, so make sure to include application connection updates in your plan.
If you’re okay with a longer maintenance window, then backup and restore is a great option. You can restore from either Autonomous Recovery Service (RCV) or Object Storage, the process is the same. The destination must use the same or a higher database edition; downgrades aren’t supported. So, make sure to confirm the destination’s version before provisioning.
For supported database editions, Oracle Data Guard can be used to configure an ECPU-based standby DB system for an OCPU-based primary. You can create the standby through the OCI Console or API, let it synchronize with the primary, then perform a planned switchover. If the migration requires a change in the database software edition, use manual Data Guard configuration and validate that the source and destination combination is supported.
Lastly, we have Oracle Zero Downtime Migration (ZDM) which supports different migration workflows. Depending on the source, destination, and chosen workflow, it can use RMAN and Data Guard for physical migration (i.e. to ExaDB-XS), or Data Pump and Oracle GoldenGate for logical migration (i.e. Base DB on VM.BaseDB.x86).
No single method fits every database. Assess the options early, then test the chosen approach before production cutover.
Test the full service, not just the database
A database that starts successfully is only the first check. Before cutover, confirm that applications can connect and perform as expected, and that batch jobs, backups, monitoring, security, and operational procedures are ready. Verify hostnames, IP addresses, listeners, and network paths. Then document the runbook, owners, change freeze, success criteria, rollback plan, and communications. Doing this early gives your team time to fix any gaps before the maintenance window.
Move toward long-term availability
Existing deployments on affected SKUs will continue to run, but eventually you will be required to migrate. So, start planning now to manage the migration schedule, budget, and cutover, which can help manage costs and reduce the risk of a rushed migration. Prioritize workloads, align cutovers with business and budget cycles, and allow time to secure capacity and test. By doing this, you can plan a migration to the Oracle Database Cloud Service that best fits your needs.
If you have any questions, please reach out to your Oracle representative.