Short Answer: Sometimes You Can Keep Every Pairing, but Only if the Migration Path Preserves the Network Identity

If you are moving a Zigbee network in Home Assistant to a new coordinator, the answer is often yes, but not in every stack and not across every adapter family. Home Assistant's ZHA docs explicitly support backups and coordinator migration, and since the September 7, 2022 2022.9 release, Home Assistant has described that flow as a way to move to a new Zigbee coordinator without losing connected devices or settings.

But the phrase "without re-pairing" needs translation. It does not mean zero downtime, zero device churn, or zero risk. It means the new radio takes over the same Zigbee network identity so existing devices can rejoin it instead of being factory-reset and paired from scratch. The official ZHA migration docs say devices can take up to one hour to rejoin after the move.

Tara's rule: when you hear "no re-pairing," think same network identity, not magic instant cutover.

Why This Question Is All Over Home Assistant Right Now

The demand is real and current because Home Assistant itself raised expectations. On November 19, 2025, Home Assistant launched Connect ZBT-2 and said its improved migration tools make upgrades easy, adding that most adapters migrate with just a few clicks. The product page also markets seamless migration for Zigbee or Thread.

That immediately turned into concrete community questions. On November 22, 2025, a Home Assistant Community user with about 100 Zigbee devices asked for the most painless way to move from ConBee 2 to ZBT-2 while keeping automations intact. On December 7, 2025, another user asked whether a new ZBT-2 meant re-pairing every end device. Around the same time, Reddit threads asked how to migrate from ConBee 2 to ZBT-2, while a separate Reddit guide showed a Sonoff Dongle-P to ZBT-2 migration finishing with 156 devices back online and no manual re-pairing.

Inference from those sources: users keep hearing "migration" as if all coordinators behave alike, but the real dividing lines are ZHA vs Zigbee2MQTT, supported backup formats, chip family changes, and whether the old stick is still alive.

What Actually Decides Whether You Need to Re-Pair

The coordinator brand matters less than four technical facts: which stack you use, whether backups are supported for that stack and adapter, whether the old coordinator is still available, and whether the new radio can preserve the old coordinator identity.

If your current setup is... The likely answer is... Why
ZHA to another supported ZHA coordinator, with the old adapter still present Usually no full re-pairing Home Assistant's ZHA docs support backup and migration between supported Silicon Labs, Texas Instruments, and ConBee/RaspBee adapters.
Zigbee2MQTT zstack to zstack or ember to ember Often no full re-pairing Zigbee2MQTT says official backup and restore support currently exists for zstack and ember, and the old coordinator IEEE can be important.
Zigbee2MQTT zstack to ember or ember to zstack Sometimes Zigbee2MQTT says it might work without re-pairing, but results vary and it is not officially supported.
Zigbee2MQTT using conbee, older unsupported backup paths, or a stack family with no official restore flow Expect at least some re-pairing, sometimes a full rebuild Zigbee2MQTT says backup and restore is not officially implemented for those adapter families.
The old coordinator is dead, missing, or cannot be attached during migration The easy path gets much harder Home Assistant issue reports and support docs both imply the clean migration flow assumes the old coordinator is still available, unless you have a specific backup-file workflow.

ZHA Has the Cleanest Supported Story

The official ZHA documentation is the clearest source here. It says ZHA performs automatic backups of your Zigbee network and supports migrating to a different coordinator. It also says that, during migration, Home Assistant can prompt to overwrite the radio IEEE address when necessary so the new coordinator takes over the old network identity.

That is why ZHA-to-ZHA moves are usually the least dramatic path when you want to keep pairings. Home Assistant's own migration steps explicitly tell you to plug in the new radio, run Migrate, pick the new adapter, and then wait for the existing devices to rejoin the network. If you are already on ZHA and your radio family is supported, this is the closest thing to a native "just move the stick" experience.

The January 16, 2026 Nabu Casa support guide for migrating an existing ZHA network to a Connect adapter reinforces the same point: Home Assistant backs up the old adapter, moves the network settings to the new one, and existing devices usually rejoin within about an hour.

Zigbee2MQTT Can Also Work, but the Fine Print Matters More

Zigbee2MQTT is not a dead end for no-repair migration, but it is more conditional. Its current FAQ says official backup and restore support is implemented for zstack and ember adapters. It also says moves between those families might work without re-pairing, but that cross-family path is not officially supported and results can vary.

The same FAQ is blunt about what does force re-pairing: changing the network key, the PAN ID, or sometimes even the Zigbee channel. That means a clean coordinator migration is not the time to redesign the network. Keep the identity stable first. Optimize later.

Zigbee2MQTT's IEEE-copy documentation explains why this matters: some devices look up the coordinator by its IEEE address, so the new stick may need to use the same one. That is not a cosmetic detail. It is sometimes the difference between a network that quietly reforms and one that makes you walk around the house resetting sensors.

Important caution: Zigbee2MQTT also warns that some EFR32-based IEEE writes can be a one-time irreversible operation. Do not treat coordinator identity changes like a harmless toggle.

Why ConBee-to-Something-Else Is Where the Happy Marketing Ends

This is where most confusion shows up. A lot of users are not simply replacing one supported coordinator with another equivalent one. They are moving from ConBee II, old Sonoff hardware, or an older network built years ago into a newer adapter like ZBT-2. That is exactly why the community threads keep asking whether they should expect a clean migration or a total rebuild.

