Migrating Devices From One Hub to Another: A Realistic Playbook

Moving devices between hubs sounds simple but the device-by-device flow has subtle traps. Here is the realistic playbook that prevents losing automations.

Migrating Devices From One Hub to Another: A Realistic Playbook
Difficulty Advanced
Estimated time 2 hours
Last tested May 2026
Verified on HomeKit, Alexa, Google Home +4

You decided to migrate from your current hub to a new one. Maybe you outgrew SmartThings and moved to Home Assistant. Maybe a hub died and you bought its successor. Whatever the reason, you now have a closet full of paired devices on the old hub and an empty new hub waiting to receive them. The migration is more involved than “unpair and re-pair”, and the order matters more than most guides admit.

The hard truth about migrations

Most Zigbee and Z-Wave devices cannot be “transferred” between hubs. Their security pairings live on the radio of the original hub. To move them, you have to exclude (Z-Wave) or unpair (Zigbee) from the source hub, then include or pair on the destination hub from scratch.

This is not a hub limitation. It is how the underlying protocols work. Even Home Assistant cannot magically read security keys off a SmartThings hub.

What you can preserve: device metadata (names, rooms, automations) by copying it from one system to another at the application layer. The actual radio pairing has to be redone.

Plan before you start

Document everything before you touch a single device.

  • Export your device list from the old hub. Most hubs let you copy or screenshot.
  • For each device, note: name, room, manufacturer, model, paired status, any associated automations.
  • List your automations and what devices each one uses.
  • List your scenes and what devices they include.
  • Note any integrations (voice assistants, IFTTT, third-party apps) that reference these devices.

This will take an hour for a typical setup. It is essential. The number of users who started a migration without documentation and lost weeks of work to rebuilding from memory is significant.

The migration order

Migrate in this order:

  1. Set up the new hub completely first, including any network configuration, Thread border router setup, and basic settings.
  2. Test the new hub with one throwaway device to confirm it works. This is your sanity check.
  3. Migrate non-critical devices first: spare smart plugs, decorative lights. Get comfortable with the new hub’s pairing flow.
  4. Migrate room by room rather than category by category. This keeps each room functional throughout the migration rather than half-broken.
  5. Migrate critical safety devices last (locks, smoke detectors, security cameras) so they remain on a tested hub for the longest.
  6. Recreate automations and scenes on the new hub as each room completes.
  7. Update voice assistant and third-party integrations to point to the new hub.

Per-device flow

For each device:

  1. In the source hub’s app, exclude or remove the device. This is the unpair step that frees the device from its old network membership.
  2. Factory reset the device to clear any residual state.
  3. In the destination hub’s app, include or pair the device. This adds it to the new network.
  4. Verify the device responds in the new hub.
  5. Rename the device to match its original name (devices usually pair with generic default names).
  6. Assign the device to its room in the new hub.

Plan 5 minutes per device. Some devices (especially Z-Wave locks) take longer because of the secure inclusion process.

What can go wrong

Common pitfalls:

  • Devices that refuse exclusion: if the source hub is dead or broken, you may not be able to formally exclude. Use the destination hub’s general exclusion or factory-reset-the-device path.
  • Devices that pair but report incorrect capabilities: a device handler mismatch on the destination hub. Install a community driver or accept reduced functionality.
  • Devices that pair to the destination but appear in the wrong category: rare but happens. Some hubs misidentify devices. Check the device’s classified type in the new hub and override if necessary.
  • HomeKit accessory codes that have been used: factory reset usually generates a new pairing state, but for some HAP devices you may need to wait an hour for HomeKit to release the old pairing record.

Voice assistants and the migration

If your voice assistants connect to devices through the old hub’s integration, those connections break when devices move. You have two paths:

  1. Re-link voice assistants to the new hub through the new hub’s integration. All your devices reappear in the voice assistant under the new hub’s identifiers.
  2. Use Matter on the new hub and expose devices directly to voice assistants through Matter, bypassing hub-specific integrations.

Either way, voice routines that referenced specific devices may need to be edited to point to the new device identifiers, even if names match.

Scenes and automations

Most hubs do not support importing scenes or automations from another hub. The exceptions are tools like Home Assistant’s import wizard for some specific source hubs.

For the typical migration, plan to rebuild scenes and automations manually using your documentation. Allow another hour for this depending on complexity.

The old hub disposal

After migration, the old hub has nothing on it but may still be in your account. Delete it from the account before unplugging. For hubs you intend to recycle, factory reset before disposal to clear any residual network credentials.

For hubs in good condition, secondary market value is real. SmartThings v3 and Aeotec hubs hold value among smart home tinkerers who use them for testing.

Realistic time estimates

For 25 devices and moderate automation complexity, plan an entire weekend. The pairing itself is faster than that; the rebuild and verification are what take time.

If you have 75+ devices, plan two weekends, spread across a couple of weeks. Trying to do it all in one sitting leads to mistakes you will not catch until later.

The room-by-room approach beats the device-by-device one

Migrating one room at a time keeps the rest of your house functional while you work. You move the kitchen first: exclude every kitchen device from the old hub, include each one on the new hub, rebuild kitchen automations, test, walk away. The next day, the living room. Bedroom on the weekend.

The advantage is that you can test each migration thoroughly before moving to the next, and any household member can still use the unmigrated rooms in the meantime. For the per-device pairing details that come up during this work, our re-pairing guide has the protocol-specific steps.

Works with
HomeKitAlexaGoogle HomeSmartThingsZigbeeZ-WaveMatter

Frequently asked questions

Can I run the old and new hubs simultaneously during the migration?

Yes, and you should. Keep the old hub powered until every device is migrated and verified on the new hub. This gives you a fallback if you discover a device migrated badly.

Will my Zigbee devices interfere if both hubs are running?

If they are on different channels, no. If they are on the same channel, you may see degraded performance on both networks during the transition. Pick separated channels before starting.

Should I migrate to Matter where possible?

Yes if your destination hub supports Matter and your devices have Matter equivalents. Matter devices are easier to move in the future and have better cross-ecosystem support.

What if I cannot reset a device?

Some devices have particularly stubborn reset procedures. Check the manufacturer's manual carefully; some require multiple seconds of button hold with specific timing. As a last resort, contact the manufacturer for a force-reset procedure.

How do I migrate cameras and locks safely?

Locks need their batteries removed during the migration to prevent accidental triggers. Cameras should be unplugged and re-plugged after the migration to clear any cached cloud associations. Both should be migrated last in the per-device order.

Is there a tool that automates this?

Not for cross-hub migrations. Some tools help within an ecosystem (HomeKit Controller for HomeKit, the Z-Wave JS replace flow for Home Assistant), but the cross-hub case is too varied for automation.