Identify the exact source server and destination resource, current disk format, storage tags, CPU family, snapshots and backup dependencies. Take an independent recovery copy and test access to it. Agree an outage budget and reserve destination capacity for the guest plus temporary conversion or transfer data.

1. Check the installed SolusVM migration requirements before choosing live or offline migration. Compare CPU architecture/features, host software compatibility and storage capabilities. A heterogeneous CPU fleet may require a common guest CPU policy designed before deployment.
2. Review guest snapshots and special devices. Existing snapshots can block migration, and attached accelerators or passthrough devices need their documented detach/re-attach plan. Preserve independent backups before removing any recovery option.
3. Confirm destination networking can serve the intended address. If the current migration workflow offers address changes, plan guest configuration, DNS, firewall rules and external allowlists together. Do not assume an old and a new release support identical IP-preservation behavior.
4. Check destination storage tags and format compatibility. If storage conversion is involved, determine whether existing full or incremental backups can restore to the new backend and reserve any required intermediate space. Do not disable placement safeguards merely to make a destination selectable.
5. Open the server migration action, select the destination and run the platform possibility checks. Resolve every failed prerequisite before starting. Schedule offline movement when live compatibility is uncertain or the application requires a coordinated stop.
6. Monitor transfer progress and host capacity. Keep the source recovery path intact while the platform completes its transition. After an offline move, start the guest through the supported workflow and inspect its console.
7. Validate the application before declaring success. Update the inventory and backup destination associations as required, then create and test a new recovery point suited to the final storage.

Only if the reverse path is compatible with its current state. A storage conversion, changed IP or application writes after the move can change recovery requirements. Define rollback before migration and avoid treating a stale source disk as current data.

Confirm the VM runs only on the intended destination and that its storage, IP addresses and console match the plan. Test authentication, scheduled jobs, database writes and external integrations. Observe latency and errors during normal traffic rather than relying solely on a green panel status.

If prechecks fail, stop before forcing a transfer. For an interrupted migration, inspect the platform task and determine which copy is authoritative before starting anything manually. Running duplicate guests with the same IP or writable shared disks can cause corruption. Escalate an ambiguous ownership state with the server ID, task ID and sanitized logs.

• Planning backups for SolusVM 2 servers
• Restoring a SolusVM 2 server backup safely
• Selecting storage for a SolusVM 2 compute resource
• Choosing a compatible CPU mode for KVM migration

• SolusVM: Migration Of Servers Between Compute Resources
• SolusVM: Choosing A Compute Resource Network Type
• SolusVM: Backing Up And Restoring Servers