Oracle Cloud Migrations Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Compute

1. Introduction

Oracle Cloud Migrations is an Oracle Cloud (OCI) Compute-focused migration service designed to help you move server workloads (typically virtual machines) into OCI Compute with a guided, repeatable process.

In simple terms: it helps you lift-and-shift existing servers into Oracle Cloud so you can run them as OCI instances with minimal redesign—while still giving you checkpoints to validate, test, and cut over safely.

Technically, Oracle Cloud Migrations provides a migration control plane in OCI for discovering source workloads, replicating VM disks and configuration, and launching equivalent OCI Compute instances in a target compartment, VCN, and subnet. It integrates with core OCI services such as Identity and Access Management (IAM), Networking (VCN), Block Volumes, Object Storage (in some workflows), Audit, and Work Requests for governance and operations.

The problem it solves: migrations fail when they are treated as ad-hoc copy operations. Oracle Cloud Migrations addresses the hard parts—inventory, repeatability, replication, cutover orchestration, and operational visibility—so teams can migrate server workloads into OCI with less risk and better control.

Naming note (important): In the OCI Console and documentation, this capability is commonly presented as Cloud Migrations. This tutorial uses Oracle Cloud Migrations as the primary name (as requested) and treats “Cloud Migrations” as the console/documentation label. Verify the latest naming in the official docs: https://docs.oracle.com/en-us/iaas/Content/cloud-migrations/home.htm

2. What is Oracle Cloud Migrations?

Official purpose (what it’s for)
Oracle Cloud Migrations is intended to help you migrate server workloads—most commonly VMware-based virtual machines and similar VM workloads—into OCI Compute by using a managed migration workflow: discover, assess (where available), replicate, test, and cut over.

Core capabilities (what it can do)
Capabilities vary by supported source types and current OCI release, but the service is generally centered around:

Creating a migration project to organize migrations
Connecting to a source environment (for example, a virtualization environment such as VMware) for discovery/inventory (where supported)
Replicating workloads to OCI (disk data and some configuration)
Launching OCI Compute instances from the replicated state
Tracking progress via status, work requests, and console activity

If you need database-specific migrations, application refactoring, or data pipeline moves, OCI provides separate services (for example, OCI Database Migration, GoldenGate, Data Transfer). Oracle Cloud Migrations is primarily about Compute / server workload migration.

Major components (how it’s structured)
Common conceptual components you’ll see in Oracle Cloud Migrations workflows include:

Migration projects: A logical container for migrations and related configuration, scoped to a compartment.
Migration resources: The individual migrations you create per VM/workload.
Replication and staging: The mechanism and OCI-side resources that receive replicated disk data and make it launchable.
Work requests / jobs: Asynchronous operations that track progress and failures in OCI.

Exact component names in your tenancy may differ slightly by region or service version—verify against the current console and docs.

Service type (control plane vs. data plane)
Oracle Cloud Migrations is primarily a managed control plane in OCI that orchestrates migration operations. The actual data movement uses replication/staging infrastructure that interacts with source environments and OCI storage/compute resources.

Regional vs. global; scope

Regional: OCI services like this are typically regional—you choose a target region where the migration project and target instances will live.
Compartment-scoped: Resources are created and governed within an OCI compartment, controlled by IAM policies.
Tenancy-wide governance: You can enforce tagging, audit, and guardrails at the tenancy level.

How it fits into the Oracle Cloud ecosystem
Oracle Cloud Migrations sits in the Compute migration toolkit of OCI and commonly integrates with:

OCI Compute: target runtime for migrated instances
VCN (Networking): subnets, security lists/NSGs, routing, NAT/IGW
Block Volumes: boot and data volumes for instances
IAM: least-privilege access, compartments, dynamic groups (in some patterns)
Vault: storing secrets/credentials (recommended)
Logging, Audit, Events: operational monitoring and compliance trails

3. Why use Oracle Cloud Migrations?

Business reasons

Reduce migration risk: Use a structured workflow instead of “copy a disk and hope it boots.”
Shorten project timelines: Repeatable steps and clearer visibility reduce rework and downtime.
Enable phased migration: Migrate in waves aligned to business priorities (dev/test first, then production).

Technical reasons

Lift-and-shift for Compute: Suitable when you want to move VMs with minimal code change.
Support for iterative replication: Lets you keep syncing changes until cutover.
Target OCI-native constructs: Launch to OCI instances in a VCN/subnet with OCI security controls.

Operational reasons

Central visibility in OCI Console: track migration status, tasks, failures.
Work-request-based operations: asynchronous operations are auditable and observable.
Standard OCI governance: compartments, tagging, audit logs.

Security / compliance reasons

IAM policy control: restrict who can create migrations, who can launch instances, who can access logs.
Auditability: OCI Audit logs record control plane actions.
Network isolation: place replication and target instances in private subnets, use VPN/FastConnect.

Scalability / performance reasons

Parallel migration waves: organize projects and migrate many VMs with consistent patterns.
Right-size in OCI: modernize shapes, adjust CPU/memory, and adopt OCI features post-migration.

When teams should choose Oracle Cloud Migrations

Choose it when:

You are migrating server/VM workloads into OCI Compute
You need repeatable migration orchestration instead of one-off manual conversions
You want OCI-native governance (compartments, policies, tags, audit trails)
You have network connectivity and access to source environments to support replication

When teams should not choose it

Consider alternatives when:

You need application refactoring, not lift-and-shift (consider containers, OKE, or app modernization)
You’re primarily migrating databases (consider OCI Database Migration, Data Pump, GoldenGate)
You cannot meet connectivity/security requirements between source and OCI
Your source platform isn’t supported by the service’s current capabilities (verify in docs)

4. Where is Oracle Cloud Migrations used?

Industries

Financial services (regulated workloads needing audit trails)
Healthcare (controlled cutovers, traceability)
Retail/e-commerce (seasonal scaling, cloud adoption)
Manufacturing (legacy on-prem VMs moving to cloud)
SaaS providers (infrastructure consolidation into OCI)

Team types

Cloud platform teams migrating shared infrastructure
Infrastructure/virtualization teams moving VMware estates
SRE/operations teams standardizing backup/monitoring post-move
Security teams enforcing segmentation and IAM guardrails
DevOps teams migrating CI/CD runners, build servers, jump boxes

Workloads

Linux/Windows application servers
Web/API tiers
Batch processing workers
Enterprise middleware running on VMs
Third-party vendor appliances (verify supportability/licensing)

