A Safe Home Assistant Migration Checklist for a New Home Server

A safe Home Assistant migration is not finished when the new server reaches the login screen. The new host must recover the same configuration, radios, integrations, storage paths, network identity, and local-control behavior before the old server is retired.

Treat the move as a recovery test with a rollback copy still available. Create a fresh backup, record the old server's dependencies, restore on the target, reconnect radios and network storage, test critical automations, then keep the source powered off but intact until the new installation survives normal use and a reboot.

Take a Fresh Full Backup and Keep the Recovery Key Outside the Old Host

Home Assistant's current backup workflow supports migration during onboarding, including migration between different device types. Before starting, confirm the target has enough storage, download or otherwise preserve the backup, and keep the emergency kit needed to decrypt it away from the machine being replaced.

The current Home Assistant migration procedure uses a backup from the old device during onboarding on the new device and explicitly notes that network storage and radio migration may still need follow-up work.

Do not overwrite the only backup during the move. Keep at least one copy that is independent of both servers so a failed target disk or accidental reset cannot remove the recovery source and the source installation at the same time.

Record the Dependencies That a Backup Does Not Physically Move

A backup can preserve Home Assistant state, but it cannot physically move a USB Zigbee or Z-Wave stick, network cable, UPS connection, external database host, MQTT broker, reverse proxy, NAS share, or router reservation. Write down those dependencies before powering down the old host.

Record the old Home Assistant IP or hostname, external URL, network-storage mounts, database URL if Recorder is external, broker address, USB devices, radio types, and any host-level Compose or VM settings. This inventory is what lets you distinguish a failed restore from a missing external dependency.

The broader ZimaSpace migration checklist applies the same rule: protect the source, define what is actually in scope, verify the destination, and keep the old copy until normal use is proven.

Move Zigbee and Z-Wave Networks as Their Own Migration Step

If the same USB radio moves to the new host, reconnect it and verify the device path. If the new server uses a different built-in or replacement radio, migrate the radio network rather than assuming the Home Assistant backup alone changes the coordinator identity.

ZHA performs automatic network backups and supports migrating a Zigbee network to a different supported coordinator without re-pairing the entire mesh. The migration process may also transfer the radio IEEE identity when required.

Z-Wave has a separate controller state. A recent Z-Wave JS UI migration discussion confirms that the service store and an NVM backup are the critical recovery assets when moving the Z-Wave service to new hardware. Treat both radio networks as assets with their own recovery procedures.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Restore First, Then Reconnect External Storage and Network Services

Bring the target Home Assistant instance up from the backup before changing the router, DNS, NAS permissions, or multiple service addresses at once. A migration is easier to diagnose when the new host differs from the old host in only one major variable at a time.

If the old installation used network storage, reconnect it after restore and verify the expected share names and credentials. If it used an external database or MQTT broker, test DNS and TCP connectivity from the new host before changing Home Assistant configuration that was already known to work.

The application state can move, but host-specific dependencies still need to be recreated correctly. Keep the migration record focused on the things a Home Assistant backup cannot physically relocate: radios, host networking, external storage, database services, broker endpoints, and any deployment settings owned by the old server.

Run an Acceptance Test Before Retiring the Old Server

• Confirm expected users, dashboards, integrations, helpers, automations, and areas exist.
• Trigger one important local automation and confirm physical device feedback.
• Verify Zigbee, Z-Wave, Bluetooth, or other radio devices are available.
• Confirm Recorder history and statistics are writing normally.
• Test one network-storage path and one external dependency such as MQTT if used.
• Test local and remote access separately.
• Restart the new Home Assistant host once and repeat the critical local-control test.

Only after this second-boot test passes should you consider wiping or repurposing the old server. Until then, keep the source installation powered down, disconnected from conflicting radios or IP addresses, and available as a rollback reference.