Replace SmartThings or a cloud smart home hub

This is not one migration. It is three, they have different costs, and people fail at it because they plan for the first and discover the other two halfway through.

The hub is software: Home Assistant replaces it in an afternoon. The radios are hardware: the Zigbee mesh lives on the coordinator chip inside your old hub, that chip is not coming with you, and every device gets re-paired. The cloud-only devices are a loss, because anything whose only control path runs through a vendor account cannot be brought local at all.

Work out that third category first. It decides whether this is worth doing.

What you are actually giving up#

A hub that just works. SmartThings is an appliance. It updates itself, it has no breaking changes page, and nobody in your house has had to know what YAML is. Home Assistant ships monthly with its own breaking changes section, and one custom component that fails to load can stop the instance from starting. Its operational load is 4 out of 5 on this site's scale. That is not a criticism of the project, it is the price.

Every cloud-only device. A Wi-Fi plug that only speaks to its manufacturer's servers, an appliance that only answers through the vendor app, a doorbell with no local API: these do not migrate. Some have community integrations that reverse the cloud API and break when the vendor changes it. Some can be reflashed. Many are e-waste in this plan, and you should count them before you buy a coordinator.

Voice, on day one. Alexa and Google Assistant do not automatically see Home Assistant entities. Until you expose them back or move to the local Assist assistant, "turn off the kitchen light" stops working. That is the most visible thing you will break.

Two weeks of evenings. Pairing, naming, re-writing automations, and finding that the sensor you just mounted is deaf because the coordinator is in a USB 3 port.

If the house works today and nobody is unhappy, When not to self-host applies. The reasons to do it anyway are concrete: automations keep running when the internet is down, no vendor can retire a device you own, and nobody is monetizing a log of when you go to bed.

Get your device inventory out first#

Before you buy anything, build a table: every device, one row, four columns of name, radio, local control, replacement. The radio column is what matters. Sort every device into:

• Zigbee. Migrates, with your own coordinator and a re-pair.
• Z-Wave. Migrates, with a Z-Wave stick and an exclude-then-include per device.
• Matter or Thread. Migrates most cleanly, and needs a border router.
• Wi-Fi with a local API. Migrates. ESP-based devices can often be reflashed.
• Wi-Fi, cloud only. Does not migrate. Fill in the replacement column now.

Also mark which devices other people depend on. A bedroom lamp is not the same class of risk as the lock or the thermostat, and the ones that matter move last, not first.

Which one to pick#

Four pieces, and only the first is mandatory.

The install method is the decision you cannot cheaply reverse. Home Assistant now supports exactly two: HA OS, an appliance image for a Green, a Pi or a VM, and Container, one Docker image. Core and Supervised were deprecated in May 2025 and lost support at release 2025.12, along with i386, armhf and armv7 builds. If you followed a 2022 tutorial you are probably on a dead path.

Choose HA OS unless you already run a Docker host and enjoy it. Only HA OS gets Apps (renamed from Add-ons in 2026.2), one-click updates and Supervisor-managed backups. Container has no Apps panel, so Thread and Z-Wave lose their turnkey path and you run those containers yourself: fine if you already run Docker Engine, a genuine surprise if you picked Container because it sounded simpler. Give either the documented 2 GB of RAM and 2 vCPUs.

Zigbee2MQTT or ZHA. ZHA is built in, needs no broker, and supports EmberZNet, Z-Stack, ConBee and RaspBee, ZiGate and XBee radios, with the Connect ZBT-2 as the recommended adapter. It does not support Zigbee Green Power or Smart Energy profile devices. Zigbee2MQTT costs two containers (itself plus Mosquitto, which must be up first or it exits) and gives you broader device support, a live network map, OTA firmware pushes and MQTT topics other tools can subscribe to. Take Zigbee2MQTT if you like inspecting things, ZHA if you want fewer parts.

What it actually costs#

