Smart Home

Migrate Home Assistant to a new server

Move Home Assistant to new hardware with a tested restore — full backup, the same-radio no-re-pairing rule, and the area/IP gotchas to verify before you wipe the old box.

Problem summary

Migrating Home Assistant is a full-backup restore, not a reinstall: the new box restores from the backup during onboarding, even across CPU architectures. Moving the same Zigbee/Thread radio with the backup means no re-pairing. The discipline that saves you is proving the restore on the new hardware before you wipe the old one — and watching the known gotchas: area assignments can drop, ZHA may need a reload to pick up its network, and the new box won't keep the old IP.

Operator snapshotEvidence first

First proof

Take a fresh full backup and confirm it's complete and downloadable.

Screen to open

Settings > System > Backups > Create backup (then download it off-device)

Expected signal

You have a current, retrievable full backup (ideally off the device too).

Stop boundary

Keep the old box until everything verifies.

Layer path

1Migrating Home Assistant is a full-backup restore, not a fresh install: the new machine restores the backup during onboarding and doesn't fully start until it completes — cross-CPU-architecture restore is supported.

2Moving the same Zigbee/Thread radio with the backup means no re-pairing — ZHA backs up the Zigbee network and the physical coordinator holds it.

3The discipline that prevents disasters is proving the restore on the new hardware before wiping the old box — keep the old machine intact until the new one is verified.

4Known gotchas survive even a 'successful' restore: area assignments can drop, ZHA may need a reload to load its network from backup, and the new box won't inherit the old IP.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Back up and copy it off-device

Check: Create a full backup and download it elsewhere.

Expected result: You have a retrievable, complete backup.

If not: Don't proceed on an on-device-only or partial backup.

Restore onto the new hardware

Check: Restore the backup during the new box's onboarding.

Expected result: Config, entities, and automations come across.

If not: Cross-architecture restore is supported; container restore — verify.

Move the radio and reload ZHA

Check: Plug the same dongle into the new box (by-id) and reload ZHA if needed.

Expected result: Zigbee/Thread devices respond without re-pairing.

If not: If you changed radio software, expect re-pairing instead.

Fix the known post-restore gaps

Check: Re-assign dropped areas and set a static IP/reservation.

Expected result: Rooms, automations, and reachability all work.

If not: These are documented gotchas — check them explicitly.

Prove it, then retire the old box

Check: Confirm entities, automations, and the network on the new box.

Expected result: The migration is verified end-to-end.

If not: Only now wipe/retire the old machine.

Decision tree

If: Same radio + full backup move together.

Then: No re-pairing needed.

Action: Restore the backup, plug in the dongle (by-id), reload ZHA if needed.

If: You're also changing radio software (ZHA↔Z2M).

Then: Re-pairing is generally required.

Action: Treat it as a stack switch, not just a migration — see ZHA vs Z2M.

If: Restore 'worked' but areas/automations look off.

Then: Known post-restore drop (areas) or ZHA not reloaded.

Action: Reload ZHA, re-assign areas, and re-check automations.

Safe stop: Keep the old box until everything verifies.

If: New box unreachable after restore.

Then: It didn't inherit the old IP.

Action: Set a static IP or DHCP reservation for the new machine.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Zigbee devices gone after migration.	Whether the same radio moved and ZHA was reloaded.	Radio move / ZHA reload	Move the same dongle (by-id); reload ZHA to load the backup network.
Entities back but rooms empty.	Area assignments post-restore.	Area-assignment drop on restore	Re-assign areas; verify before wiping the old box.
Can't reach HA on the new box.	The new machine's IP vs the old reservation.	IP not inherited	Set a static IP/DHCP reservation.
Restore behaves oddly on a container.	Install type (Container vs HAOS) and restore path.	Container restore nuance	Verify the restore on the new box before decommissioning.

Reference

Commands and settings paths

Create and export a full backup

Settings > System > Backups > Create backup (then download it off-device)

Where: In the Home Assistant UI.

Expected: A full backup exists and is copied somewhere other than the device.

Failure means: On-device-only backups are lost with the device.

Safe next step: Store a copy off the machine before migrating.

