My old Synology DS918+ died on a Tuesday night with that specific double beep that means the unit, not a disk, has failed. I had four drives full of family photos and no recent offsite copy, which is exactly the situation you do not want to learn a lesson in.
The good news is that on most modern NAS units, your data does not live inside the box. It lives on the disks. The box is just a computer that reads them.
That single fact is what makes a drive transplant possible. It is also what people get catastrophically wrong when they assume the array is somehow tied to the hardware.
What actually lives on the disks
When you build a RAID array on a Synology, QNAP, or TrueNAS system, the array metadata is written to the drives themselves. Linux software RAID (mdadm) and modern filesystems like Btrfs and ZFS store the layout, the disk order, and the pool configuration right there on the platters.
The chassis contributes the CPU, the RAM, and the operating system that assembles those pieces back into a usable volume. Move the disks to compatible hardware and the new box can, in most cases, read the metadata and rebuild the array exactly as it was.
This is why a same-brand migration is usually painless and a cross-brand migration usually is not. The metadata format has to be understood by whatever OS boots on the other side.
Same-brand moves: the easy path
Moving disks between two units from the same maker, on the same OS generation, is the migration that just works. Synology even has an official process for it.
Synology to Synology
Power down both units fully. Pull the drives from the old box keeping track of the bay order, then insert them into the new box in the same order. Power on the new unit.
DSM will detect a foreign but migratable configuration and offer a Migration option that keeps your data, packages, and most settings. There is also a Clean Installation option sitting right next to it, and that one wipes the volume, so read the screen carefully before you click.
Synology publishes a compatibility matrix for which models can migrate to which. It is worth a two-minute check before you buy the replacement. See the official Synology migration guide for the current supported paths.
QNAP to QNAP
QNAP works the same way in principle. Shut down, transfer disks in order, boot the new unit, and QTS walks you through a system migration that preserves the storage pool. The main gotcha is firmware: the destination should be on the same or newer QTS major version, never older.
The step-by-step transplant
Here is the sequence I follow every time, whether it is a planned upgrade or a dead-unit rescue.
- Get a backup first if you possibly can. If the old unit still boots, copy the critical folders to a USB drive or the cloud. A migration that goes wrong is survivable only with a backup.
- Power down both NAS units completely. Not sleep, not hibernate. Pull the plug and wait for every light to go dark.
- Remove drives one bay at a time, labeling as you go. Tape marked Bay 1, Bay 2, Bay 3, Bay 4. Do not trust your memory.
- Seat each drive firmly in the matching bay of the new unit. Same order in, same order out. Listen for the tray to click home.
- Power on and watch the first-boot screen carefully. Choose Migrate or the equivalent, never Clean Install or Initialize.
- Let it finish before touching anything. A large array can take 20 to 40 minutes to import and verify. Interrupting mid-import is how pools get corrupted.
Nine times out of ten, that is the whole job. The array comes up, the shares reappear, and you are done inside an hour.
Cross-brand moves and why they usually fail
This is where people get hurt. You cannot pull disks out of a Synology and drop them into a QNAP and expect the pool to mount. The two systems use different volume layouts and package structures even when both sit on Linux underneath.
A Synology volume typically uses mdadm plus LVM plus Btrfs in a specific stacked arrangement that QTS does not recognize as its own. QTS will see foreign disks, tell you they are uninitialized, and cheerfully offer to format them.
Do not accept that offer. Formatting is the one action that turns a recoverable situation into a data-recovery-lab situation.
Same OS family, different chassis
The migration that genuinely crosses hardware is a TrueNAS or Unraid rebuild. Because the filesystem is standard, you can build a completely new machine with different parts and import the existing pool.
On TrueNAS you install the OS on the boot drive, then go to Storage and choose Import Pool. The system scans the data disks, finds the ZFS pool metadata, and brings it online with all your datasets intact. The TrueNAS project documents this import flow in its official TrueNAS documentation.
Unraid behaves similarly but is fussier about parity. As long as you assign each disk to the same slot it occupied before, the array validates without a rebuild. Put a data disk in the parity slot by mistake, though, and Unraid will start overwriting it.
When a transplant is not possible at all
There is exactly one situation where moving drives never works: hardware encryption tied to the source unit.
Some NAS models offer self-encrypting drive support or a hardware security module where the encryption key is bound to that specific chassis. Move those disks and the data is mathematically unreadable, key gone, done. If you use full-volume encryption, export and safely store the recovery key before you ever need it.
| Scenario | Can you transplant? | Method |
|---|---|---|
| Synology to Synology | Yes | DSM Migration |
| QNAP to QNAP | Yes | QTS system migration |
| ZFS box to ZFS box | Yes | Pool import |
| Synology to QNAP (or reverse) | No | Backup and restore only |
| Chassis-bound encryption | No | Data is unrecoverable without the key |
The rescue that saved my photos
Back to my dead DS918+. I bought a refurbished DS920+ for about 380 dollars, updated it to the current DSM before touching my old disks, then powered it off.
I moved all four drives in their original bay order, powered on, and chose Migrate. Twenty-five minutes later every share, every photo, and every user account was exactly where it had been. The only thing I had to redo was a couple of scheduled backup jobs.
The lesson I took from that night is simple. Know before the emergency whether your setup supports a transplant, keep the drive order sacred, and never let a machine format disks it calls uninitialized. Do those three things and a dead NAS becomes a bad evening instead of a lost decade.
Frequently asked questions
Will moving my drives to a new NAS erase my data?
Not if you choose the Migrate option instead of Clean Installation or Initialize during first boot. The migration path reads the existing RAID metadata and keeps your volume intact. Formatting or initializing is the only choice that wipes the pool, so read every prompt carefully before clicking.
Can I move drives from a Synology to a QNAP?
No. The two brands use incompatible volume layouts, so the destination will see the disks as uninitialized and offer to format them. Your only safe path across brands is to back up the data from the old unit and restore it onto a freshly configured new one.
Does the order of the drives matter when I move them?
It can, so treat it as if it always does. Label each bay before you pull anything and insert the disks in the same order on the new unit. ZFS pools tolerate reordering, but some mdadm and Unraid setups do not, and a wrong slot can trigger an overwrite.
What if the new NAS has older firmware than the old one?
A destination running older firmware may refuse to mount a pool created by newer software. Always update the new unit to a firmware version equal to or newer than the old one before you insert the migrated drives. This one step prevents the most common mount failure.
Can I move a ZFS pool to completely different hardware?
Yes. The ZFS on-disk format is portable, so you can install TrueNAS on a new machine, move the data disks over, and run Import Pool. The system finds the pool metadata and brings all your datasets back online without a rebuild.
Is there any case where a drive transplant is impossible?
Yes, when encryption keys are bound to the original chassis, such as certain self-encrypting drive or hardware security module setups. Move those disks and the data becomes mathematically unreadable. Always export and store your encryption recovery key before you need it.
