VMware Migration Checklist

Start with the workloads you need to protect

A virtualization migration benefits from a dependency inventory, a representative pilot, an operating-cost comparison, and a recovery plan that works. Use this checklist to document your VMware environment and plan a migration or additional deployment, including a SynchresisVM evaluation.

Native desktop apps and single-server SynchresisVM Server are free forever, including the official 1.0 release. Closed-beta participants also receive an introductory free installation call and direct access to the developers. Installation calls are free throughout closed beta and for the first few months after 1.0. No purchase required. We can demonstrate clustering for free on the call and may agree a free trial for a small cluster for the beta period. The closed beta is available now; we’ll arrange your installation call with you.

Download the evaluation worksheet (.txt) — no form or registration required. Record requirements and evidence before scoring a candidate.

1. Agree the business requirements

Name the sponsor, technical lead, application owners, and person authorized to approve a cutover. Record the project schedule, evaluation window, and budget. Separate mandatory requirements from preferences so a low price cannot hide a missing operational dependency.

• Availability: define an acceptable maintenance window for each service.
• Recovery: set the maximum tolerable data loss (RPO) and time to restore service (RTO).
• Support: establish coverage, escalation, updates, and application-vendor requirements.
• Decision: write measurable acceptance criteria before anyone starts the pilot.

2. Inventory the dependencies, not just the VMs

Group machines by the service they deliver. A working application may depend on identity, DNS, databases, queues, certificates, and systems outside the cluster. Microsoft's migration guidance explains why dependency analysis helps avoid overlooked systems and unexpected outages. Apply that discipline whichever destination you choose.

Give each mandatory dependency an owner and a status: pending, pass, or fail. A feature description or successful disk conversion is not evidence that the entire service works.

3. Run a representative, isolated pilot

Choose a small group that exercises your real requirements: for example, a Windows application with its database, a Linux service, and a workload with demanding storage behavior. Use authorized copies with appropriate data protection. Keep test networks isolated to prevent duplicate addresses, domain identities, or scheduled jobs from affecting production.

Record source and destination versions, firmware, disk controllers, guest drivers, network mappings, and the transfer procedure. XCP-ng's migration documentation provides useful examples of firmware and guest-configuration planning. Follow the documentation for the destination you evaluate and record the results for your exact configuration.

Time the complete exercise, including preparation, transfer, first boot, corrections, application checks, and recovery. Keep the errors and manual steps in the results. They belong in the eventual schedule and staffing estimate.

4. Require evidence before a go decision

Go: every mandatory criterion has recorded evidence, an owner has accepted the result, and cutover and recovery fit the approved windows. Stop: unresolved data errors, unsupported mandatory dependencies, missed recovery targets, or unknown rollback behavior. Do not average a failed mandatory requirement into a favorable overall score.

5. Rehearse cutover and rollback

Define the migration sequence around application dependencies. Confirm a usable backup and the tested recovery procedure, announce the change window, quiesce writes as required, and identify the person making the go/no-go call. Set a decision deadline that leaves enough time to recover.

Write objective rollback triggers: failed integrity checks, a critical application test that cannot pass within the window, or performance below the agreed minimum. Record exactly how service will resume, which system is authoritative, and how writes made after cutover will be preserved or reconciled.

Keep the old environment recoverable until acceptance. Prevent simultaneous writers on old and new instances; restarting an outdated source after new writes can lose data. Rehearse rollback in isolation and obtain application-owner acceptance before retiring anything.

6. Compare the whole cost of operating it

Use the same period and workload assumptions for every candidate. Include software, support, backup changes, hardware, storage, training, migration labor, parallel operation, and downtime. Separate quoted costs from estimates and record their dates. A platform belongs on your shortlist when its evidence, operating model, and economics fit your requirements.

Two-server clusters are supported, with no rigid-quorum requirement. We can demonstrate clustering for free on your installation call and may agree a free trial for a small cluster for the beta period. Standard clustering prices apply unless we agree a trial; under standard pricing, every cluster member is licensed, including the first.

The introductory free installation call installs the product. Installation calls are free throughout closed beta and for the first few months after 1.0. White-glove workload migration is a separate service. Add your own hardware, backup, staffing, and operating costs to the worksheet.

See SynchresisVM pricing · Download the evaluation worksheet · Explore migration to SynchresisVM

Primary-source planning references checked October 19, 2026. Follow the documentation for the exact platform and version you evaluate.