A coordinator, roughly the price of two smart bulbs. Buy from the supported list: a CC2652-based stick or an EmberZNet one. Only zStack and EmberZNet adapters support coordinator backups at all, and without one a dead stick means re-pairing the entire mesh.

A USB 2.0 extension cable, which is not optional. A stick in a USB 3 port, or next to an external SSD, sits in a wall of 2.4 GHz noise. Range collapses to a few meters and you will blame the mesh. Get one meter of extension between it and the host, away from any metal rack, then judge coverage. This is the commonest cause of a network that works next to the server and nowhere else.

A channel decision, made once. Zigbee's default channel 11 sits underneath Wi-Fi channel 1, and Wi-Fi wins. If your access points are on Wi-Fi 1, 6 and 11, put Zigbee on 15, 20 or 25:

# zigbee2mqtt data/configuration.yaml
advanced:
  channel: 20
  network_key: GENERATE
  pan_id: GENERATE
serial:
  port: /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus-if00-port0

Set network_key and pan_id to GENERATE once and never touch them again: changing either forces every device on the mesh to be re-paired, and battery devices usually need a physical reset to comply. Use the /dev/serial/by-id/ path, never /dev/ttyUSB0, which renumbers across reboots. Changing channel later drops devices that miss the announcement, which is why it is a day-one decision.

Disk and attention. Home Assistant idles near 600 MB and lands around 1.6 GB once Mosquitto, Zigbee2MQTT and ESPHome run alongside it. The recorder writes every state change and adds 20 to 150 MB a day; cut it with exclude filters on power meters and device trackers and a lower purge_keep_days before it eats an SD card.

ESPHome is a compiler, not a service. It idles at 150 MB and wants 1 GB or more while building, which is why compiles die on a 1 GB Pi. Every version bump means rebuilding and re-flashing every device, so define twenty identical sensors with one shared YAML package or that becomes twenty edits.

What breaks and how to tell early#

Voice, immediately. Test it on day one, not week three. Either expose entities back to Alexa and Google, or commit to the local Assist assistant on a phone, an ESPHome device or the Voice Preview Edition hardware. Assist runs locally and knows your devices; it is not a general-purpose assistant and language support varies.

Whatever the household uses without thinking. The first complaints are always the same three: the switch by the door, the bedtime routine, and the thing somebody controlled by voice. Migrate those last and keep the old hub powered until they are proven.

Sensors that report intermittently. That is the channel or the USB port, not the battery. Read the network map before you buy batteries.

The first Wednesday of the month. Core ships monthly and deprecates aggressively. Read the breaking changes, keep the previous backup, and note that a backup cannot be restored into an older core version, so a rollback means rolling the container tag back too.

A device you cannot reach. In ESPHome, always include an ap: block with captive_portal so a device that cannot join Wi-Fi raises its own access point. And 2026.1 dropped MD5 OTA authentication for SHA-256: upgrade the machine that flashes firmware before you upgrade devices, or a device in a ceiling becomes a ladder job.

The point of no return#

Re-pairing. Once a Zigbee device joins your new coordinator it has left the old hub's network, and putting it back is the same manual exercise in reverse. So: stand up Home Assistant, bring the SmartThings bridge up so nothing breaks, migrate device classes in order of how little anyone would notice, and unplug the old hub only when the inventory table is fully accounted for.

Back up before each batch. What matters is the whole Home Assistant config directory including the hidden .storage/, which holds config entries and the device and entity registries: restore without it and you re-add every integration by hand. Alongside it, the Zigbee2MQTT data directory, because configuration.yaml holds the network key every paired device depends on. Both are small. Keep them somewhere that survives the server, per Backups that actually restore.

What to do next#

Build the inventory table before you buy anything: it tells you whether this is a Saturday or a shopping trip. Then read the Home Assistant profile, pick HA OS or Container deliberately, order a supported coordinator and a USB extension cable, and plan the channel. If cameras are next, Replacing Ring and Nest cameras runs on the same hardware, and Home automation has the rest.