Oracle cloud migration is straightforward - until it isn’t.

At enterprise scale, the complexity isn’t in running RMAN, Data Pump, or GoldenGate. Those mechanics are well understood. The real challenge lies in everything that surrounds the move: licensing exposure, architectural trade-offs, production-readiness gaps, operational risk, and the long-term Day 2 burden that too often gets underestimated.

At Tessell, we’ve worked with enterprises that run Oracle in production at scale - a Fortune 250 railroad operator migrating 500+ databases to Azure; a Fortune 100 energy company rationalizing 700+ databases across on-prem and multi-cloud environments; a healthcare data platform moving 67.5 TB within a 12-hour cutover window; and a global smart metering company rebuilding its digital backbone on GCP.

What we've consistently seen is that a generic lift and shift playbook isn't enough. It takes deliberate planning, disciplined execution, and clarity on what production-readiness actually looks like in the cloud.

This guide captures those lessons - written from a practitioner's perspective, grounded in real-world execution.

What Is Lift and Shift And What It Isn’t

Lift and shift (re-hosting) moves your Oracle database to cloud infrastructure without changing the application architecture, schema, or codebase. Your PL/SQL, stored procedures, and application integrations stay intact. The database runs on cloud compute and storage instead of your data center hardware.

That’s the theory. In practice, calling it “lift and shift” creates an illusion of simplicity. Enterprise Oracle environments aren’t single-instance databases sitting on a clean VM. They involve multi-terabyte datasets, RAC clusters, Data Guard configurations, Exadata-optimized workloads, CDB/PDB architectures, and decades of accumulated PL/SQL logic. Every one of these dimensions introduces decision points that a “just move it” mindset will miss.

A more accurate framing: lift and shift is the fastest path to getting Oracle workloads onto cloud infrastructure. But “fastest” only holds if you scope the migration correctly and plan for what comes after.

Common Migration Scenarios

Your starting point shapes everything - tooling, timeline, risk profile, and what “done” looks like.

On-premises cloud IaaS. The most common scenario. Physical or virtualized Oracle databases moving to AWS, Azure, GCP, or OCI compute instances. This is where most data center exit mandates begin.

Oracle on self-managed cloud VMs to a managed platform. Organizations already in the cloud but drowning in operational overhead - patching, backups, HA configuration, monitoring and looking for a DBaaS layer that handles it. This is often the phase-two realization after an initial lift and shift.

Amazon RDS Oracle take-out. Enterprises hitting the limits of RDS for Oracle: restricted versions, no RAC, limited performance tuning, no Exadata features.

Multi-cloud consolidation. The most complex scenario. Organizations with Oracle workloads fragmented across multiple clouds and on-prem, needing a single operational plane. The Fortune 100 energy company fell squarely here: databases across OCI, Azure IaaS, and on-prem, with audit deadlines approaching and no centralized license tracking.

Pre-Migration: Where Migrations Are Won or Lost

The quality of your migration is largely determined before any data moves. These are the areas worth spending time on upfront.

Inventory Your Oracle Estate

Document your Oracle versions and editions (which determine licensing and cloud compatibility), architecture specifics (CDB/PDB, RAC, ASM, TDE), packaged application dependencies (EBS, PeopleSoft, SAP), any Exadata-specific optimizations (Smart Scan, HCC), and database sizes with growth trajectories.

Downtime Tolerance and RTO/RPO

This is the single biggest driver of migration method selection. Be precise: define RTO and RPO for each database individually. 24/7 systems need online methods (GoldenGate, Data Guard). Systems with maintenance windows can use simpler offline approaches (RMAN, Data Pump) that are less complex and less expensive.

Licensing Considerations

Licensing is one of the most overlooked areas in cloud migration. Confirm your target cloud is an authorized BYOL environment. Map vCPU-to-core ratios carefully — a miscalculation can double licensing costs. Audit for inadvertent feature activation (Diagnostics Pack, Tuning Pack, ADDM) after migration. And look for consolidation opportunities: the Fortune 100 energy company saved €1.45M annually partly through license consolidation identified during migration planning.

Cloud Infrastructure Requirements

• Storage: Production Oracle often demands hundreds of thousands of IOPS. NVMe-based instances (AWS i3/i4i, Azure Lsv3) deliver over 1M IOPS. Standard block storage won’t suffice for high-throughput OLTP.

• Networking: Plan dedicated connectivity (Direct Connect, ExpressRoute). Cross-cloud latency between apps and databases was a key pain point for the railroad operator when initially considering OCI alongside Azure.

• Security and compliance: TDE compatibility, VPC isolation, encryption at rest/in transit, and certifications (SOC 2, HIPAA, PCI-DSS). Define requirements before migration.

