10 Steps to Migrate to Oracle Cloud at Customer
Executive Summary:
Migrating to Oracle Cloud at Customer enables enterprises to run Oracle’s cloud services in their own data centers, blending cloud agility with on-premises control. To succeed, CIOs must strike a balance between technical preparation and savvy commercial negotiation.
This guide outlines 10 key steps that encompass assessment, planning, contract negotiation, and execution. The goal is a cost-effective, smooth migration that meets technical requirements without overspending or disruption.
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’s 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 utilization levels.
This baseline assessment reveals your true resource needs and any gaps.
- Actionable Takeaway: 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’s needed and can right-size the Cloud at Customer environment.
2. Perform Detailed Workload Analysis
With an inventory in hand, dive deeper into technical workload analysis. Utilize tools such as Oracle’s Automatic Workload Repository (AWR) reports or monitoring data to profile performance. Look at peak vs. average utilization, 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’ll require.
- Insight: Oracle Cloud at Customer offerings come in different flavors (e.g., 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 instance, if most of your workload involves Oracle databases with high transaction volumes, an Exadata Cloud@Customer might be a suitable option. If you need a broad range of services on-prem, a Dedicated Region could be the target.
- Example: 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.
3. Engage Independent Expertise and Plan Strategy
Don’t 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 center costs.
Independent experts can help quantify benefits and flag risks.
This is also the time to decide which Cloud@Customer model suits your needs (e.g., is a single Exadata rack sufficient, or do you need a multi-rack Dedicated Region for broader services?).
- Actionable Takeaway: 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. Use that to adjust the plan and avoid overspending. With a clear strategy and executive buy-in from a solid business case, you’re ready to negotiate and prepare the migration.
4. Plan Capacity, Licensing, and Cloud Commitments
The next step is planning 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. Determine the exact amount of cloud capacity you need, using your workload analysis as a guide.
Critically, decide on your licensing model:
- Bring Your Own License (BYOL): You use existing Oracle software licenses for databases or middleware on Cloud at Customer. This lowers the cloud usage fees, but you must keep those licenses under support. BYOL can be cost-effective if you have already invested in licenses.
- License-Included: Oracle provides the software licenses as part of the subscription. This simplifies compliance (Oracle manages the licenses) but typically costs more per unit. It’s useful if you lack certain licenses or want Oracle to handle all licensing.
Negotiation is key in this phase. Oracle often requires a multi-year commitment (commonly 4 years) with a minimum annual UCC purchase.
Negotiate the UCC commitment based on realistic usage:
- If your migration will ramp up over 12 months, don’t commit as if you’ll use full capacity from day one. For example, if hardware arrives in 2 months and you’ll gradually migrate over the next 6 months, consider committing to a lower UCC spend in Year 1. You can increase commitments in later years as usage grows.
- Push for volume discounts on UCC. Oracle offers tiered discounts (e.g,. 10% off at a certain spend level, higher for bigger commitments). Leverage competitive bids or your analysis to secure better rates.
- Negotiate flexibility where possible – for instance, the ability to adjust your cloud credit commitment annually, or protections against price hikes in renewals.
To avoid common contract pitfalls, keep the following in mind:
| Contract Pitfall | Consequence | How to Avoid |
|---|---|---|
| Overcommitting to cloud credits | Paying for unused cloud services if actual consumption falls short. | Start with conservative commitments; scale up as needed based on real usage data. Ensure contract allows unused credits carryover or adjustment if possible. |
| Oversized hardware configuration | Excess capacity increases costs with no performance benefit. | Right-size based on your analysis. Push back on any hardware that exceeds your requirements. Include scalability options to add capacity later rather than overbuying now. |
| Ignoring BYOL vs. included license options | Unnecessary spend or compliance issues if chosen incorrectly. | Evaluate your current licenses. Use BYOL to save costs if you have licenses and support. Choose license-included only for products you can’t cover with existing licenses. |
| Long-term lock-in without exit plan | Limited flexibility if business needs change, stuck with high costs. | Negotiate terms like termination rights, or at least the ability to reduce scope in later years. Have an exit strategy for post-contract (e.g. plan for renewal or migration). |
By meticulously planning capacity and commercial terms, you set the stage for a cost-effective migration.
Remember that everything is on the table: you can negotiate not just price, but also support services, implementation assistance, and roles and responsibilities.
5. Prepare Your Data Center and Network
Oracle Cloud at Customer involves Oracle shipping and installing hardware in your data center. Ensure your facilities are ready well in advance:
- Space, Power, and Cooling: Verify that you have sufficient rack space available, a suitable power supply, and adequate cooling for Oracle’s equipment. Oracle typically provides specifications (e.g., a full rack Exadata with power draw requirements). The data center 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 Cloud at Customer deployments require a connection to Oracle’s public cloud for management and updates. This can be via secure VPN or a dedicated Oracle FastConnect circuit. Plan for redundant links if high availability is needed. Also, ensure low latency and adequate bandwidth, especially if you will integrate with other cloud or on-prem systems.
- Security and Access: Collaborate with Oracle to fulfill any 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 (for example, using Oracle Cloud consoles or APIs for the Cloud at Customer system). Oracle often offers workshops in this phase – take advantage of the migration workshops for security, network readiness, and data center preparation offered as part of the onboarding process.
By taking care of these preparations, you reduce the risk of last-minute surprises. For instance, verifying network settings and running a connectivity test with Oracle before the hardware arrives can save days of troubleshooting later.
A well-prepared environment means that when Oracle delivers the system, it can be installed and configured without delay, keeping your timeline on track.
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 – they’ll set up the hardware, connect it to Oracle Cloud systems, and run initial tests.
Your team should be present to learn the process and validate that everything fits your requirements.
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.
Use proven migration tools and methods (Oracle provides utilities like Data Pump or Zero Downtime Migration for databases, for example,) depending on your downtime tolerance.
- 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.
- Minimize 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, depending on their complexity.
A simple Oracle environment might be fully migrated in half a year. In contrast, a large enterprise with many interdependent systems, legacy databases, and integrations could take over a year to transition.
Create a realistic timeline that takes this into account. Importantly, avoid rushing to consume all cloud services immediately just because they’re available – use your phased approach to ensure stability.
Throughout the migration, closely monitor performance in the new environment. Compare it against baseline metrics from on-premises to catch any discrepancies. Tweak configurations as needed (for example, adjust memory parameters or storage layouts if the workload behaves differently on the new infrastructure).
By migrating in phases and actively managing the process, you reduce risk and build confidence with each step before moving to the next workload.
7. Post-Migration Optimization and Management
After migrating, the journey isn’t over – now it’s about operational excellence on Oracle Cloud at Customer.
First, ensure you have proper monitoring in place. Leverage Oracle’s cloud management tools to watch resource utilization (CPU, memory, storage), performance metrics, and up/down status of services.
The goal is to catch bottlenecks early and scale resources or tune systems as needed. For example, if a workload’s CPU usage grows over time, you might allocate additional OCPUs (if your contract allows burst capacity or by adjusting your subscription in the next cycle).
Cost governance is another key post-migration task. Regularly review your cloud credit consumption against your committed amount. If you consistently use less than what you’re committed to, consider scaling down or using more of the services you’re paying for.
Conversely, if usage is trending above expectations, plan for capacity increases or contract adjustments. Many enterprises set up cost dashboards or monthly reviews to avoid bill surprises.
Don’t forget to optimize your environment:
- Performance Tuning: Fine-tune the databases and applications now running on Cloud at Customer. The underlying hardware (such as Exadata) may offer performance features that you can exploit (e.g., smart indexing, caching) to gain even more value.
- Scalability Planning: Regularly revisit your 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, as adding hardware might have lead times. Ensure your contract covers how additional capacity would be priced.
- Stay Compliant: Since this is your on-premises environment, you are responsible for compliance with any applicable data regulations. Verify that all security controls are effective, including encryption, access controls, and audit logs, especially in industries such as finance or healthcare. Oracle Cloud at Customer is designed to meet strict requirements, but it’s up to you to use those features appropriately (e.g. enabling encryption at rest, restricting admin access, etc.).
- Continuous Improvement: Conduct a post-migration review. Identify lessons learned during the project and improve processes accordingly. Perhaps you discovered certain teams need more cloud training, or maybe the change management process can be streamlined for future updates. Institutionalize these learnings.
Finally, manage the relationship with Oracle. You now have an ongoing partnership, as Oracle is managing part of your on-premises infrastructure.
Hold regular service reviews with Oracle to discuss performance, support issues, and opportunities to optimize (Oracle might recommend new features or updates – evaluate them on merit).
Also, keep an eye on the end of your subscription term well in advance: decide whether you will renew, expand, or terminate the Cloud at Customer service, and plan accordingly (including potential data migration out if needed).
By focusing on optimization and proactive management post-migration, you ensure that your organization continues to maximize value from Oracle Cloud at Customer and adapts to evolving business needs.
Recommendations
- Conduct Thorough Analysis First: Don’t rely solely on Oracle’s sizing. Use your own metrics and tools to determine exactly what capacity and services you need. This prevents overspending on unnecessary hardware or cloud credits.
- Leverage Existing Licenses: Utilize BYOL pricing if you have underutilized Oracle licenses. It can significantly reduce your cloud costs. Keep those licenses under support and document their use in Cloud at Customer to stay compliant.
- Negotiate in Detail: Treat the Oracle Cloud at Customer contract as you would any major enterprise agreement. Negotiate discounts on cloud credits, seek flexible terms (like ramp-up periods or the ability to adjust commitments), and clarify responsibilities for installation, support, and updates in writing.
- Plan for the Long Term: Design your Cloud at Customer environment with future growth in mind. It’s easier to add capacity later than to remove excess, so start at a size that meets current needs but can scale. Ensure your contract and architecture allow for the addition of extra racks or resources when needed.
- Invest in Network and Security Upfront: Ensure your network connectivity to Oracle’s cloud is robust and secure. Use dedicated connections if possible and configure backup links. Also, implement all necessary security controls (firewalls, encryption, identity management) from day one – moving to Cloud at Customer shouldn’t compromise security or compliance.
- Train and Empower Your Team: Bridge any skills gaps by training your IT staff on managing Oracle Cloud at Customer. This might involve learning new Oracle Cloud consoles, APIs, or understanding Oracle’s support processes. Having in-house proficiency will help you get the most out of the solution and respond quickly to issues or changes.
- Migrate Gradually and Test Thoroughly: Avoid big-bang migrations. Move in phases, and after each phase, conduct thorough testing and performance tuning. This phased approach builds confidence and ensures you catch any issues while the scale is small. Use pilot migrations as learning opportunities.
- Monitor Usage and Optimize Costs Continuously: After migration, schedule regular reviews of your cloud credit usage. If you’re underutilizing, find out why and correct it (perhaps by decommissioning unused resources or adjusting commit levels at renewal). If over-using, plan budget increases or optimizations. Continuously seek ways to optimize – for instance, shutting down non-prod environments when not needed to save credits.
- Maintain Vendor Independence: Even though you’re committing to Oracle’s solution, continue to keep an eye on the broader cloud market and your enterprise architecture. Avoid customizations that lock you in too tightly. Keep Oracle accountable to SLAs and deliverables, and retain leverage for future negotiations (like citing alternative solutions or cloud providers if needed).
Checklist: 5 Actions to Take
- Inventory and Assess: Gather data on all Oracle systems (versions, usage stats, dependencies). Identify any upgrades or changes needed to run on Oracle Cloud at Customer.
- Define Requirements and Strategy: Determine the right Cloud at Customer offering and sizing for your needs, using independent expert input. Build a business case and migration plan that aligns with your company’s goals and timelines.
- Negotiate the Deal: Work with sourcing/procurement to negotiate the Oracle Cloud at Customer contract. Right-size the hardware and cloud credit commitments, choose a licensing model (BYOL vs included), and secure discounts and favorable terms (like flexible scaling and support provisions).
- Prepare Infrastructure: Ready your data center for the incoming Oracle hardware (space, power, cooling). Set up necessary network connections (e.g., VPN or FastConnect) and ensure security policies are in place. Communicate roles and expectations with Oracle’s deployment team and train your staff on the new environment.
- Execute Migration in Phases: Once the system is installed, migrate workloads in a step-by-step manner. Start with a pilot, thoroughly test it, and then move critical applications. Monitor the outcomes of each phase before proceeding. After a full migration, review the project, optimize configurations, and proactively manage ongoing operations and costs.
FAQ
Q: What is the first step in migrating to Oracle Cloud at Customer?
A: The first step is to analyze 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.
Q: Can we use our existing Oracle licenses 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 licenses (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 licenses, you can opt for a license-included subscription where the license cost is built into the hourly rates – though this is generally more expensive.
Q: How long does it typically take to implement and migrate to Oracle Cloud at Customer?
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 the complexity. Simple environments with a few databases might migrate in a half-year, whereas a large enterprise estate with many applications and databases could take over a year to fully transition.
Q: What preparations are needed in our data center before the Cloud at Customer arrives?
A: You’ll need to ensure your data center 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 (for management and updates). Think of it as preparing for a new important system: you want all environmental and connectivity requirements met ahead of time. Oracle usually provides guidance and can run workshops to help with network and security preparedness.
Q: How can we control costs during and after the migration to Oracle Cloud at Customer?
A: Cost control starts with accurate planning – commit to cloud usage based on realistic needs (don’t overcommit). During migration, use a phased approach so you aren’t paying for full capacity before you use it. After migration, closely monitor your consumption of Oracle’s cloud credits. If you notice underutilization, consider adjusting usage or negotiating lower commitments in the future. Also, utilize features like auto-scaling carefully and shut down any idle resources (for example, turn off non-production environments when they are not in use) to minimize waste. Regularly reviewing bills and usage reports will help keep costs aligned with expectations.
