Migrating to New Hardware: From a Raspberry Pi to a More Powerful Server Without Losing Your Configuration
Migrating to New Hardware: From a Raspberry Pi to a More Powerful Server Without Losing Your Configuration
A Raspberry Pi that was plenty when you started the course starts struggling after adding dozens of integrations from Modules 9 through 22: the dashboard slows down, there aren't enough USB ports for a Zigbee coordinator and an ESPHome adapter at the same time. This lesson covers when it's worth migrating, how to do it through backup and restore, and what problems to expect.
Budget around 55 minutes. This lesson assumes a trustworthy, tested backup from Lesson 2: it's the only safe way to migrate between different hardware.
When It's Worth Migrating: Concrete Symptoms
The dashboard and history noticeably slow down: even after applying the database advice from Lesson 4
You're out of USB ports: for connecting the Zigbee coordinator from Module 9 and the ESPHome adapters from Module 10 at the same time
The system barely keeps up with add-ons: Music Assistant from Module 22 and Frigate from Module 21 together are a substantial load for weaker hardware
The SD card needs replacing more and more often: a sign of an approaching failure, independent of your backup
The Migration Process: Backup, New Hardware, Restore
1. Run a fresh, full backup on your current hardware, using the mechanism from Lesson 2.
2. Download the backup to your computer, or make sure it's available in a cloud location.
3. Install Home Assistant OS on the new hardware, following the instructions for that specific platform.
4. During first-time setup (onboarding), choose the restore-from-backup option instead of creating a new install.
5. Wait for the full restore: the whole migration process usually takes about ninety minutes.
The restore works even when migrating between completely different hardware, from a Raspberry Pi 4 to a virtual machine in Proxmox on an Intel processor, for example: a difference in hardware architecture is no obstacle to the restore process itself.
Common Problems After a Migration
| Problem | Solution |
|---|---|
| Not every add-on comes back automatically | check the list of installed add-ons after the restore and manually reinstall anything missing, Mosquitto from Module 6, for example |
| Integrations specific to the old hardware | remove integrations like a Raspberry Pi power monitor if the new hardware is a different platform |
| Supervisor needs repairing | from the Home Assistant CLI, run the Supervisor repair command, then restart the device |
| The Zigbee coordinator needs its USB port pointed to again | the port identifier (see Module 9's ZHA lesson) can change on new hardware |
A Pre-Migration Checklist: What to Prepare Before You Power Down the Old Hardware
☐ A fresh, full backup taken and downloaded to your computer, not just kept locally on the old hardware.
☐ A list of installed add-ons written down by hand, in case some don't come back automatically.
☐ The IP addresses and USB ports used by the Zigbee coordinator and ESPHome adapters noted down.
☐ Confirmed that the new hardware has enough USB ports for all your hardware devices.
☐ Time set aside for the migration with buffer: the process takes about ninety minutes, plus time to verify.
A Parallel Test: Checking the New Hardware Before Fully Switching Over
Instead of immediately powering down the old hardware, experienced users often run a so-called parallel test: restore the backup onto the new hardware, connected to the network under a different IP address, and check for a few days that everything works correctly before finally shutting down the old install. This needs either an extra Zigbee coordinator or temporarily swapping it between devices, but it significantly lowers the risk of a longer smart-home outage.
Signs the Migration Actually Succeeded, Not Just That It Looks Like It Did
☐ Every Zigbee device from Module 9 is visible and responds to control, not just showing its last known state.
☐ The Energy dashboard from Module 17 still shows a continuous history, with no gap on migration day.
☐ The safety automations from Module 18 fire correctly under a manual test.
☐ Add-ons like Mosquitto and Frigate came back with their configuration intact, not in a factory-reset state.
☐ System Health and Repairs show no new, unexpected errors related to the hardware change.
mDNS and Device Discovery After an IP Address Change
After migrating to new hardware, Home Assistant's IP address usually changes, which may require pointing some mobile integrations or external dashboards at the new address if they rely on a fixed address instead of the mDNS name (homeassistant.local). If you set up remote access following Module 7, it's worth verifying that port forwarding or your VPN tunnel still points at the correct, new device.
What to Do With the Old Hardware After a Successful Migration
The old hardware that used to run Home Assistant doesn't have to go straight into a drawer. A Raspberry Pi that's proven itself over years is a good candidate for an extra test install (useful for trying out the beta channel from Lesson 3), or a separate server dedicated to a single task, like a local ad-blocking DNS server. But before you hand it off or reset it to factory defaults, make sure you have a full backup from this device saved somewhere safe, even if you're no longer using it: it's cheap insurance in case something in the new install still needs restoring from the older configuration.
Migrating to Virtualization: Proxmox and USB Passthrough
An increasingly popular migration path is moving Home Assistant off dedicated hardware (a Raspberry Pi, a mini PC) onto a virtual machine in an environment like Proxmox, often sharing resources with other home services. The key challenge there is USB passthrough: handing the physical USB port with the Zigbee coordinator directly to the virtual machine, so Home Assistant sees the device the same way it would on dedicated hardware. Misconfigured passthrough is one of the most common reasons a Zigbee coordinator stops being visible after migrating to virtualization.
How to Test This Lesson
1. Assess your current hardware against the four symptoms listed in this lesson.
2. If you're planning a migration, run a fresh backup and check its size before you start.
3. Prepare a list of your currently installed add-ons, so you can verify completeness after the restore.
Common Mistakes
Migrating without a fresh backup: relying on an older copy means losing the most recent configuration changes
No verification of add-ons after the restore: some of them may not come back automatically
Leaving hardware-specific integrations in place: generating unnecessary errors in the logs on the new platform
Practical Task
☐ Draw up a list of symptoms suggesting your current hardware is starting to fall short.
☐ If a migration makes sense, schedule it with buffer time for any problems from this lesson.
☐ Write down in your smart-home notebook a list of add-ons and integrations to verify after migrating.
Key Takeaways
Migrating through backup and restore works even between completely different hardware architectures.
The whole process usually takes about ninety minutes with a well-prepared backup.
After migrating, always check add-ons, hardware-specific integrations, and the Zigbee coordinator's USB port.
What's Next
Next lesson: Network and VLAN for IoT Devices: Why It's Worth Isolating Your Smart Home. New, more powerful hardware is a good moment to rethink your network architecture.