Architectures and contexts

Hub-and-spoke VCN networks with centralized security services
Private subnets with NAT for egress and load balancers for ingress
Hybrid connectivity via IPSec VPN or FastConnect to on-prem data centers
Migration factory: waves, runbooks, and repeatable landing zones

Production vs. dev/test usage

Dev/test: validate patterns (subnets, DNS, IAM, boot behavior), build runbooks, baseline performance.
Production: staged replication, change windows, pre-cutover checks, controlled cutover with rollback plan.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Oracle Cloud Migrations (Compute category) is commonly used.

1) VMware estate lift-and-shift into OCI Compute

Problem: Hundreds of VMware VMs must move off aging hardware.
Why this fits: Structured migration projects and orchestration reduce manual conversions.
Example: Migrate 200 mixed Linux/Windows VMs over 6 waves into OCI with minimal app changes.

2) Data center exit with phased cutover

Problem: Lease ends in 6 months; must evacuate workloads safely.
Why this fits: Replicate ahead of time and cut over in a controlled maintenance window.
Example: Replicate web tier continuously; final cutover happens overnight with DNS updates.

3) Migrate legacy apps to OCI before modernization

Problem: Apps are too risky to refactor now, but must move to cloud.
Why this fits: Lift-and-shift to OCI first; modernize later.
Example: Move a monolithic Java app VM to OCI, then containerize after stabilization.

4) Hybrid burst and DR seeding

Problem: Need a standby environment in OCI for disaster recovery.
Why this fits: Replication workflows can help seed OCI-side copies for DR planning (verify exact DR features in docs).
Example: Keep a warm copy in OCI and periodically test failover.

5) Standardize governance during migration (compartments/tags)

Problem: On-prem lacks consistent ownership and cost allocation.
Why this fits: OCI compartments and mandatory tags enforce structure.
Example: Every migrated VM is tagged with cost center, app ID, environment, owner.

6) Re-platform network/security while keeping servers intact

Problem: Need new segmentation and security posture without changing apps.
Why this fits: Launch migrated instances into hardened VCNs and NSGs.
Example: Place app servers in private subnets and front them with OCI Load Balancer + WAF.

7) Migrate build agents and CI runners

Problem: Build farm is capacity constrained and costly to maintain.
Why this fits: Lift-and-shift build VMs quickly; later convert to autoscaled pools.
Example: Move Jenkins agents, then rebuild them as immutable images post-migration.

8) Vendor appliance migration (when supported)

Problem: A vendor VM appliance must run in OCI.
Why this fits: VM migration reduces changes (but licensing/support must be verified).
Example: Migrate a monitoring appliance VM; validate vendor support in OCI.

9) Consolidate multi-region workloads into a single OCI region

Problem: Too many small sites; want centralized operations.
Why this fits: Migration projects support organized consolidation waves.
Example: Migrate branch office app servers into OCI, connect via VPN.

10) Migrate with pre-cutover testing to reduce downtime

Problem: Apps have strict availability requirements.
Why this fits: Test launches before final cutover reduce surprises.
Example: Launch test instances in isolated subnet; run functional checks; then cut over.

11) Migrate to OCI to use OCI-native backup and monitoring

Problem: On-prem backup tools are inconsistent across teams.
Why this fits: After migration, standardize on OCI Block Volume backups and OCI Monitoring.
Example: Apply backup policies to all migrated boot/data volumes.

12) Migrate “snowflake” servers with unknown dependencies (first step)

Problem: Poor documentation; need to move but dependencies are unclear.
Why this fits: Migration projects provide a trackable path; you can instrument and discover dependencies post-move.
Example: Migrate a legacy reporting server first, then map downstream connections in OCI.

6. Core Features

Feature availability can vary by region and source platform support. Always verify the latest feature set in the official Oracle Cloud Migrations documentation: https://docs.oracle.com/en-us/iaas/Content/cloud-migrations/home.htm

1) Migration projects (organization and governance)

What it does: Groups migrations under a project boundary in a compartment.
Why it matters: Enables wave planning, ownership, and consistent configuration.
Practical benefit: Separate dev/test vs prod projects; separate per business unit.
Limitations/caveats: Projects don’t replace proper compartment design; use compartments for isolation.

2) Source environment connectivity and discovery (where supported)

What it does: Connects Oracle Cloud Migrations to a source virtualization environment to list VMs/assets.
Why it matters: Inventory is the starting point for reliable migrations.
Practical benefit: Reduces spreadsheet-based tracking and missed dependencies.
Limitations/caveats: Requires access and credentials to source platforms; ensure security review.

3) Replication/staging orchestration

What it does: Coordinates disk replication from source to OCI staging so instances can be launched.
Why it matters: Migrations fail most often due to inconsistent disk transfers.
Practical benefit: More predictable cutovers with iterative syncing.
Limitations/caveats: Requires sufficient bandwidth and time; large disks can take days.

4) Test launch before cutover (typical migration pattern)

What it does: Allows launching a migrated instance for testing before final production cutover.
Why it matters: Validates boot, networking, application behavior, and performance.
Practical benefit: Catch driver, NIC naming, DNS, or firewall issues early.
Limitations/caveats: Ensure test isolation to avoid IP conflicts or accidental production traffic.

5) Target configuration mapping (OCI shapes, network placement)

What it does: Launches into selected VCN/subnet and OCI Compute shape.
Why it matters: Landing zone compliance (subnets, NSGs, routing, IAM).
Practical benefit: Align with security segmentation and operational model.
Limitations/caveats: Some source settings won’t map 1:1; plan for post-launch changes.

6) Work Requests and operational status tracking

What it does: OCI-style asynchronous operation tracking for migrations and related actions.
Why it matters: Provides auditability and a place to troubleshoot failures.
Practical benefit: Standard operator workflow: check Work Requests for errors.
Limitations/caveats: Work request error messages can be terse; correlate with logs.

7) Integration with OCI IAM, compartments, and tagging

What it does: Applies OCI-native access control and organization.
Why it matters: Migrations involve powerful permissions (compute, volumes, networking).
Practical benefit: Least privilege, separation of duties, cost allocation.
Limitations/caveats: Misconfigured IAM is a common blocker; validate policies early.

8) Compatibility handling and post-migration adjustments (typical requirement)

