Beyond Lift-and-Shift: Migrating Workloads from OCVS to OCI Native Services

A practical guide to lowering TCO, simplifying operations, and unlocking cloud-native capabilities by transitioning from Oracle Cloud VMware Solution to OCI native services.

1. Introduction

Cloud strategies are no longer about lifting and shifting servers — they are about extracting value from the platform underneath. For enterprises that landed on Oracle Cloud through Oracle Cloud VMware Solution (OCVS), a natural next step is to evaluate the move toward OCI native services. This blog post walks through the offerings of both, compares them on technical and commercial dimensions, and explains why migrating from OCVS to OCI Native is increasingly the preferred direction — particularly in light of recent shifts in the VMware ecosystem after the Broadcom acquisition.

2. Understanding the Offerings: OCVS vs. OCI Native

2.1 Oracle Cloud VMware Solution (OCVS)

OCVS provides a fully customer-controlled, native VMware environment hosted on Oracle Cloud Infrastructure. It enables enterprises to seamlessly migrate and run VMware-based workloads in the cloud without refactoring, using the same tools, processes, and policies they rely on today on-premises — vCenter, NSX-T, vSAN, and HCX. OCVS delivers high performance, enhanced security, and integration with OCI services, supporting hybrid and multi-cloud strategies while preserving full compatibility with existing VMware operations.

2.2 OCI Native Compute and Services

OCI Native provides scalable, high-performance virtual machines, bare metal servers, and containerized compute environments to run a broad range of workloads — from monolithic enterprise applications to cloud-native microservices. With flexible shapes, automatic scaling, and consumption-based pricing, OCI Compute lets organizations match resources to exact performance needs. It integrates seamlessly with services such as Autonomous Database, OKE, Object Storage, Functions, Vault, IAM, and Cloud Guard, offering robust security, high availability, and first-class support for automation and DevOps.

Quick TakeOCVS preserves the VMware operating model; OCI Native unlocks the cloud-native operating model. The right choice depends on where your workloads are heading, not just where they came from.

3. Reference Architecture: Side-by-Side

The diagram below contrasts the two stacks. Notice how OCVS keeps an entire VMware control plane (vCenter / NSX / vSAN) sitting between the workload and the OCI fabric, while OCI Native exposes managed services directly to the application layer.


 

4. Key Benefits of Migrating to OCI Native

4.1 Cost Optimization

OCVS delivers value, but it carries the licensing and operational overhead of a full VMware SDDC. Native OCI services replace many of those layers with consumption-based building blocks.

  • Lower TCO: Native OCI services (Compute, Block Volume, File Storage, Object Storage) are typically more cost-effective than running an equivalent VMware stack inside OCVS.
  • Pay-as-you-go: OCI offers per-second/per-OCPU billing and auto-scaling, removing the need to size for peak load.
  • No "double virtualization": OCI Native eliminates the cost of paying for vSphere licensing on top of OCI host capacity.

Example — Right-sizing a Web Tier

A 12-VM web tier originally hosted on a 3-host OCVS SDDC can typically be re-platformed to OCI Native using VM.Standard.E5.Flex shapes behind an OCI Load Balancer, with auto-scaling configurations responding to CPU utilization. Idle hours stop billing the unused OCPUs — something a fixed OCVS SDDC cluster cannot do.

-- Illustrative: provision a flexible-shape compute instance with Terraform $ resource "oci_core_instance" "web_node" { compartment_id = var.compartment_ocid availability_domain = var.ad shape = "VM.Standard.E5.Flex" shape_config { ocpus = 2 memory_in_gbs = 16 } source_details { source_type = "image" source_id = var.ol9_image_ocid } } -- Pay only for what is provisioned; scale OCPUs in seconds.

4.2 Operational Simplification

  • Less overhead: Migrating to OCI removes the burden of managing vCenter, NSX-T, vSAN, and ESXi patching cycles.
  • Managed services: Capabilities such as Autonomous Database, OKE, Functions, and API Gateway are consumed, not operated.
  • Single pane of glass: OCI Console, IAM, Logging, and Monitoring centralize what was previously split between vSphere and OCI.

