How do I move my Zigbee network to a new coordinator without re-pairing every device?

Why re-pairing is avoidable at all#

A Zigbee device does not remember "the hub". It remembers a network: a 16-bit PAN ID, a 64-bit extended PAN ID, a channel, a 128-bit network key, and the IEEE address of the coordinator that acts as its Trust Center. Present all of those from a new piece of hardware and the device has no way to tell that the stick changed. That is the whole trick, and it is why Zigbee in 2026 calls the coordinator the one device you cannot lose without rebuilding: the identity lives in it.

So the real question is whether your software can read that identity out of the old coordinator and write it into the new one.

The confusion, settled#

Most blog answers to this query repeat a rule: migration only works within the same chipset family, TI to TI or Silicon Labs to Silicon Labs. That rule is real, but it is a Zigbee2MQTT rule. The Zigbee2MQTT FAQ says re-pairing is not required when the adapter type stays zstack or stays ember, and that zstack to ember or back "might not" need re-pairing, "however results might vary as this is not officially supported."

ZHA says something different. Its documentation states that ZHA "supports migrating the Zigbee network between different Zigbee adapters based on chips from Silicon Labs, Texas Instruments, or ConBee/RaspBee if the backup was made from inside ZHA." Cross-family moves are the documented case there, not an experiment.

Both statements are correct for their own software. The rule persists because guides quote the Zigbee2MQTT FAQ without naming the software. Name the software first and the chip second.

The migration matrix#

As of September 2026, from each project's own documentation:

Three details in that table catch people.

The deCONZ firmware floor. ZHA only migrates a ConBee or RaspBee running firmware 0x26700700 (dated 2021-08-18) or later. Update the old stick first if it is older.

The CC2531 exception. A CC2531 running Z-Stack 1.2 is a zstack adapter, so the same-family rule looks like it covers it. It does not: Zigbee2MQTT lists the move from Z-Stack 1.2 to Z-Stack 3 as needing re-pairing.

Changing software is the expensive move. ZHA's own limitations say devices "currently or previously connected to another Zigbee implementation will need to be reset to their factory default settings" before they can join ZHA. Switching from Zigbee2MQTT to ZHA forces the re-pair whatever stick you use. That is a platform move, and switching platforms without rebuying is the page for it.

What the backup actually carries#

Both projects use the Open ZigBee Coordinator Backup Format, a JSON specification from the zigpy project adopted by zigpy (the library under ZHA) and zigbee-herdsman (the library under Zigbee2MQTT). Its top-level fields are the precise answer to "what moves":

The line most people have not seen is the frame counter. The network key is not stored alone: the backup records its 32-bit frame counter and a re-keying sequence number with it, and link keys carry their own counters. A backup is a snapshot of live security state, not just a password. ZHA's recommended path restores a backup taken during the migration itself; reach for an older one only if the old adapter is already dead.

What the backup does not carry is everything above the radio: device names, areas and automations. Those stay in Home Assistant or in Zigbee2MQTT's data/ directory, untouched.

Step by step in ZHA#

1. Confirm the prerequisites

   The old adapter must be running under ZHA, not deCONZ or Zigbee2MQTT, and its radio type must be ezsp, znp or deCONZ. For deCONZ, confirm firmware 0x26700700 or later.

2. Start the wizard

   Go to Settings, then Connectivity, then Zigbee, and select Migrate. Plug in the new adapter on a USB extension cable into a USB 2.0 port or a powered USB 2.0 hub, away from USB 3.0 devices. The reasons for that are in 2.4 GHz interference and channel planning.

3. Let it take a fresh backup

   Select Submit. ZHA performs an automatic backup before anything else happens.

4. Choose the new adapter

   Under Migrate or change adapter settings, select Migrate to a new adapter, then pick the new adapter from the list of serial ports.

5. Choose the backup

   Migrate automatically (recommended) uses the backup just created. Advanced migration lets you pick an older one.

6. Accept the IEEE overwrite if asked

   If the new radio needs its IEEE address overwritten, ZHA prompts for it. Tick Permanently replace the radio IEEE address. The documentation says this is required for the migration to complete, and that skipping it means you "will have to reconnect many of your devices."

7. Wait, then wake stragglers

   ZHA resets the old adapter at the end. Devices are uncontrollable until they rejoin, which ZHA says normally happens within one hour, faster if you power-cycle them.

Step by step in Zigbee2MQTT#

Zigbee2MQTT has no wizard. It restores from coordinator_backup.json in its data/ directory (named zigbee2mqtt/ when running as a Home Assistant add-on), which it only produces for zstack and ember adapters.

1. Update and stop Zigbee2MQTT

   Run the latest version, then stop it.

2. Decide from the matrix whether re-pairing is required

   If it is, delete coordinator_backup.json and database.db and accept a fresh network. If it is not, leave both files exactly where they are.

3. Copy the old adapter's IEEE address into the new one

   This is the step ZHA does for you and Zigbee2MQTT does not. How the address is written depends on the adapter's flashing tool, so check the new adapter's own documentation.

4. Point the configuration at the new adapter

   Change serial.port in configuration.yaml, and the adapter type if it differs. Coming from an older adapter you may also need to change the baud rate; the FAQ gives ZBT-1 to ZBT-2 as an example.

5. Start Zigbee2MQTT and check every device

   If devices do not respond, the FAQ's advice is to restart some routers by removing them from mains power for a few seconds.

Why battery sensors come back last#

Mains-powered routers are always listening, so they resume within minutes. Battery end devices are the opposite. As Zigbee in 2026 explains, they sleep with the receiver off and only poll their parent occasionally, so a door sensor nobody has opened since the migration has had no reason to wake and notice. The fix is to make the device wake. Power-cycle it by pulling and reseating the battery, or press its button. Zigbee2MQTT's advice for keeping a battery device awake during pairing is to press its button about every three seconds.

Two practical consequences:

• Check mains devices first. If routers are not back, battery devices have fewer parents to rejoin through, which is the same reason a mesh that holds up is built from mains-powered devices outward.
• Do not read silence as failure too early. ZHA marks battery devices unavailable only after 21,600 seconds (six hours) of inactivity by default, and mains devices after 7,200 seconds (two hours). Trigger a quiet sensor before you call it lost.

If a device is still dead after it has been woken and its nearest routers are back, re-pair that one device rather than re-running the migration. Removing and re-pairing devices cleanly covers the reset sequence, and a device shows as unresponsive covers what else it might be.

Where this stops applying#

This page covers ZHA and Zigbee2MQTT, the two stacks where you own the coordinator and can read its backup. A closed hub with a built-in Zigbee radio, such as SmartThings or Hubitat, decides for itself whether its network can move, so follow that vendor's own replacement procedure. Moving devices from such a hub to a stick you own is a re-pair, and the order of operations is in switching platforms.

A migration is also not the moment to change channel. The backup puts the new coordinator on the old channel. If the channel was the problem, migrate first, then change it as a separate step with the channel planner. Coordinator hardware choices, including the single-radio limit on Zigbee or Thread combination dongles, are in Thread vs Zigbee and the Home Assistant platform guide.