Migrate a VM

6 min read

This guide walks the canonical Carbon workflow for migrating an Azure VM to on-premises VMware or Hyper-V. The same flow applies to a single VM or a batch of many. Carbon structures the work in four phases: discovery and assessment, replication and conversion, configuration, and monitoring.

Before starting, complete Install Carbon and the Setup Wizard.

Critical prerequisite: stop the source VM in Azure

Carbon only migrates VMs that are in the Stopped (deallocated) state in Azure. Running VMs cannot be replicated. Before kicking off a migration:

In the Azure portal, stop the VM you plan to migrate. The status changes to "Stopped (deallocated)" after a few minutes.
Confirm the VM is fully deallocated (not just "Stopped") — the deallocation releases the Azure compute resources and is what Carbon needs.
Plan a maintenance window if the VM is in production. The downtime spans: stop in Azure → Carbon migration → validate on-premises → cut over (or rollback if needed).

If you try to migrate a running VM, Carbon either skips it with an error or prompts you to stop it first.

Phase 1: Discovery and assessment

Launch Carbon. The main view lists every VM in your connected Azure subscriptions with the full metadata you need to plan a migration:

VM name and status (look for VMs marked Stopped / Deallocated as your candidates)
Size (CPU count, memory)
IP address
VNET
Operating system
Resource group
Subscription
Location
Attached disks

Filter the list by subscription, resource group, location, status, or name pattern. Use this phase to confirm scope — which VMs you actually want to move, where they live in Azure, what the configuration looks like.

For first-time use, start with a single small Windows or Linux VM that you can lose without consequence. Use this run to validate your network and target setup before committing to production workloads.

Phase 2: Select and configure the migration job

Tick the checkbox next to each VM you want to migrate. Multi-select supports any combination — different subscriptions, different sizes, different OSes — within one job. Confirm every selected VM is in Stopped (deallocated) state.

Click Start Migration. The Migration Wizard opens:

Target hypervisor — pick from the targets you connected during the Setup Wizard: vCenter, ESXi, Hyper-V standalone, or SCVMM.
Datastore / storage location — pick the target datastore. Carbon shows free-space figures so you can confirm there is room.
Target network — pick the virtual network or port group the migrated VM connects to on first boot.
Resource pool / VM folder (VMware) or VM placement (Hyper-V) — pick where the migrated VM appears in the target inventory.
Compute sizing — defaults to mirroring the Azure VM's CPU and memory. Override if you want to right-size during the migration.
Notification preferences — per-job choice of which events trigger emails. See Notifications.

Click Next, review the summary, click Start.

Phase 3: Replication and conversion

Carbon pulls the VM disks from Azure to the Carbon machine, converts disk format as required (VHD ↔ VMDK depending on source / target), then writes them to the target datastore. This is the slowest phase — disk transfer time is bounded by the bandwidth between Azure and the Carbon machine plus the Carbon machine and the on-premises target:

Small VMs (under 100 GB total disks) — tens of minutes on a healthy network.
Medium VMs (a few hundred GB) — a few hours.
Large VMs (TB-scale) — many hours, possibly overnight.

ExpressRoute or a properly-sized site-to-site VPN make the biggest difference for the Azure-side pull. Local network between Carbon and target also matters for the second leg.

Per-VM progress is visible in the Migration Jobs tab. You can leave the Carbon console open or close it — the migration continues in the background. Email notifications cover the milestones if configured.

Phase 4: Configuration and verification

Once disk transfer completes, Carbon:

Creates the VM in the target hypervisor with the same CPU, memory, and disk configuration as the Azure source.
Attaches the migrated disks.
Connects the VM to the target network you selected.
Runs basic verification checks against the new VM.

When verification passes, the job state flips to Complete and Carbon sends the configured completion notification.

Job states (full progression)

Each VM in a job passes through these states:

Queued — waiting for a worker slot.
Reading source — Carbon pulls VM configuration and metadata from Azure.
Transferring disks — the slowest phase; disk content is copied from Azure to the Carbon machine. Progress percentage updates.
Converting — disk format conversion if needed.
Configuring target — VM is created in the target hypervisor with matching CPU, memory, disks, and network.
Verifying — Carbon runs basic checks against the new VM.
Complete — the migrated VM is in your target inventory and bootable.

Phase 5: First boot of the migrated VM

After Carbon marks the job Complete:

Open the target hypervisor console (vCenter or ESXi for VMware, Hyper-V Manager / SCVMM for Hyper-V).
Find the migrated VM.
Verify the configuration (CPU, memory, disks, network).
Boot the VM.
Confirm the OS comes up and the network is reachable.

See Post-migration checks for the recommended validation steps before considering a migration "done".

Batch migration considerations

When migrating many VMs in one job:

All VMs in the batch must be Stopped (deallocated) in Azure — Carbon enforces this per-VM.
The job runs migrations in parallel up to a worker concurrency limit. Multiple VMs can be in different phases at the same time.
A single VM failing does not cancel the rest of the job — failures are reported per-VM, the job continues with the remaining VMs.
Total job time is bounded by the largest VM in the batch and available bandwidth.

For very large batches (tens or hundreds of VMs), consider running multiple smaller jobs back to back rather than one giant job. Smaller jobs are easier to monitor and recover from if anything fails partway through.

Cancelling an in-flight job

Right-click the job → Cancel. Per-VM behaviour:

Migrations not yet started simply skip.
Migrations in disk-transfer or later phases stop and the partially-transferred target VM is removed.

The original source VM in Azure is never modified or deleted by Carbon. After migration completes and you are satisfied the new on-premises VM is working, deleting the Azure VM is a manual step you perform separately.