10 Steps to Migrate to Oracle Cloud at Customer

Why Oracle Cloud at Customer Is Different From a Standard Cloud Migration

Oracle Cloud at Customer is not a standard lift-and-shift to a public cloud. It is a private cloud deployment model in which Oracle ships its engineered hardware into your data centre, manages the infrastructure remotely, and charges you a multi-year subscription for cloud services running on your own premises. The appeal is straightforward: you get Oracle's cloud capabilities — elastic scaling, Autonomous Database, managed patching — without moving data across a public network boundary.

But the migration path is structurally different from OCI, AWS, or Azure migrations. Licensing compliance obligations follow you on-premises. Oracle's audit rights remain unchanged. Your existing on-premises licenses interact with Cloud at Customer in ways that require careful analysis before you sign anything. And the contract terms — often four to five years with no early exit — are among the most significant software commitments an enterprise makes.

The ten steps below reflect the sequence that experienced Oracle licensing practitioners follow to protect the organisation at every stage of the migration.

Step 1: Conduct a Full Oracle Estate Inventory

Before any migration planning begins, you need a complete and accurate picture of your Oracle footprint. This means inventorying every Oracle software product in use — databases, middleware, application server, WebLogic, Forms, Reports, BI Publisher, and any other Oracle technology — along with the hardware environment in which each product runs.

The inventory should capture the number of processors, cores, and the core factor applied under Oracle's Processor Core Factor Table. It must identify any virtualisation layer — VMware, Hyper-V, Oracle VM, KDE — and confirm whether Oracle's hard partitioning rules are satisfied. Most on-premises estates carry latent compliance risk that surfaces during cloud migration when Oracle's LMS team runs their licence review scripts against the new environment.

Use Oracle's licence management scripts (DBSAT, LMS collection scripts) combined with your own CMDB and discovery tools. Do not rely on Oracle to conduct this inventory on your behalf — their assessment is not independent and will be used against you in commercial negotiations.

Step 2: Validate Your On-Premises Licensing Position

Cloud at Customer migration is not a clean break from your existing licence position. If you have processor licences on-premises that you intend to bring to Cloud at Customer under BYOL, those licences must be validated as compliant before migration. Taking non-compliant licences into Cloud at Customer does not resolve the underlying deficit — it simply relocates the exposure into a new environment where Oracle's remote monitoring has greater visibility.

Pay particular attention to processor licensing in virtualised environments. Oracle's policy requires that processor licences cover the full physical server — not just the assigned virtual machines — unless the virtualisation technology qualifies as hard partitioning. VMware does not qualify. If your on-premises estate runs Oracle on VMware and you have been licensing by assigned vCPUs rather than physical cores, you likely have a compliance gap that must be resolved before migration planning proceeds.

Also review any Unlimited Licence Agreement (ULA) or Perpetual ULA (PULA) obligations. ULA certification windows interact with Cloud at Customer deployment timelines in ways that can either maximise or severely restrict your BYOL position depending on when you certify.

Step 3: Decide BYOL vs Licence-Included Per Workload

Oracle Cloud at Customer supports two licensing models for each service: Bring Your Own Licence (BYOL) and Licence-Included. The decision is not binary across the entire estate — you can apply different models to different workloads and different service types on the same Cloud at Customer environment, but you cannot mix models on a single database or service instance.

The financial difference is significant. BYOL rates are typically 75 to 80 percent lower than Licence-Included rates because Oracle removes the software licensing cost from the cloud service charge. For an Exadata Cloud at Customer deployment, BYOL pricing runs approximately $0.32 per OCPU-hour compared to $1.34 per OCPU-hour Licence-Included at list price — a ratio of approximately 4:1. If you own sufficient licences with active CSI (Customer Support Identifier) support contracts, BYOL is almost always the correct model.

Licence-Included is rational only when you do not own the required licences — for example, Autonomous Database, which requires Database Enterprise Edition plus the Autonomous Database option — or when the workload is small and the overhead of licence tracking is disproportionate to the cost saving. For every workload on the shortlist, produce a workload-level BYOL vs Licence-Included analysis before the contract is drafted.

