Skip to content

Veeam Migration Path — Validation & Checklist ​

Validation steps for each migration hop and the complete pre-migration checklist.


Hop 1 Go / No-Go Sign-off ​

CAUTION

Do not proceed to Hop 2 until every VM in this batch passes every check below The Hyper-V staging host is your last rollback point before Azure Migrate consumes the VMs. Once Hop 2 replication starts and succeeds, rolling back to Nutanix requires restoring from backup.

After Veeam failover or restore, sign off on each VM individually before committing the batch to Hop 2:

CheckCommand / MethodExpected ResultSigned off
VM boots and stays runningHyper-V Manager — check VM stateRunning (not Paused or Off)☐
Network connectivity to gatewayping <gateway-ip> from inside VMSuccessful☐
Correct IP address assignedipconfig /all (Windows) / ip addr (Linux)Matches planned IP☐
DNS resolution (forward)nslookup <hostname>Resolves to correct IP☐
DNS resolution (reverse)nslookup <vm-ip>Resolves to correct hostname☐
AD domain membershipTest-ComputerSecureChannel (Windows)True☐
Can reach domain controllersnltest /sc_query:<domain>Success☐
All critical services runningGet-Service / systemctl statusExpected services active☐
Application smoke testBrowser / curl / DB query / ping app portExpected response☐
Can communicate back to source networkPing dependent servers / databases by hostnameSuccessful☐
Disk integrityCheck Event Viewer (Windows) or dmesg (Linux)No disk errors☐
Re-IP applied correctly (if applicable)ipconfig /all / DNS checkNew IP active, DNS updated☐

Batch Hop 1 Sign-off:

FieldValue
Batch
VMs in batch
Date / Time completed
All checks passed?☐ Yes — proceed to Hop 2 ☐ No — rollback
Sign-off by
Application owner confirmation

Hop 1 Validation — Hyper-V Staging (Detail) ​

After Veeam failover, validate each VM before committing:

CheckCommand / MethodExpected Result
VM bootsHyper-V Manager — check VM stateRunning
Network connectivityping <gateway> from inside VMSuccessful
DNS resolutionnslookup <hostname>Resolves to correct IP
AD domain membershipTest-ComputerSecureChannel (Windows)True
Services runningGet-Service / systemctl statusExpected services active
Application smoke testBrowser/curl to app URL or DB queryExpected response
Disk integrityCheck Event Viewer or dmesg for disk errorsNo errors

TIP

Document your baseline Before starting any migration, record the expected state for each VM (IP, service list, app test URL/query). This becomes your validation checklist post-migration.


Hop 2 Validation — Azure Local ​

After Azure Migrate cutover, repeat all Hop 1 checks plus:

CheckMethodExpected Result
Arc statusAzure portal → Azure Local → VMsConnected
Azure Monitor agentAzure portal → Monitor → AgentsReporting
Defender for CloudAzure portal → Defender for CloudVM appears, no critical alerts
Update ManagerAzure portal → Update ManagerVM inventoried
DNS (if re-IPed)nslookup <hostname> from multiple clientsResolves to new IP
SPN registrationsetspn -L <computer-account>SPNs intact for SQL/IIS services
Kerberos authenticationTest app login with domain accountSuccessful
Application sign-offApp owner performs full functional testPass

IP and DNS Verification ​

=== "Preserved IPs (same VLAN)"

- `ipconfig /all` (Windows) or `ip addr` (Linux) — verify IP matches expected
- `nslookup <hostname>` — verify forward DNS resolves to correct IP
- `nslookup <ip>` — verify reverse DNS (PTR) resolves to correct hostname
- From other servers: ping by hostname to verify DNS propagation

=== "Re-IPed (new subnet via Veeam re-IP rules)"

- Verify new IP assigned correctly after Veeam failover
- Update DNS A records: `Set-DnsServerResourceRecord` or via DNS Manager
- Update PTR records (reverse zone)
- Flush DNS caches on key servers: `ipconfig /flushdns` (Windows), `systemd-resolve --flush-caches` (Linux)
- Verify SPN registrations if SQL Server, IIS with Windows Auth, or other Kerberos services are present

Rollback Decision Points ​

StageRollback Action
After Veeam failover — validation failsUndo Failover in Veeam → source AHV VMs power back on
After Commit Failover — Azure Migrate test failsPower off Azure Local test VMs, restore source AHV VMs from Nutanix snapshots
After Azure Migrate cutover — issues foundOpen source AHV VMs (still powered off, not deleted) and power them back on

CAUTION

Never delete source VMs until holding period expires Maintain source Nutanix VMs in a powered-off state for a defined holding period (typically 2–4 weeks per batch) after Azure Local validation is complete. Only then decommission them permanently.


Pre-Migration Checklist ​

ItemStatusOwnerNotes
Veeam B&R v12+ installed☐InfraConfirm version
Veeam licensed (VUL count confirmed)☐InfraMinimum 10 VUL for rolling batches
Nutanix AHV/ESXi added to Veeam☐InfraAHV proxy deployed and healthy
Hyper-V staging host(s) added to Veeam☐InfraTransport service installed
Hyper-V storage sized and available☐Infra≥ used disk of largest batch
Azure Migrate project created☐CloudSubscription + RG selected
Azure Migrate appliance deployed☐CloudRegistered, discovery complete
Azure Local cluster healthy☐InfraArc-registered, CSV capacity available
Network ports verified open☐NetworkingAll ports in prerequisites table
VM inventory sorted into batches☐Migration LeadBatch spreadsheet complete
IP/VLAN mapping spreadsheet complete☐NetworkingSource → target for all VMs
DNS TTLs lowered (if re-IPing)☐NetworkingSet to 300 seconds, 48 hours before Batch 1
Application baseline documented per VM☐App OwnersIPs, services, smoke test procedure
Rollback procedure documented and tested☐AllUndo Failover confirmed working
Stakeholder maintenance windows approved☐PMPer-batch windows scheduled
Source VM holding period policy agreed☐AllMinimum 2 weeks recommended

Released under the MIT License.