The technical issue is that Zigbee2MQTT's official backup and restore support does not cover every adapter family. Its docs say conbee, ezsp, zboss, and zigate do not have official backup-and-restore coverage in the same way zstack and ember do. That is why a ConBee II to ZBT-2 conversation feels very different from a Sonoff Dongle-P to ZBT-2 conversation.

So if someone tells you "I moved without re-pairing", the next question is not "Which brand?" It is "Which stack and chip family were you on before and after?"

The Practical Migration Path That Fails Least Often

1. Decide whether you are moving hardware only, or changing the whole Zigbee stack

If you are already happy with ZHA vs Zigbee2MQTT, do not turn a coordinator swap into a stack migration at the same time unless you have a very specific reason. Radio migration and application migration are different problems.

2. Back up both Home Assistant and the Zigbee network before touching the old adapter

For ZHA, Home Assistant already supports coordinator backups and manual backups from the network settings page. For Zigbee2MQTT, the docs say the network state lives partly in the coordinator and partly in the add-on data directory. This is also the moment to review how to back up Home Assistant so you can actually restore it.

3. Keep the old coordinator available if the migration flow expects it

This is one of the most important caveats in the whole article. A Home Assistant core issue around failed migration reports stated that the Migrate function does not work when you do not or cannot have the old coordinator connected. If the old stick is dead, stop assuming the normal wizard will save you and check whether you have a documented backup-file path for your exact stack.

4. Preserve coordinator identity only when the documented flow calls for it

In ZHA, the migration flow can prompt to overwrite the new radio's IEEE address when that is required. In Zigbee2MQTT, the official guidance is more manual and sometimes depends on adapter tools. The reason is straightforward: if the new stick presents the wrong coordinator identity, some devices will not trust it as the same network owner.

But do not casually write coordinator identity during normal operation. SONOFF's own migration tooling warns that changing the IEEE address is a migration-only action and can destabilize a live Zigbee network if you treat it like a routine configuration tweak.

5. Let the network settle before you declare failure

Even a good migration is not instantaneous. ZHA says existing devices can take up to an hour to rejoin. Zigbee2MQTT likewise recommends power-cycling routers if devices are slow to recover. Start with mains-powered routers like bulbs and plugs before you start factory-resetting battery sensors.

6. Do not confuse a migration problem with an RF placement problem

Some upgrades happen because the old network feels weak, not because the old adapter is truly failing. Before or after migration, follow the same boring rules that the official docs keep repeating: use an extension cable, keep the radio away from USB 3.0 noise, and avoid hiding it behind your server. The ZBT-2 launch blog explicitly says its new base and antenna were designed to reduce exactly that kind of interference pain.

When You Should Expect a Rebuild Instead of a Miracle

Some situations are strong warnings that you should budget for manual work:

  • You are moving from an adapter family without official Zigbee2MQTT backup and restore support.
  • You are changing both the coordinator and the Zigbee stack at the same time.
  • You no longer have the old coordinator available and did not save a usable coordinator backup.
  • You changed the network key, PAN ID, or channel during the move.
  • You expect Home Assistant entity names, areas, and automation assumptions to remain identical after a cross-stack migration.

That last point is easy to miss. A radio-level migration might preserve device pairings while the application-level model still shifts. If you move between ZHA and Zigbee2MQTT, the devices may survive but the entity surface can still change. That is a different kind of rebuild.

Tara's Take

The stable answer is not "yes" or "no." It is "only if you preserve the same Zigbee network identity through a supported path." If your house depends on Zigbee locks, water sensors, or key lighting automations, treat coordinator migration like planned maintenance, not like a lunchtime experiment.

If your real goal is better coverage or stability, remember that a better adapter helps only part of the story. A smarter layout of routers, cleaner USB placement, or a simpler architecture can solve the problem without forcing a risky migration at all. That is why this topic sits next to decisions like whether to separate Zigbee and Thread radios, which Home Assistant hardware to run, and how to move Home Assistant to new hardware.

If you are planning a bigger Zigbee or Home Assistant change, these are the adjacent decisions that usually matter most.

FAQ

Can ZHA move to a new Zigbee coordinator without re-pairing devices?

Usually yes. ZHA has a documented backup and migration flow, and Home Assistant explicitly supports coordinator migration for supported adapter families. The cleanest path is when the old adapter is already running in ZHA and is still available during the migration.

Can Zigbee2MQTT move to a new coordinator without re-pairing?

Often yes for supported zstack and ember backup paths, but not always. Zigbee2MQTT's own FAQ says some cross-family moves are unsupported or only partially supported, and preserving the coordinator IEEE address can be part of the success path.

Why are devices offline right after migration even if I did not re-pair them?

Because no re-pairing does not mean instant rejoin. The docs say devices can take minutes or up to an hour to come back, and power-cycling mains-powered routers often helps the mesh reform faster.

Does changing the Zigbee channel or network identity affect whether I must re-pair?

Yes. Zigbee2MQTT says changing the network key, PAN ID, or sometimes the channel can require re-pairing. If you want a low-drama coordinator move, keep those values stable during the migration.

Can I reuse the old coordinator as a router after migration?

Sometimes, but only after you are sure it no longer shares the migrated coordinator identity. Two radios acting like the same coordinator in the same area is a bad idea, and adapter-vendor tooling explicitly warns against casual IEEE changes on live networks.