A completed clone is a claim, not a result. The result is a server that boots alone, serves users, survives a restart, and keeps doing it for a week. This page is the test sequence that turns the claim into the result.
Most clone disasters are not clone failures — they are untested clones whose small problem (a swapped drive letter, a service that did not start, a share pointing at nothing) was discovered by fifty users on Monday morning instead of by one technician on Sunday. Testing takes twenty quiet minutes. Here is the order.
Disconnect the old drive completely (cable or caddy out, not just 'disabled') and boot. This proves the new drive's boot partitions came across whole, and it removes any chance of the two identical systems meeting. The first boot can be slower than usual while Windows adjusts to the new disk — give it time before judging. If it fails to boot here, nothing is lost: reconnect the old drive and the server is exactly where it was, and you re-clone with different settings in the next window.
Open Disk Management and confirm the drive letters match the old layout exactly — D: must still be D:, because shares, applications and backup jobs all point at letters. Then open the shared folders from the server itself and check the share names exist. A very common clone wrinkle: a data partition gets a different letter because the old drive's ghost is still in the configuration. Fix the letter here, in peace, rather than in front of users.
Open services.msc and scan the Automatic services for any that failed to start — databases, backup agents, print spooler, your management tools. Then Event Viewer, System log: the new drive should show no disk, storahci or NTFS errors. That silence is the sound of the rescue working — the old drive was generating those errors daily. Note the time of this clean bill; it is also your before/after evidence if anyone asks why the swap was worth it.
Go to an ordinary user's PC — not the server console — and do ordinary things: log in, open the main share, open and save a real file, print one page if this server shares printers. Then, back at the server, do the test people skip: restart it. A clone that boots once from a cold start but misbehaves after a warm restart (pending updates, a driver re-detect, a service race) is far better discovered by you, now, than by the office at 9 AM.
When everything passes, the old drive's job changes — from patient to insurance. Write on it with a marker: the server name, the date, 'FAILING — CLONE SOURCE — DO NOT BOOT'. Store it out of the server, somewhere it will not be casually reused. Keep it through at least a full week of normal work plus one backup cycle. Only then wipe or physically destroy it — it holds the office's entire data set, so its retirement is a security step, not tidying up.
The video includes the moment the server boots from its new drive and the checks that follow — watch what a clean first boot looks like.
▶️ Watch Full VideoUsually not. Windows re-detects the storage hardware, may finish pending maintenance, and antivirus often rescans. Judge the second boot, not the first — but do confirm in Task Manager that the disk is not pinned at 100% by an error loop, and check the Event Log for disk errors, which should be absent on the new drive.
In Disk Management, right-click the partition and choose Change Drive Letter and Paths, then set the original letter (free it first if another partition took it). Shares follow letters, so this one fix usually restores every 'missing' share at once.
At minimum one full working week plus one successful backup of the new setup. Subtle problems — a monthly report, a rarely used application — surface on their own schedule. Storage is cheap; an unrecoverable 'we wiped it yesterday' is not.