Domain 3: Design and Implement Migrations Using Oracle Cloud Migrations Service (25%)

Domain 3 of the 1Z0-1123-25 Oracle Cloud Infrastructure 2025 Migration Architect Professional exam covers the Oracle Cloud Migrations (OCM) service end to end. At 25% of the exam, this is the single heaviest domain, representing approximately 13 questions out of 50. You must know OCM architecture, the full migration lifecycle, both VMware and AWS source paths, replication internals, and IAM policy requirements.

Unlike OCVS migration (Domain 4), which moves VMware workloads into a VMware-managed environment on OCI, OCM migrates workloads to native OCI Compute instances. This distinction is a common exam trap. OCM converts VMs into OCI-native resources; OCVS preserves the VMware stack.

1. OCM Service Architecture and Components

Oracle Cloud Migrations provides an end-to-end self-service experience for migrating VMware virtual machines (on-premises or hosted) and AWS EC2 instances (EBS-backed only) to OCI native Compute instances. The service itself has no cost; you pay only for temporary OCI resources created during migration (compute, storage, networking) at standard OCI rates. (OCM Overview)

Core Components

Three-Phase Workflow

OCM follows a structured three-phase approach: (OCM Overview)

1. Manage Assets -- Connect to source, discover VMs, build inventory
2. Plan and Migrate -- Create projects, build plans, replicate data, configure targets
3. Verify Migration -- Generate Resource Manager stacks, deploy instances, validate, complete project

Exam trap: The OCM service does not perform post-migration application validation. It deploys the OCI instances and performs basic configuration remediation (serial console, virtio drivers, fstab updates). Application-level validation is handled outside OCM.

2. Source Environments: VMware vs. AWS

OCM supports two source environment types with fundamentally different connectivity models. Know the differences cold:

Source: OCM Overview, AWS Source Environments

Supported Source Versions

Source: OCM Specifications

Exam trap: OCM only supports EBS-backed EC2 instances. Instance store-backed EC2 instances are not supported. If a question mentions instance store volumes, OCM cannot migrate them.

Supported Guest Operating Systems

Linux distributions supported from VMware: Oracle Linux 7/8/9, RHEL 7/8/9, CentOS 7/8/9, Ubuntu 14.04 through 24.04 LTS, Debian 8-12, SUSE SLES 12/15, Amazon Linux 2/2022/2023, Rocky Linux, Clear Linux. From AWS: Oracle Linux 7/8/9, RHEL 7/8/9, CentOS 7/8/9, Ubuntu 14.04 through 24.04 LTS, Debian 9-12, SUSE SLES 12/15. (OCM Specifications)

Windows Server editions supported: 2012/2012 R2, 2016, 2019, 2022 (Standard and Datacenter) from both VMware and AWS.

Exam trap: Amazon Linux variants (AL2, AL2022, AL2023) are only supported from VMware, not from AWS. This is counterintuitive. Also, Amazon Linux 2 instances migrated from VMware require virtio drivers added to initramfs manually before replication:

sudo dracut -v -f --add-drivers "virtio virtio_pci virtio_scsi virtio_ring" /boot/initramfs-$(uname -r).img $(uname -r)

Windows Licensing on OCI

Windows Server BYOL is not permitted on shared OCI compute hosts. All Windows instances on shared compute must register with the Oracle-provided KMS server. This is a licensing constraint, not a technical one. (OCM Specifications)

3. Remote Agent Appliance (RVA) -- VMware Only

The RVA is a sealed OVA/OVF virtual appliance deployed into your VMware environment. It is the cornerstone of VMware migration -- without it, you cannot discover or replicate. (RVA Documentation)

RVA Plugins

Network Connectivity Requirements

Exam trap: The RVA does not support non-default vCenter ports. If vCenter is running on a custom port, it will not work with OCM.

Network Interface Modes

• Single interface: One IP for both internal (vCenter/ESXi) and external (OCI) traffic
• Dual interface: Separate interfaces for internal and external connectivity (more secure, recommended for production)

vSphere Privilege Requirements

Discovery and replication require different privilege levels:

Discovery: Read-only vCenter role (built-in) is sufficient.

