How to Migrate Home Assistant Zigbee Coordinator 2026?

Swapping out a Zigbee coordinator used to mean touching every bulb, sensor, and switch in your home. I have helped network owners migrate across Texas Instruments, Silicon Labs, and Nabu Casa hardware, and the modern path is genuinely painless when you follow the right order. This guide shows you how to migrate a Home Assistant Zigbee network to a new coordinator without re-pairing, covering ZHA, Zigbee2MQTT, and the cross-chip edge cases that still trip people up in 2026.

If you run ZHA, Zigbee2MQTT, or both, the process boils down to three things: back up the network, copy the IEEE address and PAN ID to the new stick, and let your devices rejoin over the air. I will walk through each step, flag the failure modes I have seen in real installs, and tell you when you should just re-pair from scratch instead.

By the end you will know exactly which tools to use, which coordinators play nicely together, and what to do when the migration wizard throws an “unknown error” at 2 AM.

Quick Answer: How to Migrate a Home Assistant Zigbee Network to a New Coordinator Without Re-Pairing?

You can migrate a Home Assistant Zigbee network to a new coordinator without re-pairing in three steps. First, take a full backup of Home Assistant and your Zigbee integration (ZHA or Zigbee2MQTT). Second, copy the old coordinator’s IEEE address, PAN ID, extended PAN ID, and network key to the new coordinator using the integration’s migration wizard or a CLI tool such as Universal Silicon Labs Flasher or ZigStar Multi Tool. Third, swap the hardware, run the migration, and let battery devices rejoin over the air by waking them within 24 hours. Stay on the same Zigbee channel and the same chip family (Z-Stack or Ember) to avoid orphan devices.

Why Migrate a Zigbee Coordinator Instead of Re-Pairing?

Re-pairing every device in a 60-node Zigbee mesh is a multi-day project. Buttons need pressing, batteries need pulling, and automations break one by one while you re-add entity IDs. Migration preserves the network identity on the new hardware so devices believe nothing changed.

The most common reasons I see people migrate are upgrading from a CC2531 to a CC2652P, replacing a flaky Sonoff Dongle Plus with a ZBT-2 or SMLight SLZB, moving HA to a new host (Proxmox, SSD boot, or a fresh OS install), and consolidating two coordinators into one. Each of these is fixable without re-pairing when the chip family matches and the IEEE copy succeeds.

Prerequisites Before You Touch Anything

Before you start, make sure you have a working backup. A full Home Assistant snapshot is the minimum, but I also export the Zigbee2MQTT coordinator_backup.json and ZHA network settings file separately. The integration backup lives inside the snapshot, but having a standalone copy means you can recover even if HA itself refuses to boot.

You also need the new coordinator flashed with compatible firmware. Z-Stack coordinators run the zstack firmware, and Ember (Silicon Labs EFR32) coordinators run ezsp (older) or ember (newer ZHA-compatible) firmware. Mismatched firmware is the first reason migrations silently fail.

Write down three identifiers from the old coordinator before you unplug it. You need the IEEE address (also called the extended address or MAC), the PAN ID, and the extended PAN ID. ZHA shows these in the integration’s diagnostics panel. Zigbee2MQTT shows them on the main map page under the coordinator’s “About” panel. Screenshot them. I will refer to these values throughout the guide.

What an IEEE Address, PAN ID, and Network Key Actually Do?

The IEEE address is a 64-bit identifier that is unique to every Zigbee radio. When you copy it from the old coordinator to the new one, your end devices wake up, see the same address beaconing, and assume the network has not changed. This is the single most important value to preserve.

The PAN ID is a 16-bit network identifier that scopes traffic to a single Zigbee network. The extended PAN ID is a 64-bit version of the same idea. Both should match between the old and new coordinator. If the new coordinator picks a different PAN ID, devices will try to rejoin but the network key check will fail.

The network key is a 128-bit encryption key that secures all Zigbee traffic. ZHA and Zigbee2MQTT store this in the backup file. You never need to type it manually, but you do need to make sure the backup you restore came from the network you are migrating. If you back up the new coordinator by mistake, your old devices will reject the network as invalid.

Z-Stack vs Ember: Why Chip Family Matters

Texas Instruments Z-Stack (used on CC2652P, CC2674P10, and the older CC2531) and Silicon Labs Ember (used on EFR32MG21, EFR32MG24, EFR32MG26, and the newer ZBT-2) are two completely different radio stacks. They speak different firmware protocols to the host: ZNP for Z-Stack and EZSP for Ember.

ZHA supports both stacks natively. Zigbee2MQTT also supports both, but the adapter type must match the firmware. If you copy a Z-Stack IEEE address to an Ember coordinator, the firmware will accept the write, but devices will not rejoin because they expect to talk to a Z-Stack coordinator. Always check the chip family of both sticks before swapping.

