This is a step-by-step migration guide within the Oracle Knowledge Hub. For a full architectural overview, see our Oracle Cloud at Customer: The Complete Guide. For contract negotiation specifics, see How to Negotiate Oracle Cloud at Customer Contracts.

Step 1: Assess Your Current Oracle Environment

Begin by evaluating your existing Oracle landscape. Inventory all Oracle software and infrastructure to understand what you have and how it is used. Check versions of databases and applications. Legacy versions (e.g., older Oracle Database releases) may require upgrades to be compatible with Oracle Cloud at Customer. Document current CPU, memory, and storage utilisation levels. This baseline assessment reveals your true resource needs and any gaps.

Develop a comprehensive picture of your Oracle estate's workload patterns. For example, identify peak CPU usage periods and memory hogs. If you find an Oracle Database running on an outdated version (say 11g or 12c), plan to upgrade to a supported version before migration to avoid compatibility issues. A thorough assessment ensures you only move what is needed and can right-size the Cloud at Customer environment. Use Oracle licence compliance scripts and internal discovery tools to build an accurate picture.

For guidance on running a structured assessment, see our Oracle Cloud Migration Readiness Assessment and how to conduct an internal Oracle licence audit.

Step 2: Perform Detailed Workload Analysis

With an inventory in hand, dive deeper into technical workload analysis. Utilise tools such as Oracle's Automatic Workload Repository (AWR) reports or monitoring data to profile performance. Look at peak vs. average utilisation, storage growth trends, and I/O throughput requirements. This analysis might take a few weeks, but it is critical to accurately size the Cloud at Customer solution.

It helps you determine how many OCPUs (Oracle CPU cores), how much storage, and what network capacity you will require. Understanding Oracle's licence minimums and counting rules is essential here, as they directly affect your sizing calculations.

Oracle Cloud at Customer offerings come in different flavours. For example, Exadata Cloud@Customer for databases, or Dedicated Region for a full on-prem cloud. Your analysis will indicate which option is the best fit. For a detailed comparison, see Cloud at Customer vs. Dedicated Region.

One global retailer discovered through AWR analysis that its average database CPU usage was 30% of on-premises capacity, enabling them to consolidate and select a smaller Exadata configuration than Oracle's initial recommendation. Data-driven analysis prevents oversizing the hardware and cloud services.

Step 3: Engage Independent Expertise and Plan Strategy

Do not plan in a vacuum. Seek independent advice to validate your findings and strategy. Involve a third-party Oracle licensing or cloud expert (or an internal architecture review board) to get an unbiased second opinion. These experts can highlight if Oracle's sales proposals are inflated and suggest cost-saving configurations.

Use their input to refine your target architecture and migration roadmap. Additionally, build a strong business case for the migration. Align the Cloud at Customer move with business objectives, such as improving performance, ensuring data sovereignty, or reducing data centre costs.

Leverage external advisors to challenge vendor assumptions. This helps dictate migration terms on your own needs, not Oracle's selling agenda. For example, an unbiased review might reveal you only need 50 OCPUs of database capacity, not the 100 OCPUs Oracle pitched. Avoid overspending. Read about 20 key considerations for managing Oracle contracts.

Need Independent Oracle Cloud@Customer Advisory?

Redress Compliance provides completely vendor-independent Oracle advisory services. We help enterprises right-size deployments, negotiate favourable contracts, and avoid common licensing pitfalls.

Step 4: Plan Capacity, Licensing, and Cloud Commitments

Plan the commercial and capacity aspects of your Oracle Cloud at Customer deployment. Oracle will offer a subscription that includes on-prem hardware plus cloud services via Oracle Universal Cloud Credits (UCC). Break down the cost components: typically, the hardware appliance (Exadata rack or OCI rack) is a fixed subscription portion (often around 25–30% of total cost), and the cloud service usage (OCPUs, storage, etc. via UCC) will be the majority of the spend.

Model Description Pros
BYOL (Bring Your Own License) Use existing Oracle software licences on Cloud at Customer. Lowers cloud usage fees significantly. Must keep licences under active support. Cost-effective if you have already invested in licences. See BYOL Comprehensive Guide.
License-Included Oracle provides software licences as part of the subscription. Simplifies compliance: Oracle manages the licences. Typically costs more per unit. Useful if you lack certain licences. No need to track BYOL rules. See BYOL vs. License-Included Cost Comparison.

Negotiation Tips: Oracle often requires a multi-year commitment (commonly 4 years) with a minimum annual UCC purchase. Negotiate the UCC commitment based on realistic usage. For detailed negotiation strategies, see our Oracle Cloud Negotiations guide and Oracle Cloud Contracts and Credits for CIOs.

