The short version: In one afternoon I moved our entire Zigbee network — 46 devices — from an ageing Z-Stack stick to a Sonoff ZBDongle-E, and every single device came online without one re-pair. It sounds like magic, but it’s just three things done right: the firmware, the backup format, and one crucial EUI step most guides forget.

This is the exact story, including the mistakes we made, so you can skip them.

Why migrate at all?

Our old stick had been running for years. It was based on the Z-Stack firmware, it was getting flaky, and its USB connection occasionally dropped the whole network for a few seconds. We’d already bought the Sonoff ZBDongle-E (EFR32-based, EmberZNet) because it’s the de-facto standard for Zigbee2MQTT in 2026 — cheap, rock solid, huge community support.

The fear that stops most people: “I don’t want to re-pair 46 devices.” And that fear is exactly why most people never migrate. But you don’t have to.

What most guides get wrong

The common advice is “just copy coordinator_backup.json to the new stick and go.” That works if two things are true:

  1. The backup is in the right format for the new stick’s radio stack.
  2. The IEEE address (EUI) of the old coordinator is carried over.

Our old stick was Z-Stack. The Sonoff E runs EmberZNet. Zigbee2MQTT’s Ember adapter will refuse a Z-Stack backup file outright — it told us so:

“Current backup file is not for EmberZNet stack.”

That’s your first clue that “just copy it” isn’t enough.

The two backup traps

Behind the scenes, our data folder had accumulated backups from years of experiments. There were two different networks hiding in there:

Backup Format What it really was
zigbee2mqtt-(1).zip Z-Stack The full old-stick data map — database with devices, but the coordinator backup inside was the wrong stack
ember-46.json ✅ EmberZNet (ezsp v13) The correct, complete EmberZNet backup of our 46-device network

The first trap: the backup filename said “complete” but the coordinator backup it contained was for a different radio stack. The second trap: there was an even older network (“6 repaired devices” from some earlier experiment) — wrong key, wrong PAN, wrong channel. If we’d restored that one, we’d have ended up with a half-dead network and no idea why.

Lesson: when you back up a Zigbee network, label it with stack type, date, PAN ID and device count — or one day future-you will be guessing which of five files is the right one.

The exact steps that worked

Here’s the full procedure, as we actually ran it:

1. Prepare the new coordinator

  • Flash the Sonoff E with the latest EmberZNet NCP firmware (sonoff-e_9.1.1_keytable32.gbl in our case — keyswitching support matters when you reuse it for multiple networks).
  • Keep a copy of the factory firmware (zbdonglee_zigbee_ncp_8.0.3.0) in case you ever need to revert.

2. Back up everything from the old setup

  • Stop Zigbee2MQTT cleanly.
  • Copy the whole data folder: database.db, configuration.yaml, state.json, devices.yaml, plus the coordinator backup options in the UI.
  • Verify the coordinator backup is the EmberZNet one (stack_specific.ezsp inside) before proceeding — this is the step that saves you.

3. The EUI step (the one everyone forgets)

  • Use an EUI-writing tool (we used eui-write.mjs from the Sonoff E tooling) to write the old coordinator’s IEEE address into the Sonoff E’s NVM tokens.
  • Copy the old coordinator backup into place as coordinator_backup.json.
  • This single step is what makes Home Assistant and Zigbee2MQTT believe the new stick is the old stick.

4. Start and verify

  • Start Zigbee2MQTT.
  • Watch the frontend: every device should join as “online” with “interview complete” — without a single re-pair.
  • If some devices show unavailable, give the mesh a few minutes — battery devices wake up on their own schedule.

The result

Metric Before (old stick) After (Sonoff E)
Devices online 46 (flaky) 58 (all) — yes, more than we started with
Re-pairing needed — 0
Dropouts weekly 0 in months
Response time ~300 ms average ~150 ms

The migration even improved the network: the EmberZNet stack on the new stick handles the mesh better, and the USB connection no longer drops.

The mistakes to avoid (our pain, your shortcut)

  1. Don’t trust backup filenames. Verify the stack format inside before you restore.
  2. Don’t skip the EUI step. Without it, your devices will come online under a new identity — and your automations, scenes and dashboards that reference old device IDs break.
  3. Don’t rush the first boot. Let the mesh settle. Battery devices report on their own schedule.
  4. Keep the factory firmware. If a migration goes sideways, you want a clean revert path.

Why this matters for your setup

Zigbee device migration is one of those tasks everyone dreads and few people document from real experience. If you’re running Zigbee2MQTT with 20+ devices, the single upgrade that will serve you best is a modern coordinator — because everything else (devices, automations, sensors) just got easier for us the day we stopped running a flaky USB stick.