Data Recovery Case File · Migrations · Too Hot to Copy

Working drives that can't survive their own transfer: the bare-NVMe heat problem decoded — and two rescued SSDs migrated under thermal management

His case wasn't a failure story — it was a rescue that kept stalling. The old laptop "had a GPU issue and failed due to overheating; fortunately the SSDs are still intact." Two NVMe drives, pulled from the casualty, data present and readable — and then the wall: "they are overheating every time I have them plugged in, to the point where the data transfer rate slows to a crawl and the device disconnects." A few attempts, same result each time, and then the instinct this archive keeps a medal for: "I am looking to have a professional look at them in case I do harm with this overheating." Exactly right — and exactly the correct moment. The page below explains why healthy NVMe drives cook in adapters, what the crawl-and-disconnect cycle was actually protecting, and how a migration gets finished when the patient can't tolerate its own copy.

Devices2× 1TB NVMe SSDs — recovered intact from a laptop lost to GPU overheating; data present and wanted whole on new storage
Reported behaviourDrives readable on connection → temperature climbing under transfer load → throughput collapsing to a crawl → device disconnecting; pattern repeated across attempts, then stopped on the do-no-harm instinct
Fault classNo fault — thermal-environment mismatch: bare NVMe under sustained load without the heatsinking its design assumes
Equipment usedThermally-managed native NVMe interfacing (heatsinked, monitored) · write-blocked whole-drive imaging in sustained cool passes · verified migration to new storage

The decode: why NVMe runs hot on purpose, and what the crawl-and-disconnect was doing for him

The design truth first: NVMe drives are small furnaces by intention — controllers running at speeds that generate real heat, engineered on the assumption that the host provides the cooling: the laptop's chassis, its thermal pads, its airflow. Inside his old machine, the drives lived against exactly that infrastructure. Pulled bare into a USB adapter, they lost it all — a naked stick of hot silicon in a plastic sleeve, asked to sustain a terabyte-scale transfer, the single heaviest continuous workload an SSD performs. The crawl, translated: the slowdown he watched was thermal throttling — the drive's own protection deliberately cutting speed as temperature climbs, trading performance for survival; and the disconnect that followed was the next rung of the same ladder: a controller reaching its thermal limit and shutting down rather than cooking — the drive ejecting itself to save itself. Nothing was failing; everything was protecting, loudly. Why his stop mattered anyway: the protection works, but repeated excursions to the thermal ceiling are not free — sustained high temperature is one of the genuine agers of flash and its controllers, and a transfer strategy of "try again until it finishes" runs the drives hot over and over while never actually completing (each disconnect abandoning progress). His few attempts cost little; a stubborn afternoon of them starts spending real margin — and his "in case I do harm" instinct drew the line at precisely the professional handoff point. And the reframe his case earns: not every job here is a broken drive — safe migration of working-but-vulnerable storage is legitimate bench work, and drives rescued from dead machines are its commonest customers.

The migration — cool, sustained, verified

The bench solved the environment, not the drives: each NVMe mounted on native interfacing with proper heatsinking and live thermal monitoring — the cooling their design always assumed, restored — and imaged write-blocked in single sustained passes at full, unthrottled pace, temperatures held flat well below the ceilings they'd been bouncing off at home. No crawls, no disconnects: two clean terabyte images, first attempt each. Both estates mounted whole from their images — the old laptop's complete working world, current to its final overheated day — verified by opening files across the set, and delivered migrated onto new storage in duplicate. The report gave his instinct its formal ratification: no drive fault present; thermal-environment mismatch under transfer load; owner's cessation after repeated throttle-shutdown cycles correct and protective; migration completed under thermal management without incident — plus the practical postscript for the two veterans: cleared for continued service in properly heatsinked homes, never again bare in a sleeve for anything sustained.

Outcome

Both drives migrated complete, cool, and verified — and the filings the bare-NVMe era needs. Read crawl-then-disconnect as thermal protection, not failure: the drive is throttling to survive and ejecting to save itself — and the correct response is better cooling, not better persistence; repeated hot retries age flash for nothing. Respect the transfer as the heavy lift it is: terabyte copies are sustained maximum load — exactly when a bare drive in a cheap adapter is least equipped to cope. And widen the definition of a recovery case: working drives that can't safely complete their own migration are proper bench work — rescued-from-dead-laptop drives most of all, because they're usually sole copies at their most vulnerable moment. He asked before harm instead of after it. Two intact terabytes stayed that way — which is, quietly, the best genre in this archive.

Rescued drives overheating mid-transfer

Stop retrying: throttling and thermal disconnects are protection, and repeated hot cycles spend real flash life while abandoning progress each time. Don't improvise cooling (fans aimed at bare boards, freezer folklore) and don't leave drives running hot "to see how far it gets." If the data is a sole copy, treat the migration as bench work: heatsinked native interfacing, one cool pass, verification after. And once migrated, house NVMe drives only where cooling exists — they were never designed to work naked.

Transfer keeps cooking the drive?
It's protecting itself — call Belfast Data Recovery on 028 9002 0144; one cool pass finishes what the sleeve couldn't.
Request a quote online →

Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.

Call us — 028 9002 0144
Mon–Fri · 9am–5:30pm · No fix, no fee
Start a free diagnostic →
028 9002 0144