Replication: Requires a custom vCenter Server role with these specific privileges:

• Global: Disable methods, Enable methods, Licenses
• Virtual Machine > Change Configuration: Acquire disk lease
• Virtual Machine > Provisioning: Allow read-only disk access, Allow virtual machine download
• Virtual Machine > Snapshot Management: Create snapshot, Remove snapshot

Source: RVA Documentation

Agent Dependency: VDDK

The VMware Virtual Disk Development Kit (VDDK) is a third-party library required by the Replication Plugin. It is not bundled with the RVA due to licensing restrictions. You must obtain VDDK separately from VMware and upload it as an agent dependency. Without VDDK, replication will fail. (OCM Getting Started)

RVA Key Behaviors

• Each RVA registers to one source environment only
• Multi-region migrations require a separate source environment and at least one RVA per target region
• Multiple RVAs can be deployed for a single source environment for redundancy and increased throughput
• RVA maintains a persistent secure connection to OCI via token exchange; if the token refresh fails, the agent disconnects and requires manual re-registration
• RVA includes a TUI (text-based user interface) diagnostics tool for network troubleshooting

4. AWS Source Environment Setup

AWS migration uses an agent-less approach. No appliance is deployed into AWS. The OCM discovery service connects directly to AWS using IAM credentials. (AWS Source Environments)

Required AWS IAM Permissions

Discovery permissions:

Replication permissions:

AWS credentials are stored as JSON in OCI Vault: {"accessKeyId": "<KEY>", "secretAccessKey": "<SECRET>"}.

Exam trap: Cost Explorer and CloudWatch permissions are optional for AWS discovery. Without them, OCM can still discover and replicate, but it cannot generate sizing recommendations based on utilization metrics or AWS spending comparisons.

Encrypted EBS Volumes

If source EBS volumes are encrypted with AWS KMS, the replication IAM user must have Decrypt permission on the KMS key. Only the Decrypt operation is needed -- no other KMS operations. Without this, EBS read errors will cause replication job failure. (VM Replication)

5. Inventory Management

The inventory is a database of discovered assets stored in your OCI tenancy. Each inventory asset represents a resource found in the source environment, including compute, storage, and networking metadata. (OCM Overview)

Asset Types (Know These Precisely)

Populating the Inventory

Three methods:

1. Discovery work request -- Run on-demand or on a schedule against an asset source
2. CSV import -- Import inventory assets from a CSV file (useful for bulk population or when discovery is not available)
3. API -- Programmatically create inventory assets via the Cloud Bridge REST API

Discovery Schedules

A discovery schedule defines the frequency of automatic discovery work requests. Each run refreshes the asset source against the source environment: new assets are added, and existing asset metadata is updated. Discovery can also be triggered on-demand at any time. (OCM Overview)

Metrics Collection

When creating an asset source, you can enable:

• Historical metrics collection: Gathers past performance data for sizing recommendations
• Real-time metrics collection: Gathers current performance data

Performance data is stored in OCI Monitoring service and is searchable by asset attributes and OCI tags.

6. Migration Projects and Assets

Migration Projects

A migration project is a logical container that groups migration assets and migration plans. Best practice: keep assets that will be migrated during the same cutover event together in one project. (OCM Overview)

Key behaviors:

• All assets in a project are included by default; individual assets can be excluded from specific plans
• A migration asset can belong to only one project at a time
• Marking a project as complete freezes it: no changes to plans or assets are allowed, and replication stops
• A completed project can be marked incomplete to resume work if needed

Migration Assets

Migration assets are point-in-time references to inventory assets. When you add an inventory asset to a project, it becomes a migration asset with:

• A reference to the source inventory asset
• A replication location (availability domain in a specific OCI region)
• Replication can be manual (on-demand) or scheduled

Exam trap: Data is replicated to a specific availability domain. You choose this when adding the migration asset. Each migration plan uses a clone of the replicated data, so multiple plans can use the same replicated data simultaneously without affecting synchronization.

7. Migration Plans and the Recommendation Engine

Creating a Migration Plan

A migration plan maps source assets to target OCI configurations. When you create a plan, the recommendation engine generates an initial target configuration based on discovered attributes and collected performance statistics. (Creating a Migration Plan)