Example — Database Tier

Instead of patching Oracle Database on a Windows or Linux VM inside OCVS, an OCI Native deployment can run the same workload on Autonomous Database or Base Database Service, where Oracle handles patching, backup, and HA configuration.

-- Inside Autonomous Database: zero infrastructure to manage SQL> SELECT banner FROM v$version; BANNER -------------------------------------------------------------- Oracle Database 23ai Enterprise Edition - Autonomous SQL> -- Patching, backup, scaling: handled by OCI.

4.3 Scalability and Flexibility

  • Elastic resources: OCI Compute shapes can scale OCPU and memory dynamically; OCVS clusters scale by adding entire ESXi hosts.
  • Wide service catalog: Native services unlock AI/ML (OCI Generative AI, Data Science), analytics (Analytics Cloud), and integration (OIC) without leaving the platform.
  • Granular networking: VCN, NSGs, and private endpoints replace heavyweight NSX-T constructs for most use cases.

Example — Burst Capacity

An OKE cluster fronting a containerized application can scale from 5 to 50 worker nodes in minutes via cluster-autoscaler. The equivalent in OCVS would require provisioning ESXi hosts ahead of time, which is slower and far less elastic.

4.4 Enhanced Integration with the Oracle Ecosystem

  • Optimized for Oracle workloads: EBS, Siebel, JD Edwards, PeopleSoft, and Fusion Apps all benefit from OCI's purpose-built networking and Exadata/Autonomous database options.
  • Unified identity: OCI IAM (with Identity Domains) federates across SaaS, PaaS, and IaaS — no separate vCenter SSO to maintain.
  • Lower latency: Native services live inside the same fabric as the workload, removing the encapsulation overhead introduced by NSX-T overlays.

4.5 Security and Compliance

  • OCI Native security: Vault (KMS), Cloud Guard, Security Zones, Web Application Firewall, and Bastion are all first-class services.
  • Reduced attack surface: Removing the VMware control plane removes a category of CVEs and patch dependencies.
  • Compliance posture: OCI services map directly to controls in NCA ECC, ISO 27001, SOC 2, and PCI DSS — particularly relevant for KSA-regulated workloads.
TipUse OCI Security Zones on the target compartments before migration. This blocks misconfigurations (e.g., public buckets, unencrypted volumes) at the platform level, not just through audit policies after the fact.

4.6 Modernization Opportunities

  • Application modernization: Re-platform monoliths into containers on OKE or break them into Functions where the workload is event-driven.
  • DevOps enablement: OCI DevOps, Resource Manager (Terraform), and integrations with GitHub/GitLab support modern CI/CD pipelines natively.
  • Data & AI: Once on OCI Native, workloads sit next to Generative AI, Vector DB, and Data Lake services without extra egress.

Example — From VM to Container

A Java application that previously ran on three VMware VMs behind an NSX load balancer can be containerized and deployed to OKE with horizontal pod autoscaling. The result: smaller blast radius, faster deployments, and a foundation for further decomposition into microservices.

5. Impact of the Broadcom Acquisition on VMware Customers

The Broadcom acquisition of VMware introduced significant changes that continue to affect customers across licensing, support, and product strategy. Many enterprises have raised concerns about:

  • The shift to subscription-only licensing, replacing perpetual licenses.
  • Cost increases tied to bundled SKUs and minimum core commitments.
  • Roadmap uncertainty for several VMware products that were either sunset, divested, or repackaged.
  • Changes to partner programs and tiered support structures.

As a result, many VMware customers are reassessing their virtualization and cloud strategies — accelerating moves to public cloud platforms, adopting alternative hypervisors, or, where they remain on VMware, choosing managed offerings like OCVS as a stabilization layer while planning a deeper transition to OCI Native.

Strategic InsightOCVS is an excellent landing zone from on-premises VMware. OCI Native is where most customers ultimately want to live. Treating OCVS as a transitional state — rather than the destination — preserves long-term flexibility and cost control.

6. Migration Examples and Patterns

6.1 The Three Common Patterns

