A hub fails at the worst possible moment: after a router change, during an update, or when the box itself stops starting. The smart lights may still turn on at the wall, but the schedules, sensor alerts and shared controls are gone. At that point, a list of device models does not restore the home. What matters is whether you preserved the controller configuration, the radio network, the encryption keys and the account access needed to recover it.
Quick answer: before replacing or resetting a smart-home hub, identify which system owns each device and routine. Make a supported configuration backup, confirm that its recovery credentials are stored outside the failing hub, document any separately managed Zigbee or Z-Wave radio network, and check the vendor’s exact migration procedure for your current and replacement hardware. Test a small, noncritical part of the restored home before treating the system as recovered.
Scope: This is a US-first planning and recovery Guide for homeowners, renters and property managers who operate their own authorized smart-home systems. It does not prescribe a universal Z-Wave NVM transfer, promise that all cloud ecosystems support downloadable backups, or replace vendor-supported restoration procedures. No hub migration or destructive reset described here was performed by WesternTechy. Source review: 21 October 2026.
Start with the four things that can be lost
| Layer | Examples of what lives here | What to verify before assuming it is backed up |
|---|---|---|
| Controller application and configuration | Home Assistant integrations, dashboards, entities, helper values and automations; Homey Flows; hub settings. | Can you export a supported configuration backup? Is the version compatible with the restoration target? |
| Radio-network state | Zigbee coordinator network and trust data; Z-Wave controller memory and device inclusion/security material. | Does the platform backup include radio data, or is a separate adapter-specific migration supported? |
| Cloud accounts and third-party authorizations | Manufacturer account ownership, external integrations, voice-assistant links, household membership and tokens. | Will a restore require reconnecting accounts or reauthorizing integrations? Do not record passwords in an ordinary worksheet. |
| Physical behavior and safe fallbacks | Which wall controls still work, which alerts require the hub, and which automations must be retested. | Can normal lighting, emergency access and certified life-safety functions remain usable while the hub is down? |
The layers are related but not interchangeable. A working copy of the Home Assistant configuration does not, by itself, prove that a particular replacement USB Z-Wave controller contains the right network state. Conversely, preserving radio-network details will not automatically rebuild all scene names, dashboards, integrations and third-party sign-ins. Treat a restoration as a sequence of validated dependencies, not a single “restore successful” message.
Diagnose the failure before restoring anything
| Symptom | Safer first check | Do not do this first |
|---|---|---|
| Only one or two devices stopped responding | Check power, the native device app, controller status and recent changes; use our Wi-Fi and discovery troubleshooting Guide. | Factory-reset every accessory or erase the hub. |
| The app cannot reach the hub, but local devices still work | Check internet versus LAN access, router address changes, hub power and status indicators; consult the model manual. | Assume the radio mesh has been erased. |
| A software update broke integrations or automation behavior | Record version, error messages, latest known-good backup and update notes; check vendor-supported rollback options. | Restore an older snapshot before understanding what new changes will be overwritten. |
| The hub or radio adapter is physically dead | Identify exactly which component failed, the last verified backup and supported compatible replacement. | Put a new radio into service and start pairing existing devices without a migration plan. |
| Moving house, selling a property or changing account owner | Separate the questions of hardware migration and owner transfer. Document devices that stay versus leave. | Hand a buyer your personal account, encryption kit or access tokens. |
The first decision should be reversible: look for recent power loss, an offline access point, expired sign-in, a failed update or a detached adapter. A genuine disk, hub or radio failure follows a different plan from a lost internet connection. If the fault is only discovery or Wi-Fi, our network troubleshooting Guide is the right starting point; this page begins when you need to protect or reconstruct controller state.
Prepare a recovery set while the system is healthy
- Record an accurate inventory: hub brand and exact model, software version, installation type, radio adapter models, owned integrations, current backup date, essential automations and their owner roles.
- Create a supported backup: follow the platform’s own menu and its limits; do not assume a screenshot of a device list is a restorable export.
- Store a copy outside the hub: a backup on the same failed storage device may be unavailable when it matters. Use another secure device and, where appropriate, encrypted off-site storage.
- Keep matching recovery material safely: encryption emergency kit and relevant vendor recovery credentials belong in secure storage controlled by the legitimate owner, not in a public document or shared worksheet.
- Note the radio dependency: write down whether Zigbee is managed by ZHA, Zigbee2MQTT or a proprietary hub; whether Z-Wave uses a separate controller; and whether vendor migration handles these networks.
- Define a low-risk restore test: keep a short acceptance checklist and perform a non-destructive verification of accessible backup files and metadata. Do not test by factory-resetting a healthy production hub.
Backup schedules are a maintenance decision, not a one-time migration chore. After adding many devices, changing radios or editing important routines, take a fresh supported backup. Record its date, target location, software version and restoration prerequisites. A backup created before half the devices were enrolled may be valid but insufficient to reconstruct the present home.
Platform-by-platform: what the vendor actually supports
Home Assistant: built-in backups, encryption and separate radio considerations
Home Assistant’s official backup guide documents scheduled and manual backups under Settings → System → Backups. It recommends storage away from the primary system. During setup, download the backup emergency kit and keep it safe. Encrypted backups require the matching key, including when the original machine is unavailable. The Home Assistant Cloud backup option is subject to its stated capacity and retention behavior; check your own configured destinations rather than assuming the service stores every backup.
Home Assistant’s recovery features cover the application, but radio details deserve a separate entry in your plan. The ZHA documentation says ZHA makes automatic Zigbee network backups and supports migration to certain compatible coordinator types using backups created by ZHA. That is a specific capability, not proof that every Zigbee coordinator or every Zigbee integration can be swapped interchangeably. For Z-Wave, identify the precise controller and software stack and use the supported radio migration instructions for those models; do not treat a generic application backup as an adapter-level guarantee.
Before running a Home Assistant restore, note which newer settings will be overwritten. The official full-restore documentation explicitly warns that changes after the backup are lost. Plan a return path rather than restoring experimentally because an integration temporarily says “unavailable.”
Homey Pro: distinguish cloud backups, USB backups and account reauthorization
Homey’s backup documentation states that its subscribed cloud backup service protects devices, Flows, settings and Zigbee/Z-Wave networks for the supported Homey Pro models. It also describes local backups through the Homey USB Tool. Those are different backup mechanisms; consult the documentation for your precise hardware generation. A replacement or migration can require a factory-default receiving device, and the official migration instructions say to power off the old Homey to prevent competing radios using the same network data.
After migrating Homey, the company instructs users to sign back into third-party services, and some Zigbee devices may require a repair command. Its separate Homey Pro mini documentation also specifies cross-model backup limitations. A backup that exists is not necessarily transferable to any newer or smaller hub.
Hubitat: application restore and radio migration are separate decisions
Hubitat’s Backup and Restore settings describe local backups alongside supported cloud backup and migration functions. Hubitat’s documentation states that cloud restore and certain Zigbee/Z-Wave radio migration capabilities can require its subscription services. The exact options depend on hub model and firmware. Before upgrading, check Hubitat’s hub migration instructions, particularly whether your source and replacement models support migrating the relevant radio. Do not promise yourself that importing a local database automatically moves radio pairing and security state.
SmartThings: supported Hub Replace and Hub Backup, not a universal export file
SmartThings describes Hub Replace as a way to transfer supported network and routine state between hubs. Its Hub Backup announcement describes secondary hubs that can assist after a primary failure. Neither description proves that every SmartThings hub, integrated Samsung appliance or discontinued model participates in every migration path. Confirm eligible source and destination models within your actual SmartThings Hub Manager before depending on a recovery procedure. Don’t infer that a user-downloadable whole-home backup file exists just because “Hub Backup” appears in marketing.
A worked recovery scenario: failed controller, functioning devices
Illustrative scenario, not a field test: A household uses Home Assistant on a small computer, a separate ZHA Zigbee adapter, and cloud-controlled cameras. The computer fails. The owner has a recent configuration backup and its encryption emergency kit stored on another computer, plus notes about which Zigbee adapter was in use.
- Decision 1: is the radio working? If the original Zigbee coordinator still works, identify its supported reconnection path instead of creating a new mesh.
- Decision 2: is the restoration target supported? Install Home Assistant by its official onboarding instructions on a compatible target and follow the supported restore path.
- Decision 3: does the restored integration find the correct adapter? Inspect its serial/network connection and configured integration before removing devices from the Zigbee network.
- Decision 4: which connections are external? Reauthorize camera and cloud integrations as required; do not assume local backup restored remote tokens or third-party account status.
- Decision 5: what actually works? Test a real switch, a battery sensor, a triggered routine, an offline recovery, notifications and normal physical controls. If something fails, record the failure without resetting all devices.
A different result is possible when the Zigbee adapter itself failed, when a Z-Wave radio cannot be restored to the proposed replacement, or when the only backup was on the dead drive. This is why the exact hardware and backup method matter more than a universal “five-click migration” promise.
Post-restore acceptance test: recover the household, not merely the dashboard
| Test | How to check it safely | Pass condition |
|---|---|---|
| Controller access and ownership | Use the supported owner account; check time zone, update status and connected integrations. | Correct owner can administer without exposing credentials to guests. |
| Normal physical controls | Operate a representative lamp or other low-risk device at its wall control. | Manual action works even if app automation is paused. |
| Radio networks and representative devices | Try one mains-powered device and one battery sensor from each network type where applicable. | Device commands and fresh sensor state updates appear, not merely cached status. |
| Automations and manual fallbacks | Use a real trigger with an allowed condition, then a blocked-condition case. | Expected actions run; excluded cases stay blocked; physical fallback still works. |
| Alerts and notification recipients | Send a low-risk test notification using approved platform methods. | Correct person receives it; obsolete household users do not. |
| Local and cloud paths | Check one supported local command and one cloud-linked integration separately. | No hidden dependency on a broken external account. |
| Reboot recovery | When safe, perform an ordinary supported restart and observe reconnection. | Core device functions recover without a cascade of manual resets. |
| Handover and records | Update controller serial/model, backup date, radio details and who has owner authority. | Next maintainer can find the recovery steps without receiving personal login details. |
For security cameras, locks, and heating equipment, use non-disruptive checks appropriate to the device. Never disable smoke/CO alarms, fire systems, required ventilation, or critical-access functions just to run a smart-home restoration test. Their certified stand-alone functions and emergency access must remain independent of a convenience automation where applicable.
When to stop and ask for manufacturer support
- A controller or radio reports corrupt firmware/NVM, encryption-key mismatch, missing ownership authorization or an unsupported cross-model restore.
- The replacement requires security-network key handling you cannot verify from the vendor’s documentation.
- A lock, alarm or safety-related device fails to operate normally after the migration.
- An earlier restore would overwrite important information with no verified rollback path.
- The home belongs to a landlord, employer or building and you lack authorization to modify shared systems.
Keep the original hub, adapter and untouched backups whenever it is safe and lawful to do so until the new system has passed acceptance tests. Where a vendor explicitly requires shutting down an old controller to prevent a duplicate radio network, follow that model-specific process. “Factory reset everything” is the final escalation after recovery options have been reviewed, not the opening step.
Printable controller recovery record
Copy or print this short recovery ledger. Record where a protected secret is stored, not the secret itself. Keep it private and verify that the intended new owner can access it.
| Item | Record or verify |
|---|---|
| Hub and software installation type | Model: __________ / Version: __________ / Managed by: __________ |
| Zigbee/Z-Wave/Thread network ownership | Radio and software stack: __________ / Adapter model: __________ |
| Backup state | Most recent backup date: __________ / Location: __________ / Encryption: __________ |
| Recovery-key location (not the key) | Controlled storage location and authorized custodian: __________ |
| Account and third-party integrations | Owner role: __________ / Services requiring reauthorization: __________ |
| Supported replacement or migration route | Official documentation link and compatible target: __________ |
| Fallback essentials | Lighting: __________ / Access: __________ / Critical alerts: __________ |
| Acceptance test date and outstanding exceptions | Date: __________ / Failures to resolve: __________ |
Related WesternTechy guides and resources
- Networks, Standards & Reliability hub — the broader problem-solving pathway.
- Wi-Fi, Matter & Thread troubleshooting — distinguish local-network failures from failed controller state.
- How to Install a Z-Wave Hub — new-device inclusion and security.
- Network Readiness Checklist — check physical network and radio basics.
- Device Inventory & Account Transfer Tracker — document ownership, models and handover.
- Automation Planning & Testing Worksheet — test routines and manual fallback after recovery.
Official source log and editorial limitations
Research review: 21 October 2026. Primary documentation: Home Assistant backups and restores; Home Assistant encryption emergency kit; ZHA backups and supported coordinator migrations; Homey Pro backup; Homey Pro migration; Hubitat Backup and Restore; Hubitat hub migration; SmartThings Hub Replace; and SmartThings Hub Backup overview. This Guide synthesizes vendor procedures with an original recovery/validation framework. The comparisons are not claims of hands-on restoration testing. Model, firmware, plan and region restrictions can change; check the official procedure immediately before a destructive operation.