Migration planner
Zigbee coordinator migration checklist
Answer a few questions about the coordinator you have, the one you are moving to, how many devices are on the network, how you run Home Assistant and — the question that decides everything — what state your backup is really in. You get an ordered, printable checklist with the preconditions, the fast path or the re-form path, the steps people most often skip, and an honest expectation about re-pairing. Everything is built in this page from your answers; nothing is read from your system and nothing is stored.
Nothing is generated yet. Fill in the form above and pressBuild my checklist — your answers stay in this page, and the checklist appears here ready to print, copy or download.
Read this before you start
The steps people most often skip
These are inside the plan below, flagged asOften skipped. They are listed here too because they are the ones a migration survives without noticing — until it does not.
Assumptions and limits
What this generator is, and what it is not
It is a checklist builder. It takes eight answers and returns the order of work for a Zigbee coordinator migration, with the preconditions, the branch that matches your hardware and backup, the verification pass and the way back out. It is not a network audit, not a live check of your setup, and not a guarantee: the page never reads your Home Assistant instance, your data folder, your backup file or your coordinator's firmware, and it says so in the output.
That limit is deliberate. A migration plan that claimed to inspect your backup would be describing something it cannot see, and the whole point of the checklist is that you go and look.
The one thing that decides whether devices stay paired
Zigbee devices do not store your coordinator's address. They store the network identity: the PAN ID, the extended PAN ID, the network key and the channel. If the new coordinator ends up carrying that same identity, every paired device carries on as if the radio had never moved. If it does not, nothing else in the plan can rescue the pairing — which is why recording those four values comes before the swap, not after it.
| Your situation | The path the plan takes | What to expect |
|---|---|---|
| Same firmware family, backup you have restored | Restore the coordinator backup onto the new radio | No re-pairing expected; verification pass only |
| Same firmware family, backup never restored | Restore it — but prove the file first, in phase 3 | Usually none, and the risk sits with the unopened file |
| Different firmware families (for example CC2652 to EFR32) | Re-form the network from the recorded PAN ID, extended PAN ID, network key and channel | Routers usually return on their own; expect to wake battery devices, and to re-pair any that stay silent |
| No backup at all | Re-form, with the recorded identity and no fallback | Budget for a walk round the house; the plan reorders verification around it |
How the checklist is put together
- Your answers set the branches. Firmware families decide restore versus re-form. Backup state decides how loudly phase 3 shouts. Device count and reachability set the verification pass and the time estimate.
- The order is the product. Recording the network before backing it up, backing it up before flashing, and flashing before the swap — each of those steps is cheap in order and expensive out of order.
- Every phase is generated from published behaviour, not from a template. The same rules that say a coordinator backup is firmware-family-specific also say which stack keeps its network identity in a file you can read and which keeps it inside a backup.
- Menus are landmarks, not gospel. Paths and labels describe Home Assistant 2026.10 with Zigbee2MQTT 2.x or ZHA. Wording moves between releases, so treat the names as directions rather than exact strings.
Steps people most often skip
- Opening the coordinator backup to confirm the network key and PAN ID are actually inside it — An unopened backup is a claim. It can be from before a firmware change, written by a different firmware family, or simply truncated — and the restore is the moment you find out.
- Writing down the network key, PAN ID, extended PAN ID and channel before anything is unplugged — Those four values are the network's identity. Once the old coordinator is out of service they can be hard to read back, and they are the only route to keeping devices paired when a backup cannot be restored.
- Checking that joining is disabled again after the migration — Pairing flows open the network and quietly leave it open. A network left in permit-join is open to anything nearby.
- Verifying routers outward from the coordinator instead of top-to-bottom through the device list — The mesh rebuilds outward. Working through a list in display order tells you almost nothing about where the routing is actually broken.
- Waiting a day, and keeping the old coordinator untouched, before declaring the migration finished — Sleepy battery devices can take hours to check in. Most 'failed' migrations are a device that had not woken up yet.
A worked example
The default answers in the form describe a common case: a Sonoff ZBDongle-P moving to a ZBDongle-E, 35 devices, Zigbee2MQTT on Home Assistant OS, a backup file that has never been restored, channel unchanged, no extension cable, and battery devices fixed out of reach. That combination produces the “careful” verdict — the hardware lines up, the backup is unproven — and it puts the same-family restore path in phase 5 while insisting that phase 3 opens the file first. Change the answer to a different firmware family and the plan switches to re-forming the network from your recorded parameters instead.
Related guides
Whether pairings survive a coordinator change depends on supported source and destination adapters and firmware migration, not just a verified backup or network key. Zigbee2MQTT documents backup and restore for its zstack and ember adapters; moving between those families is not officially supported, and some devices may need pairing again. That is why phase 3 of this checklist is written the way it is. See the Zigbee2MQTT adapter-migration FAQ. For the surrounding decisions: Home Assistant Zigbee gateway: coordinator choices explained, Home Assistant Zigbee2MQTT setup, start to finish and Zigbee channel vs Wi-Fi interference checker.
Two questions worth answering before you migrate
Is this a network audit?
No. It is a checklist generator. It reads nothing from your system and checks nothing for you — it takes your answers and produces the order of work, the preconditions, and the re-pairing expectation that go with them.
Which part actually decides whether devices stay paired?
Your backup, and whether the two coordinators use the same firmware family. The generator says which of the two paths you are on and what it means for your device count.