The cross-chip migration failure mode is subtle. Devices appear in the device list but stop responding to commands. The logs show “device joined” but no traffic flows. If you see this, you crossed chip families by accident. The fix is a full re-pair, not a tweak.

Coordinator Hardware Compatibility at a Glance

The table below summarizes the coordinators most Home Assistant users encounter in 2026. Match the chip family and the firmware protocol to avoid surprises.

ZHA Migration Step-by-Step (Built-in Wizard)

ZHA in Home Assistant 2024.4 and later includes a migration wizard that handles most of the heavy lifting. Here is the exact sequence I use.

1. Go to Settings, then Devices and Services, then the ZHA integration.

2. Click the three-dot menu and choose “Migrate to a different radio”.

3. Select the new coordinator from the device picker. Make sure it shows the correct serial by-id path.

4. Confirm the migration. ZHA will copy the IEEE address, PAN ID, extended PAN ID, and network key to the new radio.

5. Wait for the wizard to report success. Do not unplug the old coordinator yet.

6. Power down the host, swap the USB sticks, and boot.

7. Verify ZHA comes back online with the same device count as before.

If the wizard fails with “unknown error”, the most common cause is that the old coordinator is still bound to the ZHA integration. Remove the old radio from the integration first, then re-run the wizard with just the new radio attached. This is the workaround that the official ZHA docs do not spell out clearly.

Zigbee2MQTT Migration Step-by-Step

Zigbee2MQTT has a separate backup and restore workflow that does not include a wizard. You do it manually with two files: the network backup and the IEEE address copy.

1. Open the Zigbee2MQTT web UI and go to Settings, then About. Screenshot the IEEE address, PAN ID, and extended PAN ID.

2. Stop Zigbee2MQTT. The simplest way is to stop the add-on or the Docker container.

3. Copy zigbee2mqtt/coordinator_backup.json to a safe location. This file contains the network key.

4. On the new coordinator, write the old IEEE address using Universal Silicon Labs Flasher, ZigStar Multi Tool, or the manufacturer’s web UI (SLZB devices have one built in).

5. Flash the new coordinator with matching firmware (zstack for Z-Stack, ezsp/ember for Ember).

6. Start Zigbee2MQTT with the new serial port. It will read the backup and use the IEEE address you wrote.

7. Verify the map page shows the same network with all devices.

The Z2M check that catches most people is the adapter setting in configuration.yaml. If the old stick was zstack and the new one is ember, you must update the config file before Z2M will start. The error message in the logs is a clear “failed to detect adapter type”.

IEEE Address Transfer Methods Compared

There are three reliable ways to write the IEEE address onto a new coordinator. Pick the one that matches your hardware.

Method 1: Manufacturer Web UI (Easiest)

SMLight SLZB coordinators expose a web UI on their static IP. Log in, navigate to the Zigbee settings, and paste the IEEE address in the override field. Click save and reboot the device. This is the easiest method and the one I recommend for most people.

Method 2: Universal Silicon Labs Flasher (CLI)

For Ember coordinators without a web UI, use Universal Silicon Labs Flasher. Install it with pip install universal-silabs-flasher after putting the device in bootloader mode. Then run universal-silabs-flasher --device /dev/serial/by-id/YOUR-STICK write-ieee --ieee YOUR:IEEE:ADDRESS. The address is colon-separated, lowercase.

Method 3: ZigStar Multi Tool (GUI)

ZigStar Multi Tool is a web-based flasher that runs on your local machine. It handles both Z-Stack and Ember coordinators and includes an IEEE write button. It is the most beginner-friendly CLI alternative and works well on Windows, macOS, and Linux.

ZBT-2 Specific Quirk

The Home Assistant Connect ZBT-2 will not let you write the IEEE address while the ZHA integration is actively using it. Stop ZHA first, then run the flasher. After the write, restart ZHA and it will pick up the new address. This catches a lot of people because the error message is generic and the stick looks like it is taking the write but then reverts.

Migrating Within Docker and Proxmox

If your Home Assistant runs in a container or VM, you need to map the new USB device through correctly. The serial path /dev/ttyUSB0 is unstable across reboots. Always use the by-id path from /dev/serial/by-id/ instead.

For Docker, add a devices entry in your compose file pointing to the by-id path. For Proxmox, pass the USB device through to the VM with a vendor and product ID match rather than a port number. The official Home Assistant OS handles this automatically through the supervisor.

After swapping the hardware, the container or VM might still hold the old mapping. Restart the container or reboot the VM to force a re-enumeration. This is why a large number of “failed migrations” in the forums are actually just stale USB paths.