What it does: Helps you move the VM; you still validate OS drivers, network config, cloud-init, etc.
Why it matters: Boot success ≠ application readiness.
Practical benefit: Establish post-migration runbooks: update NIC config, install OCI agents, etc.
Limitations/caveats: Some OS/app issues must be fixed manually; plan time for remediation.

7. Architecture and How It Works

High-level architecture

Oracle Cloud Migrations generally works as an orchestrator that:

Lets you define a migration project and connect to a source environment (where supported).
Select a VM/workload to migrate.
Replicates VM disk data to OCI staging using a replication mechanism.
Creates a launchable state (for example, a boot volume or custom image-like artifact).
Launches an OCI Compute instance into your selected network and compartment.

Request/data/control flow (conceptual)

Control plane: User actions in OCI Console/API create migration resources, initiate replication, and trigger launches.
Data plane: Disk data flows from the source environment to OCI staging over the network (VPN/FastConnect/public internet depending on design).
Outcome: OCI creates an instance with attached boot/data volumes representing the migrated workload.

Integrations with related services

Compute: target instances; shapes and instance configuration
Block Volume: staging/boot/data volumes created during migration
VCN: subnets, route tables, security lists/NSGs for replication and target workloads
IAM: policies to manage migrations and dependent resources
Vault (recommended): store secrets used by connectors or appliances
Audit: records migration actions for compliance
Monitoring/Logging: track instance health and operational metrics after launch

Dependency services

At minimum, most migrations depend on:

A target VCN and subnet
Quota/limits for Compute instances and Block Volumes
IAM privileges to create and manage the above

Security/authentication model

Human operators authenticate using OCI IAM (SSO/federation possible).
Access is authorized by IAM policies on compartments.
Source-side connectivity typically requires credentials and secure network paths; treat these as sensitive and handle with Vault where possible.

Networking model

You have two main networking concerns:

Migration/replication connectivity between source and OCI
– Often via IPSec VPN or FastConnect for predictable throughput and security. – Public internet can work for some scenarios, but security and performance must be assessed.
Target runtime networking in OCI
– Place migrated instances in appropriate subnets (private vs public). – Use NSGs/security lists to enforce least-privilege traffic. – Integrate with Load Balancers, Bastion, WAF, DNS as needed.

Monitoring/logging/governance considerations

Use OCI Audit to track who initiated migrations and instance launches.
Use Work Requests for the migration service operations.
Use OCI Monitoring and Logging on target instances after cutover (OS Management/Compute agent as appropriate).
Apply tags for cost tracking from day one (migration project and launched instances).

Simple architecture diagram (conceptual)

flowchart LR
  U[Engineer / Migration Operator] -->|Console/API| OCM[Oracle Cloud Migrations<br/>(Control Plane)]
  OCM --> WR[Work Requests / Status]

  subgraph Source[Source Environment]
    VC[vCenter / Hypervisor<br/>+ Source VMs]
  end

  subgraph OCI[Oracle Cloud (Target Region)]
    VCN[VCN + Subnets]
    STG[Staging: Block Volumes / Artifacts]
    CMP[OCI Compute Instances]
  end

  VC -->|Replication data flow| STG
  OCM -->|Orchestrates| STG
  STG -->|Launch| CMP
  CMP --> VCN

Production-style architecture diagram (migration factory)

flowchart TB
  subgraph Org[Enterprise Governance]
    IAM[IAM: Groups/Policies<br/>Dynamic Groups]
    TAG[Tagging & Cost Mgmt]
    AUD[Audit]
  end

  subgraph Net[Hybrid Network]
    DC[On-Prem DC<br/>VMware / VMs]
    VPN[IPSec VPN / FastConnect]
    HUB[OCI Hub VCN<br/>Firewall/NVA (optional)]
    SPOKE[Spoke VCNs<br/>Prod / Nonprod]
  end

  subgraph Mig[Oracle Cloud Migrations]
    PROJ[Migration Projects<br/>Waves & Runbooks]
    REPL[Replication / Staging]
    WRQ[Work Requests]
  end

  subgraph Runtime[OCI Runtime]
    CMP[Compute Instances]
    BLK[Block Volumes<br/>Boot/Data]
    LB[Load Balancer]
    OBS[Observability<br/>Monitoring/Logging]
    BCP[Backups / DR pattern]
  end

  IAM --> Mig
  TAG --> Mig
  AUD --> Mig

  DC --> VPN --> HUB --> SPOKE
  PROJ --> REPL --> BLK --> CMP
  CMP --> LB
  CMP --> OBS
  BLK --> BCP
  Mig --> WRQ
  SPOKE --> Runtime

8. Prerequisites

Tenancy / account requirements

An active Oracle Cloud (OCI) tenancy with permissions to create and manage Compute, Networking, and Storage resources.
Access to the target compartment where you will create migration projects and launch instances.

Permissions / IAM roles

You need IAM permissions to:

Manage Oracle Cloud Migrations resources in the target compartment
Create/manage dependent resources (commonly: instances, volumes, VCN/subnets, VNICs)

OCI uses policy language like “Allow group … to manage … in compartment …”. The exact policy verbs/resources for Oracle Cloud Migrations can evolve. Start here and verify in current docs:

Cloud Migrations docs: https://docs.oracle.com/en-us/iaas/Content/cloud-migrations/home.htm
IAM policy reference: https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/policygetstarted.htm

A practical approach is to use a dedicated group (for example, MigrationAdmins) and grant only what is required in the specific compartment(s). If you have a platform team, split duties:

Migration operators: manage migration projects and launches
Network team: manage VCN/subnets/NSGs
Security team: manage Vault, KMS keys, and audit settings

Billing requirements

Oracle Cloud Migrations itself may not be separately metered, but migrations typically create chargeable resources (Compute, Block Volumes, network egress). Treat this as a billable project.
Ensure you can use the Cost Estimator and review the price list:
OCI pricing: https://www.oracle.com/cloud/price-list/
OCI cost estimator: https://www.oracle.com/cloud/costestimator.html

Tools

OCI Console access
SSH client for Linux instance validation
(Optional) OCI CLI for related tasks (networking, instances)
OCI CLI: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm

Region availability

Oracle Cloud Migrations availability can vary by region. Verify in the service documentation or the OCI console service list for your region.

Quotas / limits

Check quotas/limits for:

Compute instances (including any staging/replication instances if applicable)
Block Volumes (total GB and volume count)
VNICs, subnets, and public IPs (if used)
Object Storage (if the workflow uses buckets)