Step 4: Define Data Sovereignty and Compliance Requirements

One of the primary reasons enterprises choose Cloud at Customer over OCI public cloud is data sovereignty. Before migration, document the specific regulatory requirements that make public cloud untenable: GDPR article 44 restrictions on cross-border transfers, national data localisation laws in Germany, France, Russia, or the UAE, industry-specific mandates in financial services or healthcare, or internal corporate policy requiring data to remain on customer-controlled hardware.

These requirements drive hardware sizing, network segmentation design, and the specific Oracle Cloud at Customer variant you deploy. Oracle Exadata Cloud at Customer is optimised for high-performance database workloads. Oracle Compute Cloud at Customer provides general-purpose IaaS. Oracle Private Cloud Appliance offers a converged infrastructure option. Each has different data boundary guarantees, support terms, and minimum commitment levels that must align with your sovereignty requirements before the contract is signed.

Step 5: Size Your Infrastructure Requirements Accurately

Oracle Cloud at Customer hardware is deployed in rack-based configurations with fixed capacity increments. Unlike public cloud where you can provision a single compute instance, Cloud at Customer requires a minimum rack commitment — typically representing a five-year spend in the range of $1 million to $5 million depending on configuration. Over-sizing drives unnecessary cost. Under-sizing requires a mid-term upgrade conversation where Oracle holds all the commercial leverage.

Sizing inputs include current CPU utilisation profiles (peak and average), memory requirements per workload, storage IOPS and throughput, network bandwidth, and projected growth over the contract term. Oracle's sales team will model this for you, but their sizing output will consistently favour larger configurations. Commission an independent infrastructure sizing review that uses your actual workload telemetry, not Oracle's reference architectures.

Also model Oracle support cost escalation into your sizing economics. Oracle increases support costs by 8 percent per year. Over a five-year Cloud at Customer term, the cumulative support cost on your BYOL licences will be significantly higher than the day-one figure in Oracle's TCO model. Any contract modelling that uses a flat support figure is deliberately understating the total cost.

Step 6: Prepare Your Data Centre for Physical Installation

Oracle Cloud at Customer requires your data centre to meet specific physical requirements before the hardware can be delivered and installed. Network connectivity must support redundant 100-Gbit uplinks in a leaf-spine topology. Oracle requires a minimum of four network ports for the data network plus a physically separated administration network. DNS and NTP server access from the Cloud at Customer control plane is mandatory — failure to configure these correctly will block Oracle's remote management capability and delay deployment.

Power requirements vary by rack configuration but typically range from 5 to 20 kVA per rack. Cooling must support front-to-back airflow with an ambient temperature maintained between 21 and 23 degrees Celsius. Floor loading, physical access for delivery, and installation crew scheduling must all be coordinated with Oracle's deployment team. Delays in data centre readiness are among the most common sources of cost overrun in Cloud at Customer projects — Oracle will charge for delays that are attributable to customer site readiness failures.

Step 7: Negotiate the Contract Terms Before Committing

The Cloud at Customer contract is one of the most commercially asymmetric agreements in enterprise software. Oracle's standard terms include a four to five year initial term, auto-renewal language that extends the contract without explicit customer approval, pricing set at "prevailing rates" at renewal, and minimal exit provisions. Each of these terms is negotiable — but only before signature, not after.

Priority negotiation items include: capping the initial term at 36 months to preserve earlier renegotiation leverage; removing auto-renewal clauses entirely; fixing renewal pricing or capping annual rate increases; structuring minimum commits as annual rather than monthly to allow consumption flexibility; including carry-forward provisions for unused credits; and securing an early exit clause with a defined penalty formula rather than full remaining-term liability.

On discount benchmarks: a $500,000 annual commitment typically yields around 10 percent off list; $1 million annually around 15 percent. Larger deployments have achieved 30 to 50 percent discounts. The discount is only meaningful, however, if the underlying commitment level and term length are calibrated to your actual requirements. An over-committed agreement at 35 percent off still costs more than a right-sized agreement at 15 percent off.

Step 8: Select Your Migration Method