• HA/DR: Confirm same-zone failover, multi-AZ HA, and cross-region DR support. Configure these before cutover, not after.

Oracle Lift & Shift Migration Approaches

The migration tooling conversation is often backwards. Teams start with a tool (“we’ll use GoldenGate”) instead of starting with the constraints that should determine the tool. Here’s how to think about it.

Offline Migration (Planned Downtime)

Best for databases under 5 TB with scheduled maintenance windows.

RMAN Backup and Restore is the most battle-tested method. Full backup, transfer to cloud storage, restore on target. It works with every Oracle edition and feature. Downtime = backup time + transfer time + restore time. The Fortune 100 accounting firm used RMAN backup from their RDS instance, transferred to Azure, and restored into Tessell’s managed environment.

Oracle Data Pump (expdp/impdp) operates at the schema or table level. Useful for selective migrations or smaller databases. Slower than RMAN for large datasets, but offers the flexibility to reorganize schemas during migration.

Online Migration (Near-Zero Downtime)

Required when the business cannot tolerate extended outages.

Oracle GoldenGate provides real-time change data capture from redo logs. The cloud target stays synchronized with the source, and cutover is a brief connection switch - typically minutes. More complex to configure, more expensive to license, but essential for always-on systems.

Oracle Data Guard sets up a standby database in the cloud with SYNC or ASYNC replication. For organizations already running Data Guard, extending it to a cloud standby is a natural migration path. Switchover in Maximum Availability mode achieves zero data loss.

Platform-Assisted Migration

This is where the migration experience diverges most significantly from the generic playbook. Tools like Tessell Airdrop automate assessment, infrastructure provisioning, data migration, and validation compressing what typically takes weeks of manual orchestration into a managed workflow. For the healthcare data platform, this wasn’t optional: migrating 67.5 TB of HIPAA-regulated data under a 12-hour cutover window required orchestration that manual approaches couldn’t deliver.

Step-by-Step Guide to Lift & Shift Migration

Regardless of method, the execution lifecycle follows a consistent structure.

1. Assess and baseline. Capture AWR reports, peak IOPS, CPU and memory utilization, active session counts, tablespace layouts, and growth projections. These are your post-migration validation benchmarks. The railroad operator’s assessment revealed that a one-database-per-server model had driven server utilization down to 15% - a massive consolidation opportunity.

2. Prepare the cloud landing zone. Provision compute, storage, networking, and security. Deploy Oracle at the matching version and patch level. Configure HA/DR architecture before data migration, not after. For multi-cloud scenarios, this includes ensuring the management plane works across environments.

3. Migrate schema and data. Execute your chosen method. Monitor transfer throughput, verify object completeness (tables, indexes, stored procedures, sequences, database links, materialized views), and validate at each checkpoint.

4. Validate performance and integrity. Run AWR-equivalent benchmarks on the cloud instance. Compare query response times, IOPS, and CPU against your baselines. Perform row-count validations, checksum comparisons, and application-level smoke tests.

5. Cutover with a rollback plan. Redirect application connections. For Data Guard, this is typically under 5 minutes. For GoldenGate, under 15. Maintain the source in read-only or standby state for 24–72 hours as a rollback option.

6. Post-migration stabilization. Intensive monitoring for 1–2 weeks. Watch for latency shifts, connection pool issues, backup job failures, and any licensing or feature activation alerts. Decommission the source only after stabilization completes without incident.

Common Migration Risks and How to Mitigate them?

Every migration guide lists risks. Here are the ones we see cause real damage in the field, along with what actually prevents them.

Licensing exposure after migration.

This is the single most expensive and most common mistake. Oracle features get inadvertently activated in the new environment, and the next audit finds unlicensed Diagnostics Pack or Tuning Pack usage. Audit parameter settings on the target instance immediately after migration, and use centralized license tracking not spreadsheets.

Performance regressions that only appear under load.

Synthetic tests pass, but production workloads behave differently on cloud storage and networking. Query plans change. I/O patterns shift. Capture SQL Plan Baselines before migration and pin critical execution plans. Run production-representative load tests, not just smoke tests.

The “migrated but not production-ready” gap

Data is in the cloud, but backup policies aren’t configured, DR hasn’t been tested, monitoring isn’t integrated, and nobody has tested a failover. Treat backup, DR, monitoring, and security configuration as migration prerequisites, not post-migration tasks.

Operational handoff failures

On-premises DBAs who are experts in Oracle may lack cloud networking, IAM, and auto-scaling skills. Cloud engineers may lack deep Oracle knowledge. Invest in cross-training or partner with a managed service provider that bridges both domains.

Cross-cloud latency in hybrid architectures

