Overview

This guide covers migrating workloads from physical x86 servers to Oracle Cloud Infrastructure (OCI), either as OCI Native Compute Instances or as virtual machines in Oracle Cloud VMware Solution (OCVS).

Physical-to-cloud migration is typically chosen for:

• Legacy applications
• Hardware refresh initiatives
• Data center exit strategies
• Platform consolidation programs

Unlike virtual migrations, physical-to-cloud transformation introduces hardware abstraction, operating system considerations, and licensing implications.

Introduction

Oracle Cloud Infrastructure (OCI) provides global-scale infrastructure services designed for enterprise-grade workloads.

Migrating physical infrastructure to OCI enables organizations to:

• Modernize legacy estates
• Improve scalability and elasticity
• Reduce hardware lifecycle management overhead
• Consolidate fragmented environments

Two primary target platforms exist in OCI for physical migrations:

• Oracle Cloud VMware Solution (OCVS) – VMware-based lift-and-shift destination
• OCI Native Compute Instances – Replatformed, cloud-aligned workloads

Target Platforms

OCI Native Compute Instances

Key Characteristics:

• Hypervisor: OCI Compute Service
• Management: OCI Console / CLI / API
• Networking: OCI Virtual Cloud Network (VCN)
• Storage: OCI Block Volumes
• Shapes: Flexible OCPU/RAM, DenseIO, GPU, HPC, Ampere
• Ideal For: Modernization, cost optimization, platform consolidation

Oracle Cloud VMware Solution (OCVS)

Key Characteristics:

• Hypervisor: VMware ESXi
• Management: vCenter, NSX, HCX, vSAN
• Networking: NSX
• Storage: vSAN or OCI Block Storage
• Ideal For: VMware-aligned migrations, minimal operational change

Migration Tooling: RackWare

RackWare is a cloud-agnostic workload mobility platform supporting physical-to-cloud (P2V), virtual-to-cloud, and cross-cloud migrations.

The RackWare Management Module (RMM) enables policy-driven replication and orchestration.

Key Benefits

• Broad compatibility (VMware, Hyper-V, KVM, Physical, Kubernetes)
• Agent-based temporary replication model
• Delta-based synchronization
• Multi-wave orchestration
• OCI Marketplace availability
• Migration + DR + Backup in one platform

Physical-to-Virtual (P2V) Migration Model

RackWare performs OS-level replication and transformation to enable migration from physical hardware to virtual environments.

Process Overview

1. Temporary migration agent installed on physical server
2. Full disk replication initiated
3. Incremental delta synchronization maintained
4. Hardware abstraction layer adjusted
5. Virtual instance deployed in OCI or OCVS
6. Controlled cutover executed

This enables structured, low-risk transformation from hardware-bound workloads to virtual infrastructure.

Assessment and Discovery

Physical migrations require deeper validation than virtual migrations.

Workload Discovery & Classification

• Identify hardware specifications
• Map application dependencies
• Classify workloads by criticality

Dependency Mapping

• DNS dependencies
• Firewall policies
• IP preservation requirements
• Hardware-bound services

Right-Sizing & Optimization

Physical servers are frequently over-provisioned.

Migration presents an opportunity to:

• Reduce CPU allocation
• Optimize memory footprint
• Redesign storage tiers
• Improve utilization efficiency

Network & Security Planning

• Design OCI VCN topology
• Plan FastConnect or IPSec
• For OCVS: evaluate L2 extension if IP preservation required

Testing & Validation

• Execute pilot migrations
• Compare performance baselines
• Validate failover and recovery processes

Migration Considerations

Hardware Abstraction

Physical hardware components are replaced with virtual equivalents:

• Physical NIC → Virtual NIC
• RAID controller → Virtual storage abstraction
• BIOS/UEFI adjustments may be required

Storage Considerations

• Physical disks → OCI Block Volumes or vSAN
• RAID reconfiguration may be required
• Evaluate performance tiers (Standard / Balanced / High Performance)
• Large datasets require structured migration windows

Networking Considerations

OCI Native

• IP remapping required
• DNS updates required
• NSGs and security lists must be configured
• Default gateway changes to OCI routing

OCVS

• IP preservation possible via HCX L2 Extension
• Minimal reconfiguration if VMware-aligned

Operating System Considerations

• Replace hardware-specific drivers
• Validate OS support matrix
• Verify OS licensing for virtual environments
• Adjust boot configuration for virtual context

Application-Level Risks

• Hardware-bound legacy applications
• Licensing tied to physical CPU cores
• Latency-sensitive workloads
• Embedded hardware dependencies

These must be validated before final cutover.

Choosing Between OCI Native and OCVS

Choose OCI Native if:

• Modernization is a strategic goal
• OCI-native integration is required
• Cost optimization is a priority
• VMware tooling preservation is not required

Choose OCVS if:

• Operational continuity is critical
• VMware processes must remain unchanged
• IP preservation is mandatory
• Migration aligns with broader VMware estate relocation

Decision Guidance

Physical workloads should be evaluated based on:

• Hardware dependency level
• Required downtime tolerance
• IP preservation requirements
• Future modernization roadmap
• Licensing constraints

In most enterprise programs:

• Legacy + minimal change → OCVS
• Consolidation + modernization → OCI Native

Enterprise & Mission Critical Databases

P2V migrations alone may not be sufficient for:

• Large RDBMS systems (TB–PB scale)
• High transaction systems
• Near-zero downtime environments

Consider hybrid strategy:

• Oracle DB → Data Guard / GoldenGate
• PostgreSQL/MySQL → Native replication
• Active Directory → Additional domain controllers
• Exchange → Hybrid / DAG models

Combining OS-level replication with application-level replication provides stronger RPO/RTO outcomes.

Best Practices

• Execute phased migration waves
• Document IP, DNS, firewall dependencies early
• Validate performance baselines pre/post migration
• Align backup strategy before cutover
• Use migration as modernization opportunity

Strategic Insight

Physical-to-cloud migration is rarely just a technical relocation.

It is often the moment where infrastructure strategy is redefined.

Unlike virtual migrations, P2V forces organizations to re-evaluate:

• Sizing models
• Licensing structures
• Operational processes
• Long-term platform alignment

Handled correctly, this migration path becomes a modernization catalyst — not just a relocation exercise.