What happens when the tiny computer running your smart home suddenly dies? Your lights, thermostats, and sensors don’t care that the hardware failed. They still expect instructions. The good news is that Home Assistant restore to new hardware is a well-trodden path, and with the right backup in hand, most users are back online in under an hour. The bad news is that the details trip people up, especially since the backup system was rebuilt in 2025 and many older tutorials are now out of date.
This guide walks through the full migration: what to prepare, how the restore actually works, what breaks, and how to avoid the classic mistakes. It focuses on Home Assistant OS, since that’s what most people run, but the principles apply broadly.
Why Moving to New Hardware Is More Common Than You Think
People migrate for all kinds of reasons. A Raspberry Pi’s SD card wears out after a couple of years of constant writes. Someone outgrows a Pi 4 and wants an x86 mini PC for faster automations. A used NUC shows up at a good price. Or a thunderstorm takes out the whole setup.
Whatever the trigger, the goal is the same: bring back the configuration, integrations, automations, dashboards, and add-ons exactly as they were. Home Assistant’s built-in backup feature is designed for precisely this. According to the official backup integration documentation, backups are encrypted archives that can contain your configuration, add-ons, and database, and they can be uploaded during or after onboarding on a fresh installation.
That last part matters. You don’t need to be a Linux wizard. You need a backup file and its encryption key.
Before You Touch Anything: The Pre-Migration Checklist
The single biggest cause of failed migrations is a backup that turns out to be incomplete, corrupted, or locked behind a lost key. Spend fifteen minutes on prep and save yourself a weekend of rebuilding automations by hand.
Confirm you have a current, complete backup
Go to Settings → System → Backups and check the timestamp. If the newest backup is weeks old, trigger a manual one now. A full backup includes your configuration, add-ons, and the recorder database. That database can be large, so if storage is tight, a partial backup that skips the database is a legitimate choice. You lose history graphs but keep every automation and integration.
Find and store the encryption key
Backups are encrypted by default. The key lives either inside the backup file itself or in a separate emergency kit, depending on how the backup was created. If the key is only in the file, download that file somewhere safe before the old hardware dies. If it’s in an emergency kit, print it or store it in a password manager. Losing the key makes the backup unrecoverable, full stop. This is the number one mistake people make, and there is no workaround.
Export a copy of your configuration folder
As a belt-and-braces measure, copy the entire `config` directory off the device using the Samba or SSH add-on, or a file editor. It won’t restore automatically, but if the backup restore goes sideways, having raw YAML files on a USB stick is a genuine lifesaver.
Note your network details
Static IP addresses, hostnames, and DHCP reservations generally do not carry over to new hardware. Write down what the old box used so you can recreate it. If your router hands out a reservation tied to a MAC address, you’ll need to update it for the new device.
Inventory your radio sticks
If you use Zigbee or Z-Wave, note the USB path each stick gets (something like `/dev/serial/by-id/…`). On new hardware, the path will almost certainly change, and integrations that reference the old path will fail to start until you point them at the new one.
Installing Home Assistant OS on the New Device
Start clean. Download the correct image for your hardware from the official installation page and flash it to the boot medium. For a Raspberry Pi, that’s an SD card or SSD. For x86 hardware, it’s usually a USB stick or internal drive.
Boot the new device and let it complete first-run onboarding. You’ll be asked to create an account and name the instance. Don’t worry about getting the name exactly right; the restore will overwrite most of this. Just get to a working dashboard.
One practical tip: connect the new machine by Ethernet for the initial setup. Wi-Fi configuration during onboarding is fiddly, and a wired connection removes a variable from the equation. You can switch to Wi-Fi later if you need to.
The Restore Itself: Step by Step
With a fresh installation running and your backup file accessible, the process is refreshingly short.
- Open Settings → System → Backups on the new installation.
- Choose the upload option and select your backup file, or point Home Assistant at a network location if you stored backups there.
- Enter the encryption key when prompted.
- Select what to restore. A full restore brings back configuration, add-ons, and database. A partial restore lets you pick.
- Confirm and wait. The system will restart, and add-ons may need to re-pull their container images, which can take a while on slower hardware or connections.
- Once it comes back, log in with your original credentials, not the ones you just created during onboarding.
After the restart, the instance UUID and encryption keys from the old system are restored too. That’s usually what you want, since cloud and remote-access integrations stay tied to the same identity. It also means anything paired with the old instance keeps working without re-pairing.
If you’re migrating from a pre-2025 installation, be aware that the old snapshot format was replaced by the new backup system. Very old snapshots may need conversion or a manual restore. Check the current documentation before assuming an ancient file will just work.
What Breaks After a Restore (and How to Fix It)
This is where reality diverges from the tidy documentation. A restore brings back your data, but it can’t bring back physical hardware relationships.
| What breaks | Why | Fix |
|---|---|---|
| Zigbee/Z-Wave integrations | USB device path changed on new hardware | Update the serial path in the integration settings |
| Static IP / hostname | Network config isn’t restored automatically | Reconfigure in Settings → System → Network |
| Bluetooth integrations | Different or missing Bluetooth adapter | Re-add the adapter or use a USB dongle |
| Add-ons that need hardware access | USB passthrough differs on new hardware | Re-map devices in the add-on configuration |
| Dashboards referencing camera streams | Camera IPs or credentials changed | Update the integration entries |
Work through the Settings → Devices & Services page methodically. Anything showing a red error badge needs attention. Most fixes are a matter of re-pointing an integration at a new device path or re-entering credentials.
If you’re also rethinking the surrounding setup while you’re at it, this is a natural moment to look at smart speakers for home automation or a reliable backup generator so a power event doesn’t take out the new box the way it took out the old one. (Home Assistant)
Restoring Without a Backup: The Hard Way
Sometimes the old hardware dies with no usable backup. It happens, and it’s painful but survivable. If you have the raw `config` folder, you can copy it into a fresh installation and restart. YAML-based automations, scripts, and dashboards come back. Integrations set up through the UI live in hidden storage files, which are trickier to transplant and may not survive a version mismatch.
If you have nothing at all, you’re rebuilding. Treat it as an opportunity: document everything this time, set up automatic backups to a network share or cloud target, and store the encryption key somewhere you’ll actually find it. A recurring calendar reminder to verify backups is not paranoia; it’s basic hygiene.
Choosing Better Hardware So You Only Do This Once
A migration is a good moment to size up. Raspberry Pi 4 and 5 boards handle most homes fine, but if you run many add-ons, cameras, or a large database, an x86 mini PC with an SSD is a meaningful upgrade. It’s faster, more reliable under sustained writes, and easier to back up.
Whatever you pick, put the boot medium on something durable. SD cards fail; SSDs mostly don’t. And keep the old device around for a week after migration. If something turns out to be missing, you can still pull files off it.
Conclusion
Restoring Home Assistant to new hardware is mostly a test of preparation. The restore command itself takes minutes. The encryption key, the complete backup, and a note about your USB device paths are what separate a smooth hour from a frustrating weekend. Verify your backup exists, confirm you can decrypt it, and write down your network and radio details before the old box gives up. Do that, and swapping hardware becomes a chore rather than a crisis. If you’re planning other upgrades around the same time, whether that’s home addition contractors for a dedicated server closet or just a better espresso machine for the wait, the same principle applies: prepare first, then execute.
Frequently Asked Questions
Can I restore a Home Assistant backup to different hardware than the original?
Yes. The backup is hardware-agnostic. You can move from a Raspberry Pi to an x86 mini PC or the other way around. The main adjustments afterward involve USB device paths for radio sticks, Bluetooth adapters, and network settings, which don’t transfer automatically.
What happens if I lose the backup encryption key?
The backup becomes unrecoverable. There is no bypass. This is why storing the key separately from the backup file matters. If the key was embedded in the file and the file is intact, you’re fine. If it was in an emergency kit that’s now gone, the archive cannot be opened.
How long does a restore take?
Typically ten to thirty minutes for the core restore, plus additional time for add-ons to re-download their container images. A large recorder database adds time. On slow hardware or a poor connection, expect closer to an hour.
Do I need to re-pair my Zigbee and Z-Wave devices?
Usually not. The pairing information lives in the integration’s data, which the backup restores. What changes is the USB path to the stick. Once you update that path in the integration settings, devices reconnect on their own.
Will my automations and dashboards survive the move?
Yes, assuming a full or configuration-inclusive backup. Automations, scripts, scenes, and dashboards are all part of the configuration and come back intact. Only things tied to physical hardware or external network addresses need manual attention.
Should I restore the database or skip it?
Restore it if you want your history graphs and long-term statistics. Skip it if you’re moving to hardware with limited storage or if the database is corrupt. Skipping costs you history but nothing functional, and it makes the restore noticeably faster.
A final note on timing: schedule the migration for a quiet period. Automations that depend on sunset, presence, or scheduled jobs may fire oddly during the restore window, and a half-restored system can leave lights stuck on or heating running. Disable critical automations beforehand, or accept a brief gap in coverage. Once everything is verified working, re-enable them and watch the logs for a day.
With the restore complete, integrations re-pointed, and backups confirmed running on the new hardware, the migration is genuinely finished. Keep the old device powered off but intact for a week, verify your first automatic backup lands successfully, and update your notes with the new device’s network details and USB paths. That small effort now is what makes the next hardware swap — whenever it comes — a routine afternoon rather than a scramble.
