Post-Migration Checks

Carbon completes a migration when the new VM is in your target hypervisor and bootable. The job is not finished there — you need to validate the migrated VM works in your on-premises environment before retiring the Azure source. This guide walks the validation checklist.

Step 1: Boot the migrated VM

In your target hypervisor console (vCenter for VMware, Hyper-V Manager or SCVMM for Hyper-V):

1. Find the migrated VM.
2. Verify CPU, memory, and disk configuration match expectations.
3. Power on the VM.
4. Watch the console output to confirm the OS boots normally.

Step 2: Network connectivity

Once booted:

• Confirm the VM has an IP address on the target network.
• Ping the VM from another host in the same network.
• Check DNS resolution works (the on-premises DNS server may differ from the Azure-provided DNS).
• Confirm any required outbound connectivity works (does the VM need to reach external services that may have firewall rules referring to its old IP?).

Step 3: Identity and domain join

If the VM was domain-joined in Azure:

• Confirm the domain trust is intact.
• The VM may need to be re-added to the domain if the trust relationship broke during the move.
• Update any DNS records that pointed to the old Azure IP.

Step 4: Application functionality

Test that whatever the VM is for actually works:

• For application servers: try the application end-to-end with a known-good client.
• For database servers: connect with a database tool, run a representative query.
• For web servers: hit the URL and confirm the expected response.
• For internal services: confirm dependent systems can reach this VM as expected.

Step 5: Performance

Compare against the Azure baseline:

• CPU utilisation under expected load.
• Disk I/O latency (on-premises storage often differs from Azure disk performance).
• Network throughput to and from key dependencies.

If performance is meaningfully worse, the issue is often storage configuration (target datastore type or RAID level) or network sizing (VM connected to an under-provisioned vSwitch).

Step 6: Backup integration

Add the new VM to your on-premises backup tool. Confirm a backup runs successfully before considering the migration complete.

Step 7: Source decommissioning

Once you are satisfied the migrated VM is working and protected by backup:

1. Stop the original Azure VM (do not delete yet — keep as a rollback option for a configurable period, e.g. 30 days).
2. Update any documentation that referred to the Azure VM by name or IP.
3. After your rollback window, delete the Azure VM and its disks to stop the Azure storage charges.

Carbon does not touch the source Azure VM. The Azure resource lives until you delete it explicitly. This is intentional — leaving the source intact gives you a safety net while the migrated VM is in its first weeks of operation.

When something is wrong

If the migrated VM does not boot, the OS comes up but has problems, or application functionality is broken:

• Check the Carbon notifications for any per-VM warnings during migration.
• Verify the target hypervisor's host has driver compatibility for the OS — Azure VMs use Azure-specific drivers that may need replacing with VMware Tools or Hyper-V Integration Services in the target environment.
• For domain-join issues, leave and rejoin the domain.
• For specific issues, contact support@smikar.com with the migration job ID.

See also

• Migrate a VM — the migration that precedes this validation.
• Notifications — how progress and failure information arrives.

Need help? support@smikar.com.