Recommendation Engine Strategies

The recommendation engine uses configurable strategies to determine target sizing:

Strategies can be applied independently to CPU and memory, or as a default for both.

Adjustment Multiplier

Each strategy supports an optional adjustment multiplier. For example, a multiplier of 1.2 on an Average CPU strategy means the target is sized 20% above the average utilization. This accounts for headroom. (Creating a Migration Plan)

Target Environment Configuration

Each plan specifies:

• Target compartment: Where migrated resources will be created
• VM shape: System-recommended or manually selected (supported shapes below)
• VCN and subnet: Network configuration for the target instance
• Capacity type: On-demand, preemptible, capacity reservation, or dedicated host
• Block volume performance: Configurable per volume

Supported Target OCI Compute Shapes

Source: OCM Specifications

Monthly Cost Estimation

Every migration plan automatically generates a monthly cost estimate for the target configuration. For AWS migrations, the plan can compare AWS spending against the recommended OCI shape cost. You can clone plans with different shapes/sizes and compare costs. (Managing Migration Plans)

Multiple Plans Per Project

A single project can contain multiple migration plans. Recommended approach:

• Test plan: Uses smaller shapes, deployed to isolated networks
• Production plan: Uses production-grade shapes, deployed to production VCN/subnet
• Each plan uses a clone of the replicated data, so they do not interfere with each other

Plans can also be exported/imported via CSV for bulk modifications. (Managing Migration Plans)

8. Replication Architecture

Replication is the process of transferring source VM disk data to OCI Block Volumes. The architecture differs between VMware and AWS. (VM Replication)

VMware Replication Flow

VMware VM --> RVA Replication Plugin --> Snapshot -->
OCI Object Storage (Replication Bucket) -->
Hydration Agent --> OCI Block Volume (Golden Volume)

1. Replication Plugin takes a snapshot of the source VM's virtual disks
2. Snapshot data is transferred via HTTPS to a private OCI Object Storage bucket (replication bucket)
3. Hydration Agent reads snapshot data from Object Storage
4. Hydration Agent writes data block-by-block into OCI Block Volumes
5. Snapshot data is removed from Object Storage after successful write

Incremental replication: Requires Changed Block Tracking (CBT) enabled at the VM level. With CBT, only changed blocks are transferred after the initial full replication. Without CBT, every replication is a full copy.

AWS Replication Flow

EC2 Instance --> EBS Snapshot -->
Hydration Agent (EBS Direct API) --> OCI Block Volume (Golden Volume)

1. OCM creates an EBS snapshot of the source volumes
2. Hydration Agent uses the AWS EBS Direct API to read snapshot blocks
3. Hydration Agent writes data directly into OCI Block Volumes
4. Incremental replication is automatic -- only changed blocks between snapshots are transferred

Exam trap: AWS replication does not use OCI Object Storage as a staging area. The Hydration Agent reads directly from AWS EBS via the EBS Direct API. VMware replication does use Object Storage as an intermediate staging bucket.

Golden Volumes

A "golden volume" is an OCI Block Volume created for each boot and data volume attached to the source VM. The golden volume is kept in sync with source snapshots throughout the migration lifecycle. Each time a migration plan is executed, a clone of the golden volume is used for the OCI instance launch. The golden volume exists for the entire lifespan of the migration asset. (OCM Overview)

Replication Bucket (VMware Only)

The replication bucket is a private OCI Object Storage bucket in the migration compartment. It temporarily holds VMware snapshot data during transfer. Data is removed from the bucket after being written to Block Volumes. Bucket naming supports letters, numbers, hyphens, underscores, and periods. (VM Replication)

9. Hydration Agents

Hydration agents are temporary OCI Compute instances launched automatically in your tenancy during replication. They are the bridge between source data and OCI Block Volumes. (OCM Overview, VM Replication)

Key Behaviors

• Auto-scaling: Instances launch automatically based on object pool load-balancing logic
• Auto-termination: Agents terminate after idle with no pending replication jobs
• Shape selection: Prefers minimum CPU count and minimal cost; default recommendation is VM.Standard.E4.Flex
• Pooling: Agents are pooled by replication location (availability domain)
• Networking: Each agent pool creates 1 VCN, 1 subnet, and associated route tables (temporary)
• Image: Uses approved OCI images (e.g., Oracle-Linux-7.9), updated with new deployments

