How to Move Home Assistant Data Without Losing Users, History, or Settings

Move Home Assistant data by preserving the complete application state and keeping the old instance untouched until the replacement passes a full validation.

Users and settings are not just the visible YAML files, and history is not recreated by copying a dashboard. A migration must preserve the Home Assistant configuration directory or a supported backup, the Recorder database when history matters, hidden storage, secrets, custom components, and the runtime-specific device and network mappings around them. The safest sequence is inventory, consistent copy, isolated start, validation, then retirement of the source.

Inventory Persistent State and External Dependencies Before the Move

For a Container installation, treat the entire mounted Home Assistant configuration directory as the core recovery unit rather than selecting a few familiar files. Hidden state under .storage, authentication data, integration registries, dashboards, automations, and the default Recorder database can all live below that path. External MariaDB, MQTT, Zigbee gateways, secrets stores, or NAS mounts must be listed separately.

A Home Assistant container-migration walkthrough shows why a whole configuration-directory move is safer than reconstructing state file by file and emphasizes stopping the old container before a raw filesystem copy.

Create a manifest with source path, target path, owner UID/GID, database location, USB or serial devices, network mode, published ports, external services, and current Home Assistant version. If any dependency is undocumented, do not delete the old instance. The migration is not ready until the new host can reproduce that dependency from written information.

Create a Consistent Rollback Point Before Copying Data

Use the built-in backup or another application-aware method when your installation supports it. If you are performing a raw Container copy, stop Home Assistant before copying the active configuration database and related files. A plain live copy can capture application files at different moments, which is the opposite of a controlled migration.

Home Assistant's backup overhaul extended restore support across installation methods, which makes a supported backup a strong portability boundary when changing runtime. The practical lesson from cross-installation backup restore is that the new runtime can change while the application state remains the continuity boundary.

Keep two copies: one untouched pre-move recovery point and one working copy used for the migration. Do not let the new Home Assistant instance start against the only good source copy. If the target performs a migration or writes new registry state, you must still have a clean path back to the old version and old host.

Recreate Runtime-Specific Hardware and Network Mappings Separately

Application data does not automatically recreate host device paths. Zigbee or Z-Wave USB coordinators may appear under a different device name, Bluetooth access may differ, host networking can change discovery, and external databases or MQTT brokers may resolve through different addresses. Rebuild those interfaces explicitly before interpreting an unavailable integration as data loss.

An independent Container-to-HAOS migration walkthrough shows that restoring Home Assistant Core state does not automatically recreate sidecar services such as MQTT, Zigbee2MQTT, or Node-RED. Its sidecar-remapping migration sequence also verifies Recorder history continuity, USB coordinator access, and a stopped-but-intact old stack as the rollback path.

Start the target on a controlled LAN path and avoid running both instances with the same radios, webhooks, cloud accounts, or automations unless you have deliberately isolated them. Two active Home Assistant instances can send duplicate actions or compete for the same coordinator, making a correct data migration look broken.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Validate Users, History, Settings, and Device Control Before Cutover

Log in with an existing non-admin account, confirm an administrator account, open historical graphs from before the move, inspect integrations, trigger representative automations, and verify one device from every important protocol. Then restart Home Assistant and reboot the target host to prove the recovered state survives normal lifecycle events.

The related ZimaSpace explanation of Home Assistant persistent data roles provides the useful recovery boundary: durable identity, configuration, and history should be treated differently from cache or temporary files during a move.

Cut over DNS, proxy, or remote access only after the local tests pass. Keep the old host powered off but recoverable through at least one normal-use cycle. Retire it only when users, history, settings, automations, radios, external services, backup creation, and a reboot all behave as expected; a successful first dashboard load is not enough evidence to erase the rollback path.