Confirm the radio path on the new host

ls -l /dev/serial/by-id/

Where: On the new server/VM host.

Expected: The same coordinator is present with a stable by-id name.

Failure means: If absent, passthrough/cabling is wrong on the new box.

Safe next step: Fix passthrough; point ZHA/Z2M at the by-id path.

Verify network + areas after restore

Settings > Devices & Services (ZHA) + Settings > Areas

Where: In the restored Home Assistant UI.

Expected: Zigbee devices respond and areas are intact.

Failure means: Missing network → reload ZHA; empty areas → re-assign.

Safe next step: Keep the old box until all of this verifies.

Hardware boundary

Hardware and platform boundary

Change only when

Migrate when you're moving to better hardware (Pi to mini-PC/NAS VM) — and do it as a tested restore that keeps the old box until the new one is proven.

Evidence that matters

A full off-device backup, the same coordinator radio referenced by by-id, and a verification pass (entities, automations, Zigbee network, areas, static IP) before decommissioning.

Evidence that does not matter

The new machine's raw specs — Home Assistant is light; what matters is a clean restore and the radio moving with it.

Avoid

Wiping the old box before verifying the new one, or assuming a 'successful' restore kept areas and the IP.

Related tool

Use the linked tool to turn this runbook into a guided check for your exact setup.

Backup plan builder

Last reviewed

2026-06-03 · Reviewed by HomeTechOps. Built from 2026-06 research verified against home-assistant.io (3-2-1 Backup, ZHA integration); leads with the tested-restore discipline (HomeTechOps' signature angle), the same-radio no-re-pair rule, and the documented post-restore gotchas (area drop, ZHA reload, IP). Backup encryption defaults are version-specific — verify before quoting.

Sources/assumptions

Assumes a full Home Assistant backup and moving the same USB Zigbee/Thread radio to the new server (a same-chip-family swap behaves similarly; a radio-software change does not).
Cross-architecture restore (e.g. Raspberry Pi to x86) is supported; backup encryption defaults and backup 'locations' are version-specific (changed across 2025.1/2025.2).
Restoring a Container install may not behave identically to HAOS — verify the restore on the new box before decommissioning the old one.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Home Assistant: 3-2-1 BackupsUsed for the full-backup-restore migration path (cross-architecture restore, backup locations/agents, encryption defaults) that underpins moving HA to a new server with a tested restore.Home Assistant: Zigbee Home Automation (ZHA) integrationUsed for ZHA's automatic Zigbee network backup, the built-in Migrate Radio wizard (cross-vendor), and the no-re-pairing-when-the-same-radio-moves fact for migrations.Home Assistant: Introducing Connect ZBT-2Used for the radio naming truth — SkyConnect was renamed Connect ZBT-1, which ended production Nov 2025; the current Zigbee/Thread adapter is Connect ZBT-2 (Zigbee OR Thread, not both at once).

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Confirm the layer (radio, IP, app) before deep config.
4. Stop when the evidence says the risk moved.

FAQ

Do I have to re-pair all my Zigbee devices when I move Home Assistant?

No — if you move the same radio and restore the full backup. ZHA backs up the Zigbee network and restores it, and the physical coordinator holds the network, so moving the dongle plus restoring the backup keeps your devices paired. Reference the dongle by its `by-id` path so a different USB port doesn't break it. Re-pairing is only forced if you change the radio software (ZHA↔Zigbee2MQTT) — see ZHA vs Zigbee2MQTT.

What's the safe way to migrate without losing my setup?

Treat it as a tested restore: take a full backup, restore it onto the new hardware, and verify entities, automations, and the Zigbee network actually work there before you wipe the old box. Keep the old machine intact until the new one is proven. This is the same restore-verification discipline as any backup — plan it with the backup plan builder.

What breaks on restore even when it 'works'?

A few documented gotchas: device/entity area assignments can drop even when the devices come back; ZHA sometimes needs the integration reloaded (or briefly removed) to pull its network from the backup; and the new server won't keep the old machine's IP, so set a static IP or DHCP reservation. Check these explicitly after restore rather than assuming a clean copy.