PatternDescriptionBest FitTypical Tooling
Rehost (Lift & Shift)VMs from OCVS are migrated to OCI Compute as VMs with minimal changes.Legacy apps with no modernization budget; quick exit from VMware.RackWare, OCI Migration Hub, custom rsync/AMI workflows.
Replatform (Lift & Optimize)Workloads move to OCI Native and adopt one or more managed services (e.g., Autonomous DB, OCI Load Balancer).Oracle DB tiers, web tiers, middleware that benefits from managed HA.Data Pump, GoldenGate, Zero Downtime Migration (ZDM).
Refactor (Modernize)Application is re-architected for containers, microservices, or serverless.Customer-facing apps, APIs, AI-augmented workloads.OKE, Functions, OCI DevOps, API Gateway.

6.2 Worked Example — EBS Tier Migration

Consider an Oracle E-Business Suite environment running inside OCVS on three VMware VMs (DB, Apps, OHS). A target OCI Native pattern would look like:

  1. Database tier: Migrate Oracle DB to VM.Standard.E5.Flex + Block Volumes, or to Base Database Service / ExaDB-D for production-grade HA.
  2. Application tier: Run the EBS apps node on a flexible-shape OCI VM, using OCI File Storage for the shared APPL_TOP filesystem.
  3. Web tier: Front the apps node with OCI Load Balancer + WAF, replacing the OCVS-internal NSX load balancer.
  4. Backup & DR: Adopt OCI Object Storage with lifecycle rules for RMAN backups; use cross-region replication for DR rather than VMware SRM.
-- Validate target DB after migration SQL> SELECT name, open_mode, database_role FROM v$database; NAME OPEN_MODE DATABASE_ROLE --------- -------------------- ---------------- EBSPROD READ WRITE PRIMARY SQL> SELECT module, COUNT(*) FROM v$session GROUP BY module; -- Confirms application connectivity post-cutover.

7. Decision Matrix: When to Stay on OCVS vs. Move to OCI Native

DriverStay on OCVSMove to OCI Native
Workload typeLegacy VMware-centric apps with strict toolchain dependenciesOracle DB, web/app tiers, containerizable workloads
Operational modelExisting VMware operations team; vCenter is a hard requirementReady to adopt OCI Console, IaC, and DevOps practices
Cost profileStable, predictable, peak-sized workloadsVariable load, need for elasticity and per-second billing
Modernization roadmapNo near-term plan to refactorContainers, microservices, AI/ML on the roadmap
Compliance & sovereigntyNeed exact replica of on-prem VMware controlsAdopting OCI Security Zones, Cloud Guard, KSA NCA-aligned controls
Licensing exposureComfortable with subscription-based VMware costsWant to reduce VMware licensing footprint

8. Conclusion

From a technical standpoint, OCI Compute provides a more scalable, flexible, and cloud-native foundation than OCVS. It integrates natively with services such as Load Balancer, Object Storage, Autonomous Database, and OKE, enabling efficient deployment of modern, cloud-optimized applications. It supports autoscaling, custom images, flexible shapes, and infrastructure-as-code (Terraform / Ansible) for streamlined DevOps workflows.

OCVS, by contrast, offers a fully managed VMware environment that is ideal for legacy workloads, minimum-change migrations, or customers who need to preserve their VMware operating model during a transition. It comes with higher operational overhead, more layers to secure, and less direct integration with native OCI services.

For organizations aiming to modernize infrastructure, reduce TCO, and embrace a cloud-native architecture — particularly in the post-Broadcom landscape — OCI Native is the preferred technical direction. A pragmatic path is to land on OCVS where speed of migration matters, then progressively re-platform tiers (database, web, integration, analytics) onto OCI Native services, harvesting cost, agility, and security benefits along the way.

Final ThoughtThe question is no longer "VMware or OCI?" — it is "how quickly can we move from running infrastructure to consuming services?" OCI Native is the answer for most enterprise workloads.
Thanks for reading.
BR,
Zaheer

Techvisions — Cloud & Infrastructure Practice

Comments

Popular posts from this blog

Installation of Oracle Applications R12.1.1 on Linux and vmware

Oracle AVDF Installation and Setup Document

Disable Firewall on Oracle Linux 8