Cold Migration

Power off a source VMware virtual machine and migrate it to NxtSight in a single pass — the simplest migration path for workloads that tolerate a maintenance window.

Overview

Cold migration is the simplest way to move a workload from VMware to NxtSight. The source VM is powered off, all disks are exported through the vSphere API, written into NxtSight Block Storage volumes, converted for NxtSight drivers, and the migrated instance is started in the target NxtSight project. The source VM remains in the source environment (powered off) until you confirm the migration succeeded.

Prerequisites

• A discovered workload that has passed preflight assessment
• A target NxtSight project with sufficient quota for the compute, memory, and volume footprint of the migrated VM
• A target NxtSight network that can host the migrated VM’s NICs
• An acceptable maintenance window — the source VM will be powered off for the duration of the migration

---

Lifecycle

Stage	What Happens
Queued	The job is accepted and waits for an available worker slot
Export	Source VM is powered off; disks are streamed over the vSphere API
Inspect	Guest OS family, firmware, and disk layout are detected
Write Volume	A new NxtSight Block Storage volume is created and disk data is written directly into it
Guest Fixes	VirtIO drivers are injected, the boot loader is repaired, and hypervisor-specific tooling is removed
Finalize	The volume is marked bootable, metadata is attached, and the target NxtSight instance is prepared
Completed	The target instance is created and ready to launch

---

Submit a Cold Migration

Dashboard

1. Open the Migrations tab

   Navigate to Migration → Migrations and click New Migration. Select Cold Migration and pick the source environment.

2. Select the workload

   Pick one or more VMs from the discovered inventory. Each selected VM must have a Pass or Warn preflight verdict.

3. Choose target project and quota

   Field	Description
   Target Project	NxtSight project to receive the migrated instance
   Instance Name	Name in the target project (defaults to the source VM name)
   Flavor	NxtSight flavor that matches or exceeds the source vCPU and memory
   Volume Type	Target storage tier for the migrated volumes
   Availability Zone	Optional — pin the instance to a specific zone

4. Map networks

   For each source NIC, pick a target NxtSight network and subnet. You can optionally request the same MAC address on the target network, subject to network policy.

   Save a network mapping as a reusable profile if you plan to migrate many VMs from the same source into the same target environment.

5. Review and submit

   Review the job summary, estimated runtime, and target resources. Click Submit. The job enters Queued state and is picked up by the next available migration worker.

6. Watch live progress

   The Migrations tab updates live with per-stage progress, bytes transferred, and an event stream. A completed job shows a link to the newly created NxtSight instance.

   Job status reaches Completed and the target instance is visible in the NxtSight Dashboard.

CLI

# Submit a cold migration for a single VM
nxtMove migration submit \
  --source prod-vcenter \
  --vm win-ser-2022 \
  --kind cold \
  --target-project infra \
  --flavor m1.large \
  --volume-type ssd \
  --network-map 'VM Network=internal-net'

# Watch live progress
nxtMove migration events --job <job-id> --follow

# Inspect the result
nxtMove migration show <job-id>

---

What Happens to the Source VM

During Migration

The source VM is powered off. All reads happen through the vSphere API, and the source disks are never written to — the migration is read-only on the source side.

After Migration

The source VM remains powered off in its source environment. nxtMove does not delete it — you choose when to decommission the source after you have validated the migrated instance on NxtSight.

Do not power the source VM back on after cutover if the target instance has already booted on NxtSight. The two VMs share identity (hostname, MAC, disk UUIDs) and running both simultaneously can cause network and storage-level conflicts.

---

Progress and Event Stream

Every cold migration publishes a stream of events that are visible live in the Migrations tab:

Event	When It Fires
source.powered_off	Source VM has reached poweredOff
export.started	Disk export has opened a session with the source
export.progress	Emitted periodically with bytes transferred
write.started	Target volume has been created and disk write has begun
write.progress	Emitted periodically during volume write
guest_fixes.started	VirtIO driver injection and boot loader repair have begun
finalize.completed	Target volume is bootable and attached to the target instance
migration.completed	Job is complete — target instance is ready

---

Next Steps

Post-Migration Validation

Verify the migrated instance boots and works as expected

Warm Migration

Use incremental sync for workloads that can’t tolerate a maintenance window

Troubleshooting

Diagnose stuck jobs and guest boot issues