Part of Software Development & Tools — the development stack: environments, APIs and tooling.
To clone Windows to an NVMe SSD you need four things: a rescue medium you have verified yourself, a partition layout you have inspected, an unambiguous way to tell the two drives apart, and a first boot with the old drive disconnected. This article walks through all four on a real machine, including the exact commands and the readings they produced. The migration moved a 446 GB Windows install onto a 2 TB drive and finished with a system that reads model files five times faster.
- Rescuezilla 2.6.2 cloned a 446.2 GiB Windows 11 partition disk-to-disk with zero errors and zero orphaned files.
- A byte-level readback proved the rescue USB matched the ISO in 3,113,943 of 3,113,944 sectors; only the GPT header differed, by 12 bytes.
- The cloned NTFS volume came up with the dirty bit set, so
chkdsk C: /fmust run before any partition resize. - Sequential read throughput rose from 461.6 MB/s on SATA to 2,339.6 MB/s on the NVMe drive — a 5.07× gain measured with unbuffered I/O.
- The first boot must happen with the source drive disconnected, because a clone carries identical EFI partition GUIDs.
Why an AI workstation outgrows a SATA SSD
Local language models changed what “enough storage” means. A single quantised 35B model in GGUF format occupies roughly 20 GB. Add a vision projector, a couple of alternative quantisations and an embedding model, and one experiment directory passes 60 GB. Meanwhile the operating system, the toolchain and the datasets all compete for the same volume.
The machine in this article hit that wall precisely. Its 480 GB Intel D3-S4510 had 21.1 GiB free out of 446.2 GiB, which is under 5%. Windows starts warning below 10%, and NTFS fragmentation gets worse as free space shrinks. Therefore the upgrade was overdue on capacity grounds alone.
Speed matters separately, and it matters more than people expect. SATA III tops out at 6 Gb/s, which translates to roughly 550 MB/s in practice. By comparison, a PCIe 4.0 NVMe drive reaches several gigabytes per second. Consequently every model load, every dataset scan and every container build waits on a bus that has not changed since 2009.
There is a second, less obvious reason to move. NVMe drives connect through PCIe lanes rather than a shared AHCI controller. As a result they handle deep queues far better, which matters when a training run and an editor index the same disk at once.
Hardware and software used in this migration
The target machine is a dual-socket workstation, not a desktop. Specifications matter here because M.2 slot behaviour differs between boards.
| Component | Detail |
|---|---|
| Workstation | HP Z6 G4, board ID 81C6, BIOS P60 v02.96 |
| CPU | 2 × Intel Xeon Gold 5118 (24 cores / 48 threads) |
| Memory | 64 GB DDR4 ECC |
| GPU | AMD Radeon PRO W7900, 48 GB VRAM |
| Source drive | Intel D3-S4510 480 GB SATA, 447.13 GiB, 3% wear |
| Target drive | Kingston KC3000 2 TB (SKC3000D/2048G), 1907.73 GiB, 0% wear |
| Operating system | Windows 11 Pro for Workstations 25H2, build 26200 |
| Cloning tool | Rescuezilla 2.6.2, Ubuntu 24.04 LTS base |
One detail deserves attention. The Z6 G4 is a PCIe 3.0 platform, so a PCIe 4.0 drive negotiates a Gen3 x4 link. The KC3000 therefore cannot reach its rated 7,000 MB/s here. Even so, the measured gain over SATA turned out to be substantial.
Preparation: three checks before you clone Windows to an NVMe SSD
Skipping preparation is how migrations fail. Each of the following checks takes minutes and prevents a class of problem that costs hours.
Confirm the partition layout is GPT
Windows 11 boots through UEFI, which requires a GPT disk with an EFI System Partition. Verify it before touching anything:
Get-Disk | Select-Object Number, FriendlyName, BusType, PartitionStyle, IsBoot, IsSystem
Get-Partition -DiskNumber 0 |
Select-Object PartitionNumber, DriveLetter, Type,
@{n='SizeGB';e={[math]::Round($_.Size/1GB,2)}},
@{n='OffsetGB';e={[math]::Round($_.Offset/1GB,2)}}The source disk reported the textbook Windows 11 layout: EFI 0.10 GiB, Microsoft Reserved 0.02 GiB, the C: volume at 446.20 GiB, and a 0.81 GiB Recovery partition at the very end. Note the position of that Recovery partition. It sits after C:, which becomes the central problem after cloning.
Check BitLocker before anything else
Block-level cloning copies an encrypted volume fine, but a locked volume you cannot unlock afterwards is unrecoverable. Run this from an elevated prompt:
manage-bde -statusOn this machine every volume reported Fully Decrypted, Protection Off and Key Protectors: None Found. That saved hours, because decrypting a 425 GB volume can take most of a day. If your output differs, export the recovery key first and decrypt before cloning.
Free ebook
Free AI Video, Generated Locally
Working scripts and measured benchmarks. Free.
No spam. Unsubscribe at any time.
Verify the rescue USB byte by byte
Most guides stop at “write the ISO and boot it”. However, a silently corrupted boot medium wastes an entire session. After writing Rescuezilla 2.6.2 to the stick, a full readback and hash comparison exposed exactly what changed:
Sectors compared : 3,113,944
Sectors differing: 1 (LBA 1)
Bytes differing : 12 of 512
Field USB ISO
AlternateLBA 125,927,423 3,113,943
LastUsableLBA 125,927,360 3,113,880
HeaderCRC32 0x29e4c572 0x7378dbc2
PartArrayCRC32 0x4afa5f79 0x4afa5f79 <- identicalThe single differing sector is the primary GPT header, which Windows rewrote to match the 60 GB stick instead of the 1.5 GB image. Crucially the partition entry array CRC stayed identical, which proves the partition table itself was untouched. In other words the medium was sound, and the mismatch was benign.
Installing the NVMe drive in an HP Z6 G4
Power down fully with shutdown /s /t 0 rather than the Start menu, then unplug the cable and hold the power button for 15 seconds. Workstation boards keep standby voltage alive as long as the PSU stays connected.
This board carries two on-board M.2 slots, silkscreened SSD0 and SSD1. Both are CPU-attached PCIe 3.0 x4 and accept modules up to the 22110 form factor. Therefore use SSD0 whenever it is free, because populating the second slot reroutes lanes and drops PCIe SLOT4 from x8 to x4.
Two practical notes follow. First, the module mounts vertically against a standoff on the chassis wall rather than lying flat, which is unusual and easy to misread. Second, leave the graphene sticker on the drive; in fact it is the heatspreader, not a label.
Afterwards boot Windows once, purely to confirm detection. Windows will offer to initialise the disk. Cancel that dialog. Instead the drive should report as RAW and uninitialised, which is exactly what the cloner expects.
Cloning with Rescuezilla, step by step
Rescuezilla runs from the USB stick as a live Linux environment. Boot it through the HP boot menu with F9, then pick the entry prefixed UEFI. If both Legacy and UEFI boot options are enabled, the stick appears twice, and choosing the wrong one produces an inconsistent clone.
Identify source and target beyond doubt
This is the step where mistakes destroy data, so use more than one signal. In this migration three independent markers separated the drives:
| Signal | Source (keep) | Target (erased) |
|---|---|---|
| Device node | /dev/sda | /dev/nvme0n1 |
| Capacity | 447.13 GiB | 1907.73 GiB |
| Model | SSDSC2KB480G8L | KINGSTON SKC3000D2048G |
| Serial / WWN | BTYF910407K6480BGN | 50026B7687553606 |
| Partitions | 4 (EFI, MSR, C:, Recovery) | none |
Different bus, different device name, four-times capacity difference and a printed WWN on the retail box. Any single one could mislead; all five agreeing cannot.
Run the disk-to-disk clone
Choose Clone, not Backup. Select the whole physical disk on both sides rather than individual partitions, so that EFI, MSR, C: and Recovery all travel together. Rescuezilla copies only used filesystem blocks, yet with 425 GB occupied that optimisation saves little here.
First boot after you clone Windows to an NVMe SSD
Shut down completely, then disconnect the source drive before the first boot. This is not optional, and the reason is structural rather than cautious.
A block-level clone reproduces the GPT partition GUIDs exactly. Both drives therefore present an EFI System Partition with the same identifier and a byte-identical bootmgfw.efi. Firmware cannot distinguish them, so it loads whichever enumerates first — and SATA usually enumerates before NVMe.
That failure mode showed up in this migration. The BIOS boot order listed the M.2 drive first, yet the machine still started the old Windows twice before the source drive was isolated. Disabling the sSATA controller in BIOS solved it as cleanly as unplugging the cable.
Results after cloning Windows to the NVMe SSD
Throughput was measured with unbuffered sequential reads of the same 19.92 GiB GGUF file on both drives, five runs each, using FILE_FLAG_NO_BUFFERING so the filesystem cache could not distort the numbers. An earlier attempt using ordinary buffered reads reported 2,723 MB/s from the SATA drive, which is physically impossible on a 6 Gb/s bus and revealed that the data was coming from RAM.
| Metric | Intel D3-S4510 (SATA) | Kingston KC3000 (NVMe) | Change |
|---|---|---|---|
| Sequential read, 5 runs | 461.6 ± 28.2 MB/s | 2,339.6 ± 333.4 MB/s | 5.07× |
| Sequential read, runs 2–5 | 474.3 ± 0.2 MB/s | 2,488.3 ± 28.0 MB/s | 5.25× |
| Time to read 19.92 GiB | 44.33 s | 8.90 s | −35.4 s |
| Usable capacity | 447.13 GiB | 1907.73 GiB | +1460.6 GiB |
| Free space on C: | 21.1 GiB | 1473.5 GiB | +1452.4 GiB |
| SMART wear | 3% | 0% | — |
Run 1 behaved as a warm-up on both drives and pulled the averages down. Runs 2 to 5 were remarkably stable, especially on SATA, where four consecutive runs landed within 0.4 MB/s of each other. Note also that 2,488 MB/s sits well below the KC3000 rating, because a single-threaded queue depth of one cannot saturate an NVMe drive.
The filesystem itself survived intact. A full chkdsk pass examined 3,830,272 file records in 3.11 minutes and reported 0 bad sectors, 0 bad file records and 0 orphaned files recovered to lost-and-found. Only cosmetic cleanup occurred: instance tags on one file and 4,159 unused security descriptors.
What can still go wrong after cloning Windows to NVMe
Three problems surfaced after this clone, and none of them appears in typical migration guides. The NTFS dirty bit blocked any safe partition resize. The Recovery partition sat between C: and the new free space, which greyed out Extend Volume. Finally the WinRE registration pointed at a stale disk GUID.
Each has a defined fix, and each is covered in the companion article on what breaks after cloning Windows. For choosing the drive in the first place, see the overview of SSD storage for local AI.
Frequently asked questions
Can I clone Windows to an NVMe SSD without reinstalling?
Yes. A disk-to-disk clone copies the EFI partition, the boot manager, Windows itself and all installed software. This migration required no reinstall and no reactivation.
Does Windows need a driver to boot from NVMe after a SATA install?
No, not on modern builds. Windows 11 ships stornvme enabled by default, so the cloned system booted from the NVMe drive without any driver work.
How long does cloning 425 GB take?
Between 1.5 and 3 hours in practice, limited by the source drive rather than the target. Plan for an uninterrupted session and disable sleep beforehand.
Do I have to disconnect the old drive when I clone Windows to an NVMe SSD?
Yes. Both drives carry identical EFI partition GUIDs after a clone, so the firmware cannot tell them apart. Disabling the SATA controller in BIOS works equally well.
Is Secure Boot a problem for Rescuezilla?
No. Rescuezilla 2.6.2 builds on Ubuntu 24.04 LTS with a bootloader signed by the Microsoft UEFI CA, so it starts with Secure Boot enabled.
Will the new drive show its full capacity straight away?
No. The clone reproduces the original partition sizes, so the extra space appears as unallocated at the end of the disk. Reclaiming it is a separate operation.
Does a PCIe 4.0 drive make sense in a PCIe 3.0 workstation?
Yes, within limits. The KC3000 negotiated a Gen3 x4 link and still delivered 4.9× the SATA throughput. The drive also remains useful if the machine is later replaced.
Summary
Cloning Windows to an NVMe SSD is a four-hour job when preparation is done properly, and a lost weekend when it is not. Verify the rescue medium by reading it back, confirm GPT and BitLocker status before starting, identify both drives through several independent signals, and isolate the source drive for the first boot.
On this HP Z6 G4 the migration lifted sequential reads from 461.6 MB/s to 2,339.6 MB/s, added 1,460 GiB of capacity and left the filesystem provably intact across 3.8 million file records. The remaining work — clearing the dirty bit, moving the Recovery partition and re-registering WinRE — is covered separately, because those steps are where most clones actually go wrong.
Free ebook
Free AI Video, Generated Locally
Run Wan 2.1 in ComfyUI on your own GPU — the scripts I use, measured times, sample clips. No cloud, no API keys.
No spam. Unsubscribe at any time.
Leave a Reply