If your migration will ramp up over 12 months, do not commit as if you will use full capacity from day one. Consider committing to a lower UCC spend in Year 1 and increase commitments in later years as usage grows. Push for volume discounts on UCC. See Oracle Renewal Negotiation Checklist for key clauses.

Common Contract Pitfalls:

  • Overcommitting to cloud credits: Paying for unused cloud services if actual consumption falls short. Start with conservative commitments; scale up as needed.
  • Oversized hardware configuration: Excess capacity increases costs with no performance benefit. Right-size based on your analysis.
  • Ignoring BYOL vs. included licence options: Unnecessary spend or compliance issues if chosen incorrectly. Evaluate current licences.
  • Long-term lock-in without exit plan: Limited flexibility if business needs change. Negotiate termination rights.

Step 5: Prepare Your Data Centre and Network

Oracle Cloud at Customer involves Oracle shipping and installing hardware in your data centre. Ensure your facilities are ready well in advance.

Space, Power, and Cooling: Verify that you have sufficient rack space, a suitable power supply, and adequate cooling for Oracle's equipment. Oracle typically provides specifications (e.g., a full rack Exadata with specific power draw requirements). The data centre must meet Oracle's standards for security and environment since the hardware remains Oracle-owned.

Network Connectivity: Set up a robust network connection between the Cloud at Customer hardware and Oracle's cloud network. Most deployments require a connection to Oracle's public cloud for management and updates, via secure VPN or a dedicated Oracle FastConnect circuit. Plan for redundant links if high availability is needed. See Oracle licensing for disaster recovery for HA/DR considerations.

Security and Access: Collaborate with Oracle to fulfil security requirements. This may include providing controlled physical access for Oracle engineers, meeting encryption or firewall requirements, and integrating the appliance into your identity management for user access.

Team Readiness: Prepare your IT staff to manage a hybrid cloud environment. Oracle will handle hardware maintenance and cloud infrastructure management tasks (like patching the control plane). However, your team will still manage your applications and databases on the Cloud at Customer stack. Plan training sessions so administrators understand the new tooling, including managing licences in OCI environments.

Verifying network settings and running a connectivity test with Oracle before the hardware arrives can save days of troubleshooting.

Step 6: Deploy and Migrate in Phases

With the contract signed and preparations done, Oracle will deliver and install the Cloud at Customer hardware. Deployment typically takes 4–8 weeks from order to having the system on-site and operational. Coordinate closely with Oracle's team for a smooth installation.

Once live, approach migration of workloads in planned phases. Start with lower-risk or non-production systems as a pilot. This phased migration allows your team to gain experience on the new platform and resolve any issues on a smaller scale. Next, migrate your critical production workloads, scheduling cutovers during approved maintenance windows.

Data Transfer and Testing: Before switching over, ensure all data is transferred and applications are thoroughly tested on the Cloud at Customer environment. Running in parallel or doing trial runs can validate performance. Use proven migration tools and methods. Oracle provides utilities like Data Pump or Zero Downtime Migration for databases.

Minimise Downtime: Plan for the actual go-live of each system carefully. If near-zero downtime is required for a database, you might employ Oracle GoldenGate replication or other strategies. If some downtime is acceptable, schedule it during off-hours and communicate the schedule to stakeholders. Have a rollback plan in case of unexpected issues.

Migrations can range from 6 to 18 months in duration. A simple Oracle environment might be fully migrated in half a year, while a large enterprise with many interdependent systems could take over a year.

Step 7: Post-Migration Optimisation and Management

After migrating, the journey is not over. Now it is about operational excellence on Oracle Cloud at Customer. Ensure you have proper monitoring in place. Leverage Oracle's cloud management tools to watch resource utilisation (CPU, memory, storage), performance metrics, and up/down status of services. See our 32 OCI cost optimisation strategies for practical tips.

Cost Governance: Regularly review your cloud credit consumption against your committed amount. If you consistently use less than what you are committed to, consider scaling down or using more of the services you are paying for. Our Oracle Cost Optimisation Playbook covers this in depth.

Performance Tuning: Fine-tune databases and applications running on Cloud at Customer. The underlying hardware (such as Exadata) may offer performance features you can exploit. See our Oracle Database Licensing & Options Playbook for insights on features that require additional licensing vs. those included.

Scalability Planning: Regularly revisit scalability plans. Oracle Cloud at Customer can often scale by adding more hardware racks or enabling more OCPUs. Work with Oracle proactively if you foresee needing expansion.