Resource Reservations

Exam trap: Do not modify temporary resources created by OCM (hydration agent VCNs, subnets, compute instances). Modifying them can cause pending replication operations to fail.

10. Temporary Tenancy Resources

OCM creates several temporary resources in your tenancy during migration. You pay standard OCI rates for these. (OCM Overview)

11. Boot Volume Remediation

OCM performs automatic boot volume modifications during migration to ensure the target instance is bootable and accessible on OCI. (VM Replication)

Linux Automatic Modifications

Linux Manual Steps Required Post-Migration

• Remove MAC address-based udev rules
• Enable SSH and configure SSHD to auto-start
• Configure DHCP-based networking (no hard-coded MACs, static IPs, or DNS)
• Install Oracle Cloud Agent and OS Management Agent
• Remove competing cloud management agents (VMware Tools, AWS SSM Agent)
• Update NTP configuration to OCI NTP service

Windows Requirements

• Virtio drivers must be installed before launching the migrated instance -- without them, the OS cannot find the boot device
• Remove VMware Tools before migration
• Configure SAN Policy as "Online All"
• Enable RDP and configure firewall inbound rules
• Configure DHCP-based networking

Exam trap: For Windows, virtio driver installation is a pre-migration requirement, not an automatic remediation. If you skip this step, the migrated Windows instance will not boot.

12. Deployment via Resource Manager

Migration plans are executed through OCI Resource Manager (ORM). (Managing Migration Plans)

Workflow

1. Generate RMS Stack: From the migration plan, generate a Resource Manager Stack containing Terraform configuration with references to cloned golden volume data and target asset attributes
2. Deploy Stack: Apply the stack to create OCI Compute instances
3. Validate: Verify instances are running and accessible (application validation is outside OCM)
4. Iterate or Clean Up: If unsuccessful, delete the stack (prevents orphaned resources), update replication, and run the plan again

Testing with Resource Manager

Resource Manager stacks are deletable, which makes testing safe:

• Deploy a test plan, validate, then delete the stack to clean up all created resources
• Deploy again with a production plan once validated
• No orphaned resources if you use stack deletion

13. Test vs. Production Migration

OCM does not technically distinguish between test and production migrations. The difference is entirely in your planning and execution. (Migration Basics)

Test Migration Checklist

• Test migration can begin after one complete replication cycle per asset
• Deploy to isolated networks to avoid conflicts with production
• Verify entire multi-VM applications, not just individual components
• Validate network connectivity, firewall rules, DNS changes, and client configurations
• Document all Terraform/stack changes needed
• Maintain documented rollback steps

Production Migration Checklist

• Plan a maintenance window that accounts for final replication time
• Shut down source assets before the final replication to ensure data consistency
• Tag source assets for reliable identification and shutdown
• Perform one additional replication after shutdown to capture the most recent state
• Factor final replication duration into the maintenance window
• Prepare decision trees for both success and failure scenarios
• After successful validation, mark the project as complete to stop replication

Snapshot Consistency Warning

VM snapshots are not taken simultaneously across different VMs. For distributed applications requiring data synchronization across multiple VMs, standard snapshot-based replication can cause inconsistencies. The alternative is to shut down source VMs before replication (requires downtime). (Migration Basics)

Exam trap: OCM does not support reverse replication. If you need to fail back to the source environment, you must use manual data transfer methods.

14. Post-Migration Cleanup

After successful production migration: (Migration Basics)

1. Mark the migration project as complete (stops replication, freezes project)
2. Shut down all migrated VMs in the source environment
3. Clean all snapshots from VMware vCenter
4. Remove migrated VMs from vCenter
5. Decommission unnecessary network routes

Exam trap: Failing to clean up the source environment can cause clients to remain connected to outdated source resources and perform operations on stale data.

15. IAM Policies and Dynamic Groups

OCM requires extensive IAM configuration. Six dynamic groups cover different service components. (OCM Service Policies)

Required Dynamic Groups

Key Policy Patterns

