10 steps to migrate off Oracle Cloud at Customer

Oracle Cloud at Customer (OCI@C) was sold as a way to get cloud benefits with on prem control. For some workloads it has done that. For others it has produced costly lock in with limited cloud upside. If you are evaluating migration off OCI@C, the licensing and audit exposure dimensions need at least as much attention as the technical migration itself.

The ten steps

1. Inventory the OCI@C footprint

Catalog every workload running on OCI@C, the underlying Oracle products in use, the database options enabled, and the support and licensing terms covering each. Most OCI@C estates have grown organically and the inventory has not been formally maintained.

2. Read your OCI@C contract

OCI@C contracts contain term commitments, exit terms, and data extraction provisions that vary substantially. Some allow clean migration with reasonable notice. Others require contractual renegotiation. Reading these clauses is step one before any technical work.

3. Map licensing entitlements to destination

If the destination is on prem Oracle, licensing typically transfers with appropriate true ups. If the destination is a hyperscaler (AWS, Azure, GCP), licensing depends heavily on whether you have BYOL rights, whether you are using authorised cloud environments, and whether your existing Oracle license terms permit the migration.

4. Identify the audit exposure

Migration off OCI@C is a moment when Oracle's audit program often gets interested. The migration produces a deployment change that surfaces in Oracle's monitoring. Customers who migrate without a documented entitlement position frequently receive audit notices in the months following.

5. Choose the destination architecture

Same-platform on prem, hyperscaler native (RDS, Azure SQL), or third party-supported on prem with a different vendor. Each has different cost profiles and different licensing implications. The hyperscaler native path often produces the largest cost reduction but requires the most refactoring.

6. Build the migration plan with licensing as a workstream

Most OCI@C migrations are scoped as technical projects. The licensing dimension needs to be a parallel workstream from day one, not a downstream cleanup task. Decisions made for technical reasons in months one and two often determine licensing outcomes that surface in months six and seven.

7. Negotiate the OCI@C exit terms

Even if the contract permits exit, the operational exit (data extraction, runtime support during migration, rollback options) is negotiable. Most customers do not negotiate this because they do not realize they can.

8. Execute the migration in waves

Migrating non-critical workloads first builds operational confidence and surfaces licensing edge cases before they become production issues. Migrating critical workloads in the final waves means the team has done it ten times before they touch the workloads that matter most.

9. Document the licensing position post-migration

The post-migration licensing position should be a written, defensible document. This is the document Oracle's audit team will ask for if they engage in the months following migration. Customers who have it ready typically do not face an audit. Customers who do not, often do.

10. Renegotiate the forward Oracle relationship

OCI@C exit is a moment of leverage. Oracle has lost a meaningful piece of revenue. The forward Oracle relationship (Database, Apps, Java) can usually be renegotiated on better terms in the same conversation. Customers who treat the migration as a discrete event miss this leverage. Customers who treat it as part of a broader Oracle commercial reset capture it.

What to do now

If OCI@C exit is on your roadmap, the licensing workstream needs to start before the technical workstream. Read the Oracle ULA Decision Framework if a ULA covers the affected workloads. Read Oracle Third Party Support 2026 if cost is the primary driver. Or request a confidential migration review.