Limits are tenancy and region specific. Verify in the OCI console: Governance & Administration → Limits, Quotas and Usage (exact menu naming may vary).

Prerequisite services and setup

At minimum:

A target VCN and subnet (private subnet recommended for production)
Security rules for:
Replication traffic (source → OCI)
Operator access (SSH via Bastion or private access)
Connectivity plan:
Prefer VPN or FastConnect for enterprise migrations
For labs/POCs, public internet may be possible but must be security-reviewed

9. Pricing / Cost

Oracle Cloud Migrations cost modeling is mainly about the resources it uses, not just the migration UI.

Pricing dimensions (what you pay for)

You typically pay for:

OCI Compute instances used during migration and after cutover (target instances; and any staging/replication compute components, if your workflow provisions them)
Block Volumes:
Boot volumes and data volumes created for migrated instances
Any staging volumes used during replication
Backups/snapshots you keep
Object Storage (if used by the workflow or for logs/artifacts)
Network:
Ingress is often free, but egress (OCI → internet) is typically charged
Data transfer across regions (if applicable) can be charged
FastConnect/VPN costs (ports/provider, etc.) are separate considerations
Load Balancer / WAF / Bastion (if used in your landing zone)

Oracle Cloud Migrations service control plane charges: in many OCI services, the control plane is not separately billed and you pay for underlying resources. Verify the current pricing stance for “Cloud Migrations” in official pricing because service packaging can change.

Price list: https://www.oracle.com/cloud/price-list/
Cost estimator: https://www.oracle.com/cloud/costestimator.html

Free tier

OCI has a Free Tier, but migration projects usually require:

Enough Block Volume GB to stage/launch instances
Network connectivity
Potentially paid shapes for realistic testing

Treat Free Tier as suitable only for very small experiments; verify eligibility and regional availability.

Cost drivers (what makes bills grow)

Total disk size replicated (GB) and number of VMs
Duration of replication/staging resources being kept running
High-performance block volume tiers (if selected)
Retaining snapshots/backups long-term
Egress-heavy testing (downloading packages, logs, or transferring data back out)
Overprovisioning target shapes (CPU/memory)

Hidden or indirect costs

Parallel test instances (test launches can double runtime compute temporarily)
Duplicate storage during staging (source still running + staging volumes + target boot volume)
Operational tooling post-migration (logging, monitoring, third-party agents)
Connectivity (FastConnect ports, partner charges, or VPN operational overhead)

Network/data transfer implications

Migration replication is data-intensive. Even if OCI ingress is not charged, your source environment may have ISP or interconnect costs.
If you run tests that move data back to on-prem or to the internet, OCI egress charges can appear.

How to optimize cost (practical tactics)

Right-size staging resources and keep them only as long as needed.
Migrate in waves; avoid keeping large staging volumes for weeks.
Use private subnets + NAT and minimize unnecessary internet egress.
Right-size instances post-migration and adopt autoscaling patterns where applicable.
Delete failed migrations’ residual volumes (common surprise cost).
Use tags from day one to attribute migration spend.

Example low-cost starter estimate (no fabricated numbers)

A low-cost POC typically includes:

1 small target Compute instance running for a few hours/days
A modest boot volume (and maybe one small data volume)
Minimal egress
Optional Bastion session usage

Because OCI pricing varies by region, shape, and storage performance tier, use the OCI Cost Estimator to model: – “1 instance × N hours” – “boot volume GB × storage tier” – “data volume GB × storage tier” – “snapshot/backups × retention”

Example production cost considerations

For production migration waves, plan for:

Temporary duplication of storage during replication and testing
Multiple parallel migrations requiring extra quotas and staging capacity
DR/backups after cutover (ongoing monthly cost)
Load balancers, WAF, and centralized logging

A common enterprise pattern is to allocate a dedicated “Migration” compartment and track spend with tags: – costCenter, app, env, owner, migrationWave

10. Step-by-Step Hands-On Tutorial

This lab walks through a realistic, common scenario: migrating a VMware VM into OCI Compute using Oracle Cloud Migrations (Cloud Migrations).

Because Oracle Cloud Migrations commonly targets VMware-based environments, this tutorial assumes you have VMware vCenter access. If you don’t have VMware available, you can still use this as a runbook template and follow the same OCI-side steps in a corporate lab.

The exact screen names and required connectors/appliances can change. Follow the latest steps in the official docs while using this lab as the end-to-end blueprint: https://docs.oracle.com/en-us/iaas/Content/cloud-migrations/home.htm

Objective

Migrate a single Linux VM from a VMware environment to OCI Compute using Oracle Cloud Migrations, then validate the migrated instance boots and is reachable via SSH.

Lab Overview

You will:

Prepare an OCI landing zone (compartment, VCN/subnet, IAM access).
Create an Oracle Cloud Migrations project in OCI.
Connect Oracle Cloud Migrations to your VMware source (via the supported connector/appliance method in the docs).
Discover the source VM and create a migration.
Start replication and wait for it to become launch-ready.
Launch a test instance in OCI and validate.
Clean up staging and test resources to control cost.

Step 1: Prepare the OCI target environment (network + access)

Goal: Have a VCN/subnet where the migrated instance will launch, with safe access.

1) Create (or choose) a compartment, for example: – cmp-migrations-lab

2) Create a VCN (if you don’t already have one): – Name: vcn-migrations-lab – CIDR: 10.10.0.0/16

3) Create subnets: – Private subnet for migrated instances: subnet-private-app (example: 10.10.10.0/24) – Optional public subnet for a bastion host or temporary test host: subnet-public-bastion (example: 10.10.1.0/24)

4) Provide admin access pattern (choose one): – Recommended: Use OCI Bastion for SSH access to private instances (verify Bastion setup in docs). – Simpler lab option: Launch the test instance with a public IP temporarily, then remove later.

5) Security rules: – If using a public IP temporarily, allow inbound TCP/22 from your IP only. – Otherwise, allow SSH only from your bastion subnet or bastion service.

Expected outcome – You have a compartment, VCN, and subnet ready for a new OCI instance.

Verification – In OCI Console, confirm the VCN and subnet exist and are in the correct region/compartment.

Step 2: Confirm IAM access for migration operators

Goal: Ensure you can create migration resources and dependent compute/storage resources.

1) Create or identify an IAM group for operators, e.g.: – grp-migration-operators

2) Add your user to the group.