Stay Compliant: Since this is your on-premises environment, you are responsible for compliance with any applicable data regulations. For licensing compliance, regularly run Oracle compliance scripts and review on-prem to cloud portfolio management. Manage the relationship with Oracle carefully. See our Oracle support renewal contract checklist for key clauses to review before renewal.

Step 8: 9 Key Recommendations

  1. Conduct Thorough Analysis First — Do not rely solely on Oracle's sizing. Use your own metrics and tools to determine exactly what capacity and services you need. See Oracle Licensing Calculator.
  2. Leverage Existing Licences — Utilise BYOL pricing if you have underutilised Oracle licences. It can significantly reduce your cloud costs. Track compliance with OCI BYOL strategy.
  3. Negotiate in Detail — Treat the Cloud@Customer contract as you would any major enterprise agreement. Negotiate discounts on cloud credits, seek flexible terms, and clarify responsibilities in writing.
  4. Plan for the Long Term — Design your environment with future growth in mind. Start at a size that meets current needs but can scale. Read CIO Playbook: Cloud@Customer Deployment Strategy.
  5. Invest in Network and Security Upfront — Ensure your network connectivity is robust and secure. Use dedicated connections and implement all necessary security controls from day one.
  6. Train and Empower Your Team — Bridge skills gaps by training IT staff on managing Oracle Cloud at Customer tooling, consoles, and APIs. See managing licences in OCI environments.
  7. Migrate Gradually and Test Thoroughly — Avoid big-bang migrations. Move in phases and conduct thorough testing after each phase. Plan DR strategies for each cutover.
  8. Monitor Usage and Optimise Costs — Schedule regular reviews of cloud credit usage. Shut down non-prod environments when not needed. See OCI Cost Optimisation.
  9. Maintain Vendor Independence — Continue to keep an eye on the broader cloud market. Avoid customisations that lock you in too tightly. Keep Oracle accountable to SLAs. Compare with OCI vs. AWS for Oracle workloads.

Step 9: Migration Action Checklist

  1. Inventory and Assess — Gather data on all Oracle systems (versions, usage stats, dependencies). Identify any upgrades or changes needed. Use licence information tools and audit risk assessments.
  2. Define Requirements and Strategy — Determine the right Cloud at Customer offering and sizing for your needs. Build a business case and migration plan.
  3. Negotiate the Deal — Right-size the hardware and cloud credit commitments, choose a licensing model (BYOL vs included), and secure discounts and favourable terms.
  4. Prepare Infrastructure — Ready your data centre for the incoming Oracle hardware (space, power, cooling). Set up network connections and ensure security policies are in place.
  5. Execute Migration in Phases — Start with a pilot, thoroughly test, then move critical applications. Monitor outcomes of each phase before proceeding.

Step 10: FAQ

Q: What is the first step in migrating to Oracle Cloud at Customer?

A: The first step is to analyse your current Oracle environment. Identify what software and workloads you have, check their versions, and gather performance data. This assessment determines readiness and sizing for the Oracle Cloud at Customer migration. Use Oracle compliance scripts and internal audit processes to build an accurate baseline.

Q: Can we use our existing Oracle licences with Oracle Cloud at Customer?

A: Yes. Oracle Cloud at Customer supports a Bring Your Own License (BYOL) model. You can apply your current Oracle licences (with active support contracts) to the Cloud at Customer environment, which lowers the service fees. If you prefer not to use BYOL or lack certain licences, you can opt for a licence-included subscription. See our BYOL comprehensive guide and BYOL vs. License-Included cost comparison.

Q: How long does it typically take to implement and migrate?

A: Deployment and migration happen in stages. The Oracle-supplied hardware typically arrives and is set up within approximately 4 to 8 weeks after the contract is signed. The subsequent migration of workloads can take anywhere from 6 to 18 months, depending on complexity.

Q: What preparations are needed in our data centre?

A: You will need to ensure your data centre can accommodate the Oracle Cloud at Customer equipment. This means having sufficient rack space, power, cooling, and physical security. Additionally, set up a reliable network connection to Oracle's cloud.

Q: How can we control costs during and after migration?

A: Cost control starts with accurate planning. Commit to cloud usage based on realistic needs. During migration, use a phased approach. After migration, closely monitor your consumption of Oracle cloud credits. See our Oracle Cost Optimisation Playbook.

Ready to Migrate to Oracle Cloud at Customer?

Our independent Oracle licensing experts help enterprises plan, negotiate, and execute Cloud at Customer migrations, ensuring you get the right sizing, favourable contract terms, and a smooth transition.

Related Reading