Applications on one cloud, databases on another. The railroad operator initially considered OCI for databases and Azure for applications and found the latency unacceptable.

Post-Migration Considerations

A successful cutover is a milestone, but the operational reality of running Oracle in the cloud introduces its own set of challenges.

Performance tuning. Cloud storage and networking behave differently than on-premises infrastructure. SGA/PGA sizing, I/O calibration, and memory allocation typically need adjustment. Plan for 2–4 weeks of optimization post-migration.

Cost management. Cloud costs are variable, and Oracle workloads can be expensive if not right-sized. The railroad operator improved utilization from 15% to 60% through consolidation but that took continuous monitoring, not a one-time exercise.

Operational overhead at scale. Self-managing Oracle on cloud VMs still means patching, backups, HA/DR, monitoring, and security hardening for every instance. This grows quickly across large database fleets.

Compliance. For regulated industries, migration reframes compliance requirements rather than simplifying them. The healthcare data platform needed 100% observability post-migration while maintaining HIPAA compliance throughout.

How Tessell Approaches This Differently

We built Tessell because we saw the same pattern repeatedly: organizations would complete a migration and then spend 6–12 months building the operational infrastructure they should have had from day one. Migration and Day 2 operations were treated as separate problems. They’re not.

Tessell is a multi-cloud DBaaS platform purpose-built for Oracle that unifies migration and ongoing operations in a single control plane across AWS, Azure, GCP, and OCI. No application rewrites. Full Enterprise Edition feature support. An RDS-like managed experience, but without the feature restrictions and with multi-cloud portability.

Migration: Tessell Airdrop

Airdrop automates assessment, infrastructure provisioning, data migration, and validation. Whether you’re migrating from on-premises, Exadata, or RDS, it compresses what typically requires weeks of manual orchestration. For the healthcare data platform, Airdrop enabled production cutover within a 12-hour window for 67.5 TB of data - something a manual approach couldn’t have delivered under HIPAA constraints.

Day 2 Operations

• Automated patching with <15 minutes RTO

• Continuous snapshots and log backups with zero data loss

• One-click HA failover: <1 minute same-zone, <3 minutes multi-AZ

• Cross-region DR: <8 minutes RTO, <5 minutes RPO

• Built-in data governance, masking, and compliance via Availability Machine

• Centralized license tracking and cost visibility across multi-cloud fleets

Performance

Tessell leverages directly attached NVMe storage to deliver over 1 million IOPS for Oracle workloads. Independent SLOB benchmarks show Tessell delivering 1,103% higher IOPS than AWS RDS for Oracle (165,000 vs. 15,000). Landis+Gyr, running real-time telemetry from millions of smart meters, achieved >99.99% application availability on Tessell.

Results Across Our Customer Base

Best Practices for Long-Term Success

Migration is the beginning of your cloud journey. These practices separate organizations that get sustained value from those that recreate on-premises complexity at cloud prices.

• Standardize operations across your fleet. Same patching cadence, backup policies, monitoring thresholds, and governance - regardless of cloud. The energy company’s fragmentation across OCI, on-prem, and Azure was a direct result of not establishing this early.

• Automate from day one. Manual backups, patching, and DR testing don’t scale. The railroad operator achieved 10x faster provisioning through automation. At 500+ databases, manual processes would have been untenable.

• Monitor costs and consolidate aggressively. The railroad operator improved utilization from 15% to 60%; the energy company achieved 50% compute savings. These don’t happen passively.

• Design for multi-cloud from the start. Even if migrating to a single cloud today, architect your operational layer to be portable. Multi-cloud flexibility is negotiating leverage, not a theoretical benefit.

• Plan modernization as a second phase. Lift and shift gets you to the cloud. Once stable, evaluate consolidation, version upgrades, and cloud-native adoption. Don’t try both simultaneously.

Conclusion

Lift and shift remains the fastest, lowest-risk path to getting Oracle workloads into the cloud. But execution quality determines whether that speed translates into lasting value or months of post-migration firefighting.

The organizations that get this right share common traits: rigorous pre-migration planning that accounts for licensing and architecture complexity, a migration method matched to their actual constraints, and critically a plan for Day 2 operations that goes beyond “we’ll figure it out once we’re there.”

At Tessell, we built a platform that bridges the gap between migration and operations because we saw too many enterprises treat them as separate problems. Migration automation, multi-cloud management, enterprise-grade HA/DR, and unified governance in one service, from day one. Not lift and shift. Lift, migrate, and shine.

Ready to simplify your Oracle cloud migration? Explore Tessell DBaaS or book a demo to see how Tessell Airdrop can move your Oracle workloads to any cloud with zero downtime.