3) Create compartment-scoped policies that allow the group to manage required resources.

Because exact resource families for Oracle Cloud Migrations can change, use the docs to confirm. Start by reviewing: – Cloud Migrations IAM requirements: https://docs.oracle.com/en-us/iaas/Content/cloud-migrations/home.htm – IAM policy language basics: https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/policygetstarted.htm

Expected outcome – Your user can create a migration project and launch instances into the target compartment.

Verification – In the OCI Console, navigate to Oracle Cloud Migrations (Cloud Migrations). You should be able to create a project without authorization errors.

Common error – NotAuthorizedOrNotFound when creating projects or launching instances
Fix: Expand IAM policies to include required dependent resources (Compute, Volumes, Networking) in the correct compartment.

Step 3: Create an Oracle Cloud Migrations project

Goal: Create a project container for your migration.

1) In OCI Console, open: – Oracle Cloud Migrations (often labeled Cloud Migrations)

2) Click Create project: – Name: proj-vmware-to-oci-lab – Compartment: cmp-migrations-lab

3) Add tags (optional but recommended): – env=lab – owner=<yourname> – app=migration-lab

Expected outcome – A migration project exists and is visible in the project list.

Verification – Open the project details page and confirm status is active/available.

Step 4: Connect Oracle Cloud Migrations to VMware (source setup)

Goal: Allow the service to discover your VMware inventory and replicate a VM.

The VMware connection step is the most environment-specific part. Oracle typically provides a supported connector/appliance approach (often an OVA deployed into VMware) or another supported mechanism. Follow the current doc instructions for “Connect to VMware/vCenter” in Oracle Cloud Migrations.

High-level steps you should expect (verify exact steps in docs):

1) Download the Oracle-provided migration connector/appliance package (if required) from OCI documentation or console workflow.

2) Deploy the appliance into your VMware environment: – Deploy OVA/OVF into a VMware cluster with network access to: – vCenter – Source VM datastores – The route to OCI target region endpoints (via VPN/FastConnect/internet)

3) Configure the appliance: – Provide vCenter endpoint and credentials (least privilege recommended) – Provide OCI credentials or registration token (prefer OCI-native secure method as documented) – Select the OCI region and compartment/project for registration

4) Confirm discovery connectivity.

Expected outcome – Oracle Cloud Migrations can communicate with your vCenter and list source VMs.

Verification – In your migration project, go to the discovery/inventory area and confirm VMs appear.

Common errors and fixes – DNS resolution failures: Ensure the appliance can resolve OCI endpoints and vCenter FQDN. – TLS/certificate issues: Use trusted certificates where possible; follow the connector doc guidance. – Network path blocked: Confirm firewall rules allow required outbound ports to OCI.

Step 5: Select a source VM and create a migration

Goal: Define which VM to migrate and where it should land in OCI.

1) In the migration project, choose Create migration (or similar). 2) Select the source VM from the discovered inventory. 3) Provide target settings: – Target compartment: cmp-migrations-lab – Target VCN/subnet: vcn-migrations-lab / subnet-private-app (or public for lab) – Target shape: choose a shape that matches the source VM CPU/RAM as closely as possible – Boot volume size: at least as large as the source disk (add headroom)

4) Save/create the migration.

Expected outcome – A migration object is created with a status like “Created” or “Ready to replicate” (exact wording varies).

Verification – Open migration details and confirm: – Source VM name/ID – Target subnet – Target shape mapping

Common error – Boot volume too small
Fix: Increase boot volume size in migration settings (if supported) or choose correct mapping.

Step 6: Start replication and monitor progress

Goal: Copy disk data from source to OCI staging.

1) From the migration details page, click Start replication (or equivalent). 2) Monitor: – Migration status in the console – Work Requests for errors and progress

Replication time depends on: – Total disk GB – Source disk change rate – Network throughput/latency – Staging/storage performance

Expected outcome – Replication begins; progress updates in status/work requests. – Eventually, the migration becomes launch-ready (wording varies).

Verification – Migration status indicates the VM can be launched or tested. – No failed work requests.

Common errors – Timeouts / connectivity loss
Fix: Confirm stable VPN/FastConnect, avoid packet inspection breaking replication streams, verify MTU. – Insufficient OCI quotas (volumes/instances)
Fix: Request quota increase or free capacity.

Step 7: Launch a test instance in OCI

Goal: Boot the migrated VM as an OCI Compute instance and validate access.

1) Click Launch test instance (or “Launch instance”) from the migration page. 2) Choose: – Subnet: for lab, you may temporarily select a public subnet + public IP – SSH keys: provide your SSH public key for Linux – NSGs/security list: allow SSH from your IP (temporary)

3) Launch and wait for provisioning.

Expected outcome – An OCI instance exists and transitions to Running.

Verification – In Compute → Instances, confirm the instance is running and has: – VNIC attached – Correct subnet – Public IP (if you chose it)

If Linux and you attached your SSH key, connect:

ssh -i ~/.ssh/id_rsa opc@<public_ip>

The username can differ by OS image and migrated configuration. For migrated VMs, the default user may not be opc. Use the OS’s standard user (e.g., ubuntu, ec2-user, etc.) or your existing VM user. Verify the correct login approach in your source VM configuration.

Run basic checks:

uname -a
df -h
ip a
systemctl --failed || true

Expected outcome – The instance is reachable and the OS boots cleanly.

Step 8: Decide cutover approach (test vs. production)

Goal: Plan the last-mile steps safely.

For a real migration cutover, a typical safe approach is:

1) Confirm application behavior on the test instance. 2) Schedule a cutover window. 3) Freeze changes (or stop source VM, depending on app). 4) Perform final sync/replication. 5) Launch the production instance in the correct subnet (private). 6) Update DNS, load balancer backends, firewall rules. 7) Monitor and keep rollback plan.

Expected outcome – You have a clear path to production cutover with minimal downtime.

Validation

Use this checklist:

Migration status indicates replication succeeded and instance launched.
OCI instance boots and is reachable (SSH/RDP as applicable).
Network connectivity works:
Instance can reach required endpoints (DBs, APIs)
Security rules match intended architecture
Storage is consistent:
Expected filesystems present
Data volumes attached (if any)
Services are healthy:
No failed systemd services (Linux)
Application logs show normal startup

Troubleshooting

Common issues and practical fixes:

1) Instance boots but has no network – Cause: NIC naming changes, missing drivers, or wrong subnet/NSG rules. – Fix: Use OCI console serial console (if enabled) for diagnostics; verify DHCP, IP config, and security rules.

2) SSH not working – Cause: Wrong username, key not injected, firewall blocks, or SSH daemon down. – Fix: Confirm inbound rules allow TCP/22 from your IP; confirm correct OS user; use serial console to check /var/log/auth.log or journalctl -u ssh.

3) Replication never becomes launch-ready – Cause: Network instability or insufficient quotas. – Fix: Check Work Requests error messages; verify connectivity; validate limits for volumes and instances.

4) Unexpected costs – Cause: Staging volumes and test instances left running. – Fix: Tag all resources and clean up immediately after test.

Cleanup

To avoid ongoing charges:

1) Terminate the test OCI instance: – Compute → Instances → Terminate – Choose whether to delete attached boot volume (for lab, delete it)

2) Delete migration resources: – In Oracle Cloud Migrations project, delete the migration and any staging artifacts (as allowed)

3) Remove or stop replication/staging components (if provisioned): – Any dedicated compute instances and volumes created for replication/staging should be terminated/deleted if not needed

4) On VMware side: – Power off and delete the migration connector/appliance if it was deployed just for the lab

5) Verify no leftover Block Volumes: – Block Storage → Block Volumes / Boot Volumes – Delete unused volumes and old backups/snapshots

11. Best Practices

Architecture best practices

Build a landing zone first: compartments, VCNs, subnets, route tables, DNS strategy, and ingress/egress model.
Use private subnets for production workloads; front with Load Balancers/WAF.
Standardize shapes and OS baselines post-migration (golden images, configuration management).

IAM / security best practices

Implement least privilege: migration operators should not automatically get broad network admin rights.
Use separate compartments for:
migration factory (staging/testing)
production runtime
Use Vault for sensitive secrets used by connectors (where supported).
Enable and monitor Audit logs for migration-related actions.

Cost best practices

Treat staging resources as temporary—delete quickly after cutover.
Migrate in waves; don’t keep parallel replication running for everything.
Use tags like:
migrationProject, wave, app, env, owner, costCenter

Performance best practices

Size target instances with headroom, then right-size after performance tests.
Place instances in subnets with adequate bandwidth and minimal bottlenecks (avoid over-restrictive middleboxes during testing).
Verify block volume performance tier matches workload requirements.

Reliability best practices

Use test launches and validation before cutover.
Keep rollback plan:
preserve source VM until production is stable
document DNS rollback steps
After cutover, implement backups and (if needed) DR patterns using OCI-native services.

Operations best practices

Use centralized logging/monitoring from day one on target instances.
Define runbooks:
boot failures
network connectivity checks
application smoke tests
Track migrations using tickets and change management; treat cutovers as controlled changes.

Governance / tagging / naming

Use consistent naming:
proj-<source>-to-oci-<wave>
mig-<app>-<env>-<vmname>
inst-<app>-<env>-<role>
Enforce tags via governance policies where applicable.

12. Security Considerations

Identity and access model

Oracle Cloud Migrations actions are governed by OCI IAM.
Restrict who can:
create migration projects
connect to source environments
launch instances
delete migration artifacts (to prevent accidental data loss)

Encryption

OCI encrypts data at rest by default for many storage services; confirm for Block Volumes and backups in your region and tenancy settings.
For sensitive workloads, use customer-managed keys where supported (OCI Vault/KMS) and validate the integration.

Network exposure

Avoid exposing replication endpoints publicly if possible.
Prefer VPN/FastConnect for migration traffic.
Place migrated instances in private subnets; use Bastion for admin access.

Secrets handling

Do not store vCenter credentials or OCI credentials in plain text on admin laptops.
Use OCI Vault for secrets where feasible.
Rotate credentials used by connectors/appliances after migration waves.

Audit/logging

Enable OCI Audit and export logs to a central logging/SIEM pipeline if required.
Review Work Requests and related logs after each migration wave to capture lessons learned.

Compliance considerations

Data residency: keep migrations in the approved OCI region(s).
PII/PHI: ensure encrypted transit paths and controlled operator access.
Change management: migrations should follow your org’s change control process.

Common security mistakes

Launching migrated instances with public IPs permanently.
Overly broad IAM policies (“manage all-resources in tenancy”).
Leaving staging volumes and snapshots accessible to too many users.
Reusing shared admin credentials for connectors.

Secure deployment recommendations

Use a dedicated migration compartment with strict IAM and tag enforcement.
Use private networking and least-privilege security rules.
Maintain an access log of who can initiate cutovers and launches.

13. Limitations and Gotchas

These are common real-world challenges. Confirm exact service limits and supported sources in official Oracle Cloud Migrations docs: https://docs.oracle.com/en-us/iaas/Content/cloud-migrations/home.htm

Source platform support: Not every hypervisor or VM format is supported. Validate compatibility early.
Driver and boot issues: A VM that ran on VMware may require adjustments to boot cleanly on OCI (kernel/initramfs/network config).
Network identity changes: IP addresses, MAC addresses, and interface names may change—plan DNS and firewall updates.
Licensing constraints: Some commercial software licenses are host-locked or restrict cloud deployment.
Cutover complexity: Data consistency and downtime planning are still your responsibility.
Bandwidth and time: Large disks take time; plan replication windows and avoid peak business hours.
Quota surprises: Volume count/size quotas can block migrations late in the process.
Staging cost creep: Staging artifacts left behind can generate ongoing Block Volume charges.
Security constraints: Deep packet inspection or restrictive firewalls can break replication streams.
Operational readiness: Migrated workloads need OCI monitoring, backups, patching, and security baseline after move.

14. Comparison with Alternatives

Oracle Cloud Migrations is one option in a broader migration toolkit.

Alternatives within Oracle Cloud

Custom image import / manual disk conversion: More manual; useful for one-off migrations.
OCI Compute + rsync / backup-restore: Works for file-level migration but not a VM lift-and-shift.
OCI Database Migration: Best for databases, not VM compute lift-and-shift.
OCI GoldenGate: Best for replication-based data migration, not VM migration.

Alternatives in other clouds

AWS Application Migration Service (MGN): Lift-and-shift server migration into AWS.
Azure Migrate: Discovery, assessment, and migration into Azure.
Google Cloud Migrate to VMs: VM migration into Google Cloud.
VMware HCX: Strong for VMware-to-VMware hybrid/cloud mobility, depending on target.