Oracle supports several migration methods for moving on-premises databases to Cloud at Customer. Zero Downtime Migration (ZDM) is Oracle's recommended approach for production databases where downtime must be minimised. ZDM uses Oracle Active Data Guard to create a standby database in the Cloud at Customer environment, synchronise it in real time with the source, and execute a controlled switchover with minimal interruption. ZDM supports physical and logical migration modes and is suitable for databases of any size.

For very large databases — 400 TB or more — Oracle recommends ZDM physical online migration to Exadata Cloud at Customer specifically because it keeps downtime low through Data Guard continuous synchronisation. For smaller databases or those requiring schema restructuring, Data Pump and Transportable Tablespaces are viable alternatives. Transportable Tablespaces enable fast data movement but may require table reorganisation to take full advantage of Exadata's Smart Scan capabilities.

Migration method selection should be driven by your RTO, RPO, and database size — not by Oracle's default recommendation, which will typically favour ZDM regardless of whether the complexity is warranted for your specific environment.

Step 9: Execute a Phased Migration with Licence Checkpoints

Do not migrate your entire Oracle estate in a single cutover. A phased migration approach allows you to validate licensing compliance at each phase before moving additional workloads. During any migration phase where both the source on-premises environment and the Cloud at Customer environment are running the same Oracle software concurrently, you must ensure sufficient licence coverage for both environments — Oracle's BYOL rules require licences to cover active deployments in both source and target during transition periods.

Define licensing checkpoints at each migration phase: confirm OCPU allocation matches BYOL licence count, verify CSI support contract status for all BYOL licences, confirm that any decommissioned on-premises instances have been formally retired, and update your software asset management records to reflect the new deployment topology. Running a parallel environment without adequate licence coverage — even for a short period — creates audit exposure that Oracle's remote monitoring can detect.

Phased migration also provides the opportunity to right-size your Cloud at Customer OCPU commitment incrementally. Actual workload consumption in Cloud at Customer frequently differs from pre-migration estimates once query optimisation and Exadata features such as Smart Scan and storage indexes are active.

Step 10: Validate Compliance and Optimise Post-Migration

Within 90 days of completing migration, conduct a formal licence compliance review across the Cloud at Customer deployment. This review should verify OCPU allocations against BYOL licence counts, confirm that no software options are active without corresponding licence entitlements, validate that all CSI contracts remain active and properly associated with the correct licences, and document the evidence trail that demonstrates compliance.

Post-migration optimisation is also the point at which you reclaim value from unused on-premises licences. Licences that have been migrated to Cloud at Customer under BYOL and are no longer needed on-premises should be retired formally from your SAM records. If you hold a ULA or PULA, the post-migration period may be the right time to trigger certification — particularly if the Cloud at Customer deployment has maximised your deployment count and created a favourable certification position.

Finally, review your Cloud at Customer consumption against your committed levels. If actual consumption is below commitment, engage Oracle proactively to renegotiate or restructure credits before the year closes. Unused committed credits represent pure cost with no offsetting value unless actively managed.

What Most Organisations Get Wrong

The most common failure mode in Oracle Cloud at Customer migrations is signing the contract before the licensing analysis is complete. Oracle's sales cycle creates urgency — quarter-end deadlines, short-window pricing offers, executive-level sponsorship — that pushes commercial decisions ahead of the technical and licensing diligence that should precede them. Organisations that sign on Oracle's timeline, rather than their own, consistently over-commit on term, accept unfavourable renewal terms, and deploy BYOL against licences that carry unresolved compliance gaps.

The second most common failure is accepting Oracle's TCO model at face value. Oracle's pre-sales TCO analysis uses their own list prices for competitive alternatives, assumes flat support costs, understates OCPU requirements, and omits the compounding effect of 8 percent annual support escalation over the full contract term. Every organisation that has commissioned an independent TCO review has found the real cost materially higher than Oracle's presentation suggested.

Independent advisory — from practitioners with direct Oracle LMS audit experience, not consultants whose relationships depend on Oracle goodwill — is the structural requirement for any organisation approaching Cloud at Customer for the first time. The commercial decisions made at contract signature will define your Oracle cost position for the next four to five years. Getting those decisions right requires an advisor who is paid to protect your interests, not Oracle's.