MigrationDynamicGroup needs manage on: instance-family, compute-image-capability-schema, virtual-network-family, volume-family, object-family in the migration compartment. At tenancy level, it needs read on: ocb-inventory, rate-cards, metrics, tag-namespaces, and inspect on instance shapes, dedicated VM hosts, capacity reservations, and subscriptions.

RemoteAgentDynamicGroup needs cross-tenancy endorsement to write objects to the OCB service tenancy:

Define tenancy OCB-SERVICE as <ocb_service_tenancy_ocid>
Endorse dynamic-group RemoteAgentDynamicGroup to { OBJECT_CREATE } in tenancy OCB-SERVICE

HydrationAgentDynamicGroup needs cross-tenancy endorsement to write objects to the OCM service tenancy:

Define tenancy OCM-SERVICE as <ocm_service_tenancy_ocid>
Endorse dynamic-group HydrationAgentDynamicGroup to { OBJECT_CREATE } in tenancy OCM-SERVICE

Exam trap: The Remote Agent and Hydration Agent dynamic groups require cross-tenancy policies. These endorse the dynamic groups to write objects into Oracle's service tenancies. The OCIDs differ between the two (OCB-SERVICE vs OCM-SERVICE) and vary by realm.

Policy Verbs

16. Compartment Architecture Best Practice

Oracle recommends a three-compartment approach: (OCM Getting Started)

Required Tag Namespace

Create a CloudMigrations tag namespace with these keys:

• SourceEnvironmentType
• SourceEnvironmentId
• SourceAssetId
• MigrationProject
• ServiceUse

These tags enable resource tracking and cost analysis filtering.

17. Prerequisites Deployment

OCM provides an automated prerequisites deployment via a Resource Manager Stack accessible from the Oracle Cloud Migrations Overview page. This stack creates the required compartments, dynamic groups, IAM policies, Vault, and tags. This is the recommended approach for initial setup. (OCM Getting Started)

18. Service Limits and Quotas

OCM resources are subject to OCI service limits. View and manage limits at: Console > Governance & Administration > Governance > Limits, Quotas, and Usage. Filter by service: Oracle Cloud Bridge and Oracle Cloud Migrations. (OCM Overview)

Key limit considerations:

• Hydration agents consume compute, VCN, and subnet limits
• Block volumes (golden volumes) persist for the entire migration asset lifespan
• Only administrators can request service limit increases
• Limits can auto-increase based on resource usage and account standing

19. Access Methods

20. Exam-Critical Distinctions

Quick Reference: End-to-End Migration Steps

VMware Migration

1. Create compartments (Migration, Migration_secrets, Destination)
2. Configure IAM policies and dynamic groups
3. Create Vault and store vCenter credentials
4. Create private Object Storage replication bucket
5. Create source environment
6. Deploy and register RVA in VMware environment
7. Upload VDDK as agent dependency
8. Create asset source with discovery/replication credentials
9. Run discovery (on-demand or scheduled)
10. Review inventory assets
11. Create migration project
12. Add migration assets to project
13. Create migration plan with strategy configuration
14. Review recommendations and cost estimates
15. Configure target assets (shape, VCN, subnet)
16. Start replication (manual or scheduled)
17. Generate Resource Manager stack
18. Deploy stack (test migration)
19. Validate migrated instances
20. Delete test stack, update replication, deploy production stack
21. Mark project complete
22. Clean up source environment

AWS Migration

1. Create compartments and IAM policies/dynamic groups
2. Create Vault and store AWS access keys
3. Create AWS asset source
4. Run discovery
5. Review inventory assets
6. Create migration project and add assets
7. Create migration plan
8. Start replication
9. Generate and deploy Resource Manager stack
10. Validate and complete

References

• Overview of Oracle Cloud Migrations
• Getting Started with Oracle Cloud Migrations
• Specifications for Using Oracle Cloud Migrations
• Remote Agent Appliance Configuration
• Understanding VM Replication
• Oracle Cloud Migrations Service Policies
• AWS Source Environments
• Creating a Migration Plan
• Managing Migration Plans
• Basics of Oracle Cloud Migrations
• Creating a VMware Asset Source
• Configuring Target Assets