Open-source / self-managed

Backup/restore + rebuild (Veeam, etc.) depending on environment and licensing
Disk conversion tools (qemu-img, etc.) for DIY, but high operational risk at scale

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud Migrations	Migrating VMs into OCI Compute with a guided workflow	OCI-native governance, migration orchestration, repeatable process	Requires supported sources/connectivity; still need OS/app validation	You’re moving VM/server workloads to OCI and want structured migrations
Manual VM conversion + custom images	One-off or niche VM formats	Full control; can work when managed tools don’t	Error-prone, hard to scale, weaker auditing	Small migrations where you can accept manual effort
OCI Database Migration	Database migrations to OCI	Purpose-built for DBs; minimizes downtime with proper strategies	Not for VM lift-and-shift	Your primary scope is databases, not server VMs
AWS MGN	Server migration into AWS	Mature server replication and cutover tooling	Locks into AWS target	Your target is AWS, not OCI
Azure Migrate	Server migration into Azure	Strong assessment and planning tools	Azure-only target	Your target is Azure
Google Migrate to VMs	Server migration into Google Cloud	VM migration tooling for GCP	GCP-only target	Your target is GCP
VMware HCX	VMware mobility/hybrid strategy	Excellent for VMware-centric environments	Depends on VMware stack and target support	You’re staying VMware-first and moving between VMware environments

15. Real-World Example

Enterprise example: regulated company migrating VMware workloads to OCI

Problem: A financial services organization must exit a data center. Workloads are mostly VMware VMs with strict audit requirements and segmented networks.
Proposed architecture:
Build OCI landing zone with hub-and-spoke VCNs
Use VPN/FastConnect for replication traffic
Use Oracle Cloud Migrations projects per wave and business unit
Launch migrated workloads into private subnets behind load balancers
Centralize logging and enable audit exports
Why Oracle Cloud Migrations was chosen:
Provides structured migration control within OCI
Works with OCI IAM/compartments/tags for governance
Supports phased replication and test launches (verify feature behavior in your region)
Expected outcomes:
Predictable migration waves with traceable work requests
Reduced downtime through pre-cutover validation
Improved governance and cost allocation via OCI tagging

Startup/small-team example: lift-and-shift a small set of VMs to OCI

Problem: A startup runs 10 VMs on a small VMware cluster; hardware failures are increasing. They need a fast move without refactoring.
Proposed architecture:
Single VCN with separate subnets for app and admin
Oracle Cloud Migrations project for all VM migrations
Temporary public IPs only during testing; move to private subnets after
Adopt OCI backups and monitoring after cutover
Why Oracle Cloud Migrations was chosen:
Faster and more repeatable than manual disk conversions
Aligns with OCI Compute target environment
Expected outcomes:
Migration completed in days, not weeks
Standardized backups and monitoring
Reduced operational overhead of on-prem hardware

16. FAQ

1) Is Oracle Cloud Migrations the same as “Cloud Migrations” in the OCI Console?
Yes—Oracle commonly labels it “Cloud Migrations” in the console/docs. This tutorial uses “Oracle Cloud Migrations” as the primary name. Verify in docs: https://docs.oracle.com/en-us/iaas/Content/cloud-migrations/home.htm

2) What workloads does Oracle Cloud Migrations target?
Primarily server/VM migrations into OCI Compute. For exact supported sources (VMware versions, OS types), verify the support matrix in the official docs.

3) Does it migrate databases too?
It can migrate a VM that contains a database, but that’s not the same as a database migration strategy. For database-native migration, use OCI Database Migration or related tooling.

4) Is downtime required?
Most migrations require a cutover window to ensure consistency. Replication can reduce downtime, but final cutover planning is still required.

5) Do I need VPN or FastConnect?
Not always, but it’s strongly recommended for production migrations for security and predictable throughput. Public internet migrations require careful review.

6) Can I test the migrated VM before production cutover?
A test launch is a common migration best practice and is typically part of migration workflows. Confirm the exact “test instance” capabilities in your service version/region.

7) What happens to IP addresses and DNS?
IP addresses typically change in OCI. Plan DNS updates, load balancer configuration, and firewall rules as part of the cutover.

8) Can I right-size the VM during migration?
You can usually choose an OCI shape for the target instance. Right-size after performance testing to reduce cost.

9) How do I track failures?
Use migration status plus OCI Work Requests and Audit logs. Work requests often contain the most actionable failure details.

10) What are the biggest causes of migration delays?
Bandwidth constraints, large disks, change rate on source disks, quota limits, and insufficient pre-cutover validation.

11) How do I control cost during migration?
Delete staging artifacts quickly, avoid leaving test instances running, and tag everything for chargeback/showback.

12) Is Oracle Cloud Migrations agent-based or agentless?
It depends on the source type and current implementation. VMware migrations are often connector/appliance based. Verify the specific method for your source platform in docs.

13) Can I use it for cross-region migration?
Oracle Cloud Migrations is typically used to migrate into a selected target region. Cross-region moves may require separate strategies. Verify capabilities and supported patterns.

14) What security controls should I implement?
Least-privilege IAM, private networking, Vault for secrets, audit log export, and strict security rules for replication and admin access.

15) How do I validate application correctness after migration?
Use a runbook: boot validation, network checks, service health checks, application smoke tests, and performance baselines compared to the source.

16) Can I migrate Windows VMs?
Possibly, depending on supported sources and OS requirements. Pay attention to drivers, licensing, and activation. Verify Windows support in official documentation.

17) What’s the recommended order: migrate first or build landing zone first?
Build the landing zone first. Migrations into an unstructured network and IAM environment often create security debt and rework.

17. Top Online Resources to Learn Oracle Cloud Migrations