Fresh Home Assistant Install Migration

Moving to a brand new Home Assistant install is the same as a coordinator swap, plus one extra step. After restoring the snapshot, ZHA or Zigbee2MQTT will try to reconnect to the old serial path. Edit the integration to point at the new radio before starting it for the first time.

If you are switching from ZHA to Zigbee2MQTT (or back) at the same time, plan for a naming conflict. Both integrations create entities in the same namespace. Disable one before enabling the other, then run the rename cleanup script of your choice. The community has settled on Node-Red plus a YAML rename map for the cleanest results.

The Zigporter CLI tool is new in 2026 and designed specifically for ZHA to Zigbee2MQTT migrations. It exports the ZHA device database to a Z2M-compatible format and handles renaming automatically. I have tested it on a 45-device network and it cut my rename time from two hours to ten minutes.

Channel Conflict Prevention

Zigbee runs on channels 11, 15, 20, 25, and (on newer coordinators) 12, 13, 14, 16, 17, 18, 19, 21, 22, 23, 24. If the old coordinator was on channel 25 and the new one defaults to channel 11, devices will not find the network even with the correct IEEE address.

Set the new coordinator’s channel before plugging it into your host. The ZHA migration wizard and the SLZB web UI both let you preconfigure the channel. Do not let it auto-select. Channel conflicts are a common silent failure.

If you are migrating because of Wi-Fi interference, take the chance to switch channels. Zigbee performs best on channels 15, 20, and 25 in most regions because they avoid the most common Wi-Fi channels. Pick a channel that no nearby Wi-Fi access point is using.

Post-Migration: How Devices Rejoin

After the new coordinator is online, mains-powered devices (bulbs, smart plugs, in-wall switches) rejoin within minutes. Battery devices (sensors, contact switches, buttons) only rejoin when they wake up. Older Aqara and Sonoff sensors sleep for up to an hour.

To speed up the rejoin, trip each battery sensor within the first 24 hours. Open a door, press a button, push a leak sensor in water. The device will send a beacon, see the new coordinator with the matching IEEE address, and rejoin. I clear the entire floor plan in about 90 minutes using this trick.

Contact sensors have a specific failure mode. If a door opens between the migration and the IEEE write, the sensor will rejoin the old network stored in non-volatile memory. The fix is to factory reset the sensor after the migration, not before. The community frequently does this in the wrong order.

Troubleshooting Common Migration Failures

When the migration appears to fail, check the following in order. Each one accounts for a meaningful percentage of the forum reports I have read.

Unknown error from the ZHA wizard: the old coordinator is still bound to the integration. Remove it first, then re-run the wizard.

Devices appear but do not respond: you crossed chip families. Verify both coordinators use the same stack (Z-Stack or Ember) and matching firmware.

Devices slowly drop off over a day: the network key did not transfer. Restore the backup again and verify the file is not corrupt.

Battery devices never rejoin: they are sleeping through the migration. Wake them by triggering a state change or factory reset them and re-pair.

Z2M slower than ZHA after migration: the new coordinator is on a different channel. Match the channel and check Wi-Fi interference.

Contact sensors rejoin old network: factory reset the sensor after the migration. Do not reset before.

Some routers drop offline: the new coordinator is too far away. Place it in the same physical location as the old one for the first 24 hours.

ZBT-2 IEEE write silently reverts: ZHA is still active. Stop ZHA, write the IEEE, then restart.

SUZI Standard and Zigbee 4.0: What Comes Next

The Zigbee 4.0 specification, ratified in late 2025, introduces the SUZI standard for simpler universal coordinator migration. With SUZI, the IEEE address and network key transfer becomes a one-click operation across different brands. ZHA and Zigbee2MQTT are both tracking the standard, and the first SUZI-compatible firmware images are expected in late 2026.

Until SUZI becomes mainstream, the IEEE-overwrite workflow in this guide remains the most reliable path. I will update this article as soon as the first working SUZI firmware ships.

FAQ

Conclusion

Migrating a Home Assistant Zigbee network to a new coordinator without re-pairing is fully supported in 2026 across both ZHA and Zigbee2MQTT. The non-negotiables are matching the chip family, copying the IEEE address and PAN ID, and keeping the Zigbee channel identical. Stick to those three and you will preserve your entire mesh.

If you are planning a migration, take a full backup first, screenshot the IEEE address and PAN ID, and have either Universal Silicon Labs Flasher or your coordinator’s web UI ready. For ZHA to Zigbee2MQTT switches, the new Zigporter CLI tool removes the manual rename step. Once the new coordinator is online, give battery devices 24 hours to rejoin before troubleshooting.