An ESXi migration can look straightforward when the plan contains only a list of virtual machines and a destination host. The difficult decisions usually concern the surrounding system: storage access, network mappings, licensing, backup compatibility, application dependencies, and the point after which returning to the old environment becomes complicated.
A reliable migration plan makes those decisions before the maintenance window. It defines how each workload will move, how the team will prove that it works, and what evidence will trigger a rollback. It also explains what happens to data written after the move.
Teams evaluating VMware ESXi dedicated infrastructure should confirm the exact host configuration, supported software versions, and commercial responsibilities in writing. A server described as suitable for virtualization is not sufficient evidence that a particular migration method, license entitlement, or application support requirement is covered.
Create a migration inventory that includes guest operating systems, virtual hardware versions, virtual disks, network connections, backup policies, and application owners. Record services outside the platform that each workload requires, such as DNS, identity, mail delivery, storage, and external APIs.
Identify dependencies between virtual machines. A web server, database, and message broker may need a coordinated move even when they belong to different teams. Moving one without the others can increase latency or expose firewall rules that were never designed for communication between sites.
Check for hardware attached or host dependent features. Passthrough devices, special drivers, local storage assumptions, and license binding can restrict migration options. These details are easy to miss if the inventory contains only allocated CPU and memory.
Assign an application owner to every acceptance decision. An infrastructure engineer can confirm that a guest powers on, but the person responsible for the service must verify that users can complete the important business actions.
Review the supported combination of server hardware, firmware, ESXi version, storage adapters, and network adapters. Use the vendor compatibility information for the exact components. A similar model number or a working laboratory installation does not establish supported production compatibility.
The migration method may impose additional requirements. Live migration, cold migration, backup restoration, and application level replication have different prerequisites and interruption patterns. Select the method per workload rather than assuming that one approach fits the entire estate.
CPU compatibility also needs attention. Broadcom’s explanation of Enhanced vMotion Compatibility describes how EVC manages exposed CPU features for migration compatibility. It is not a universal solution for every hardware transition; validate the proposed source and destination combination and the applicable product requirements.
Confirm licensing and support separately from technical feasibility. Record who supplies the license, which features are entitled, and who handles a support case. Product packaging and entitlement rules can change, so the migration plan should refer to the agreed current contract rather than an old assumption.
A rollback plan needs a deadline, an owner, and a known source of truth for data. Returning traffic to an old virtual machine is simple only while that machine still contains the correct state. Once users write data to the new environment, the plan must account for those changes.
For a stateful application, define how writes will be paused, replicated, reconciled, or restored. The correct method depends on the application and database. Do not improvise a data merge during an outage or assume that two independently updated copies can be combined safely.
|
Decision |
What the plan must specify |
|
Go ahead authority |
Person authorized to begin the cutover |
|
Acceptance window |
Time available for technical and business checks |
|
Rollback trigger |
Specific failures or missed thresholds |
|
Data authority |
Which environment holds the accepted current data |
|
Return procedure |
Steps for traffic, data, and dependency reversal |
|
Final approval |
Owner who confirms the service is ready to remain live |
Use objective triggers where possible. A failed payment test, missing data, or an unresolved storage error is clearer than a general statement that the environment seems unstable. Define who can extend the validation window and under what conditions.
A snapshot can help with certain short lived changes, but it should not be the migration’s only recovery mechanism. Broadcom’s snapshot best practices explicitly distinguish snapshots from backups. Plan an independent, tested recovery path appropriate to the workload.
Verify backup recency, retention, restore permissions, and the destination where a restore would occur. Confirm that encryption keys and credentials remain available if the primary environment is inaccessible. A backup catalog that only one unavailable administrator can access is an incomplete recovery plan.
Run a restoration exercise before the migration, using a representative workload. Measure the time needed to restore disks, start the guest, and validate the application. This provides a realistic fallback estimate and may reveal missing drivers, network settings, or application dependencies.
Choose a pilot that exercises the important migration steps without placing the most critical service at risk. A trivial virtual machine that has no meaningful storage or network requirements may not expose the problems that will affect production.
During the rehearsal, record each manual action and the time it takes. Replace ambiguous notes such as update networking with the exact mapping and verification step. Keep secrets outside the runbook, but state where authorized operators retrieve them.
Test the rollback as part of the rehearsal. Confirm that routing can be reversed, the source workload remains usable, and the team understands the data state. A migration rehearsal that never exercises failure leaves its most consequential procedure untested.
Use the result to update the estimated maintenance window. Include decision time and communication, not just transfer time. Teams need enough room to interpret a failed check and carry out the agreed response without racing the end of the window.
Check virtual networks, VLANs where applicable, firewall rules, addresses, DNS, and external access. An internal ping proves very little about whether a customer can use the application. Test from the same locations and interfaces that real users depend on.
Account for cached DNS records and existing connections when changing traffic. Lowering a TTL in advance may help some transitions, but it does not guarantee that every client changes destinations immediately. The plan should tolerate a period of mixed routing where the application design permits it.
Confirm monitoring and backup connectivity on the destination before the cutover. A workload can appear healthy while silently losing alerting or protection. These integrations belong in the migration acceptance checklist, not in a follow up task after the old host is removed.
Use a single timeline that records checkpoints, decisions, and the person responsible for each action. Keep the communication channel clear and designate someone to coordinate rather than requiring every engineer to interpret every message independently.
At minimum, the acceptance checks should cover:
- Guest startup and expected storage visibility.
- Authentication and representative business transactions.
- Data consistency checks appropriate to the application.
- Network access from relevant user locations.
- Monitoring, backups, and scheduled background jobs.
- Resource behavior under the initial production workload.
If a check fails, follow the decision rule written before the migration. Avoid extending the window indefinitely because most of the work is already complete. The rollback deadline exists to preserve enough time for a controlled return.
Review scheduled work after the first full operating cycle. Overnight exports, month end routines, and backup jobs may not run during the initial acceptance window. Assign owners to observe them at their next execution and provide a clear route for reporting problems. This is particularly important when network addresses or service accounts changed during the move. Keep these delayed checks in the migration record with due dates so the project does not lose track of them once the visible customer facing application has been declared available.
Keep the source environment for the agreed retention period, with controls that prevent accidental duplicate processing or unauthorized use. Record when it may be removed and who approves that removal. Continued availability should not mean leaving an unmanaged production copy running indefinitely.
Complete the inventory, update support contacts, and verify the next scheduled backup. Review the migration record for steps that differed from the plan. Those differences are useful evidence for the next workload, even when the move succeeded.
A successful ESXi migration ends with a service that is usable, monitored, recoverable, and clearly owned. Planning the rollback path early helps make that result possible because it forces the team to resolve data and dependency questions before the maintenance window begins.