Resource Type	Name	Why It Is Useful
Official documentation	Oracle Cloud Migrations (Cloud Migrations) Docs — https://docs.oracle.com/en-us/iaas/Content/cloud-migrations/home.htm	Primary source for supported platforms, workflows, and IAM requirements
Official pricing	OCI Price List — https://www.oracle.com/cloud/price-list/	Authoritative pricing reference (region/SKU dependent)
Official calculator	OCI Cost Estimator — https://www.oracle.com/cloud/costestimator.html	Model migration staging + target runtime costs without guessing
Official IAM docs	OCI IAM Overview — https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/overview.htm	Required for least privilege and compartment strategy
Official networking docs	OCI Networking (VCN) Overview — https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/overview.htm	Essential for designing secure replication and target networks
Architecture center	Oracle Architecture Center — https://docs.oracle.com/solutions/	Reference architectures and patterns relevant to landing zones and migrations
Official tutorials/labs	Oracle LiveLabs — https://apexapps.oracle.com/pls/apex/r/dbpm/livelabs/home	Hands-on labs for OCI services (search for migration/compute labs)
Official videos	Oracle Cloud Infrastructure YouTube — https://www.youtube.com/@OracleCloudInfrastructure	Vendor-maintained demos and walkthroughs (verify recency)
CLI docs	OCI CLI Documentation — https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm	Useful for automating validation and related OCI tasks
Community learning	Oracle Cloud Customer Connect — https://cloudcustomerconnect.oracle.com/	Discussions and practical troubleshooting from OCI users (validate against docs)

18. Training and Certification Providers

The following training providers may offer Oracle Cloud and migration-related learning. Verify current course availability directly on their sites.

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams	Cloud/DevOps foundations, CI/CD, operations practices applicable to OCI migrations	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate engineers	DevOps tooling, SCM, automation concepts useful during migration projects	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud ops teams, administrators	Cloud operations and governance practices relevant to post-migration operations	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, reliability engineers	Reliability engineering practices, monitoring, incident response for migrated workloads	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops teams exploring AIOps	Automation/observability concepts that can complement migration operations	Check website	https://www.aiopsschool.com/

19. Top Trainers

These sites are presented as training resources/platforms. Validate current Oracle Cloud offerings and trainer credentials directly.

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training content (verify OCI topics)	Engineers seeking guided training	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training and mentoring (verify OCI topics)	Beginners to intermediate DevOps engineers	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps guidance (verify OCI topics)	Teams needing short-term coaching	https://www.devopsfreelancer.com/
devopssupport.in	Ops/DevOps support and training resources (verify OCI topics)	Operations teams and engineers	https://www.devopssupport.in/

20. Top Consulting Companies

These consulting companies may help with cloud migration planning, landing zones, DevOps, and operations. Validate specific Oracle Cloud Migrations experience directly.

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify OCI offerings)	Migration planning, automation, ops enablement	Build migration runbooks; implement tagging/IAM guardrails; post-migration monitoring setup	https://cotocus.com/
DevOpsSchool.com	Training + consulting (verify OCI offerings)	Enablement, DevOps pipelines, operational readiness	Migration factory process; CI/CD for post-migration deployments; SRE practices	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify OCI offerings)	DevOps transformations, automation, platform engineering	Infrastructure as Code; standard logging/monitoring; governance automation	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Oracle Cloud Migrations

OCI fundamentals:
Regions, compartments, IAM
VCN basics: subnets, routing, security lists/NSGs, NAT/IGW
Compute fundamentals:
Shapes, boot volumes, block volumes, VNICs
Linux/Windows administration (boot troubleshooting, networking)
Migration fundamentals:
RPO/RTO concepts
Cutover planning and rollback strategies
DNS and load balancer basics

What to learn after Oracle Cloud Migrations

OCI observability:
Monitoring, Logging, Alarms, Notifications
OCI security services:
Vault/KMS, Cloud Guard (if used in your org), security zones (where applicable)
High availability and DR:
Multi-AD and multi-region designs (depending on region)
Backup policies, restore testing
Modernization:
Containers (OKE), Terraform/IaC, CI/CD pipelines

Job roles that use it

Cloud Engineer / Cloud Operations Engineer
Solutions Architect / Cloud Architect
DevOps Engineer / Platform Engineer
SRE / Reliability Engineer
Security Engineer (migration governance and controls)
Infrastructure/Virtualization Engineer (VMware → OCI transitions)

Certification path (if available)

Oracle’s certification landscape changes. Start with OCI foundational learning and then specialize. Verify current Oracle certification paths here: – https://education.oracle.com/

Project ideas for practice

Build a migration landing zone with compartments + tag strategy.
Create a “migration wave” runbook and apply it to 3 test VMs.
Implement a post-migration baseline:
monitoring + alarms
backup policy
CIS-style OS hardening steps (as appropriate)
Simulate cutover:
test instance in isolated subnet
production launch in private subnet behind load balancer
DNS switch + rollback exercise

22. Glossary

OCI (Oracle Cloud Infrastructure): Oracle Cloud platform providing compute, networking, storage, and managed services.
Compartment: OCI logical isolation boundary for resources and IAM policy scope.
VCN (Virtual Cloud Network): OCI virtual network containing subnets and routing.
Subnet: Network segment within a VCN (public or private).
NSG (Network Security Group): Security rules applied to VNICs for micro-segmentation.
Security List: Subnet-level virtual firewall rules (older model; still used).
Boot Volume: The disk that contains the OS for an OCI instance.
Block Volume: Persistent storage volume attached to an OCI instance.
Work Request: OCI mechanism for tracking asynchronous operations and their status.
Lift-and-shift: Migrating a workload with minimal changes to architecture/application code.
Cutover: The final switch from source workload to target workload in production.
Rollback: Reverting to the source environment if the cutover fails.
FastConnect: Dedicated private connectivity to OCI (carrier/partner dependent).
IPSec VPN: Encrypted site-to-site tunnel over the internet.
Landing zone: Pre-built cloud environment with standard networking, IAM, security, and governance.

23. Summary

Oracle Cloud Migrations (Cloud Migrations in the OCI console) is an Oracle Cloud Compute migration service used to move VM/server workloads into OCI Compute through a structured workflow: organize migrations into projects, connect to sources, replicate data, launch instances, validate, and cut over.

It matters because migration success depends on repeatability, visibility, and governance—not just copying disks. Oracle Cloud Migrations helps teams reduce risk with tracked operations (work requests), OCI-native IAM controls, and a process that supports testing before final cutover.

Cost-wise, focus on the real drivers: Compute runtime, Block Volume storage (including staging and leftovers), and networking. Security-wise, prioritize least-privilege IAM, private networking, Vault-backed secrets, and strong audit practices.

Use Oracle Cloud Migrations when you need a practical lift-and-shift path into OCI Compute and you can meet the connectivity and source platform requirements. Next step: read the official documentation end-to-end and run a small POC migration in a dedicated compartment with strict tagging and cleanup discipline: https://docs.oracle.com/en-us/iaas/Content/cloud-migrations/home.htm

rajeshkumar

Category