Moving an old smart home onto standards, one room at a time

What "legacy" usually means in practice#

An older smart home is normally some combination of these, and each has a different upgrade argument:

• Wi-Fi devices with vendor apps and cloud accounts. Plugs, bulbs, cameras. They work, they are cloud dependent, and each one is a client competing for 2.4 GHz airtime.
• A vendor hub with its own radio. A Hue Bridge, a SmartThings hub of a certain vintage, an old Wink or Iris box, an alarm panel with a proprietary sensor line.
• A Zigbee or Z-Wave network that predates Matter. Often the most reliable part of the house.
• Devices from vendors that are gone or leaving. Belkin's Wemo line shut down on 31 January 2026, taking the app and cloud with it, and only devices already paired to Apple HomeKit before that date kept working. Google cut off the Nest Learning Thermostat 1st and 2nd generation on 25 October 2025, removing them from both apps while leaving them usable as ordinary thermostats.

The mistake is treating all four as one project. They have different urgencies, and only two of them are urgent at all.

Step one: audit before you buy anything#

Build a list. A spreadsheet is fine, and the outage audit tool will tell you what keeps working without internet once you have one. For each device record:

Then score each device on three things: does it still work, is it still supported, and is it blocking anything else. A device that fails only the first test is a maintenance issue. A device that fails the second is on a clock. A device that fails the third, usually a hub that other things depend on, is what actually sets your order.

The exit cost calculator is useful here for the other half of the question: what leaving your current platform would cost in devices you would have to rebuy.

Step two: build the new spine before you remove anything#

The most common way this project goes badly is starting with the devices. Start with the infrastructure, because until it exists there is nowhere for migrated devices to go.

The spine is four things:

1. A controller. Where automations will run. If you are also changing platforms, read switching platforms without rebuying first, because the migration order there interacts with this one. The seven platforms compared is the decision page.
2. A Thread border router, if you are going to buy any battery Matter devices. Check the specific model rather than the product line, because near-identical hardware differs: within Apple's range, only the 128 GB Wi-Fi plus Ethernet Apple TV 4K 3rd gen has a Thread radio, and the 64 GB Wi-Fi only model does not. Thread border routers has the current US hardware picture.
3. Two mains-powered relay devices per floor. Thread and Zigbee battery devices are sleepy end devices: they keep the radio off between polls and never relay for anyone. A house of battery sensors with one mains-powered device has no mesh, only spokes. Two well-placed smart plugs do more for reliability than a second hub.
4. A channel plan. Thread and Zigbee share the same IEEE 802.15.4 radio, so if you will run both, put them on different channels from each other and from your Wi-Fi. Wi-Fi channel 1 covers 802.15.4 channels 11 to 14, Wi-Fi 6 covers 16 to 19, and Wi-Fi 11 covers 21 to 24. The channel planner does the arithmetic and 2.4 GHz interference explains it.

Get all four working with one throwaway test device before you touch a room anyone uses.

Step three: the order of replacement#

Replace in this order, and stop when the remaining items stop bothering you.

1. Anything from a vendor that has already shut down or announced changes. This is the only genuinely urgent category, because the device may stop working on a date somebody else chose. Warning signs and history are in when a smart home company shuts down.
2. Single points of failure. The old hub that everything else routes through, the cloud bridge with no local mode. Not because they are broken, but because they cap what the rest of the house can do.
3. Anything on the critical daily path. Bedroom lights, the front door, the room the household uses most. These get replaced deliberately, with the old device kept in a drawer for a week in case you need to put it back.
4. Wi-Fi devices, in bulk, if you have a lot of them. There is no credible published figure for consumer router device limits, and the real constraints are DHCP pool size, the per-radio association table, NAT state and airtime. Past roughly 50 Wi-Fi IoT devices the honest answer is dedicated access points or moving devices to Zigbee, Thread or Z-Wave. Below that, this is a low priority. Wi-Fi smart devices: the hidden costs covers the mechanism.
5. Everything else, on failure. When a bulb dies, replace it with the standards-based version. This is how most of a house actually migrates, and it costs nothing extra.

Step four: run old and new in parallel#

This is what turns a weekend project into a series of evenings. There is no point at which both systems must be down.

Two controllers can coexist. They will both see your network, both run automations, and neither needs to know about the other. The only requirement is that you know which one owns which device, so keep an explicit list during the crossover.

Multi-admin lets one Matter device live on both at once. The first controller opens a commissioning window, which produces a fresh short-lived setup code that the second ecosystem uses to run the same flow against its own fabric. That means you can add a device to the new controller, test it, and only then remove it from the old one. Two limits: devices are only required to support five fabrics, and Apple Home consumes two slots because it synchronizes accessories through iCloud Keychain. Do not leave devices on four fabrics permanently. Sharing a Matter device across ecosystems has the per-platform steps.

Bridge the old world in rather than replacing it. A bridge lets legacy devices appear in the new controller while they are still physically what they were:

• A Hue Bridge exposes its lights over Matter to any controller.
• IKEA DIRIGERA became a Matter controller and border router by firmware update, and bridges most device types.
• Homey's Matter Bridge app is the broadest option available: it turns Zigbee, Z-Wave, infrared, Bluetooth, 433 MHz and cloud devices into Matter accessories for Apple Home, Google Home, Alexa, SmartThings and Home Assistant. If you have a large mixed legacy estate, that is the cleanest single on-ramp that exists. Homey Pro covers the hardware.
• Note what is not a bridge: SmartThings hubs and Home Assistant are Matter controllers, not Matter bridges. They consume Matter devices; they do not expose their own Zigbee and Z-Wave devices over Matter.

Know what a bridge takes from you before you rely on one: firmware updates for bridged sub-devices are never available over Matter, vendor scenes do not cross because no consumer controller implements the Actions cluster, and endpoint numbers are not reused, so a re-paired bridged device reappears as a brand new accessory with its automations gone. Matter bridges and what you lose through one is the full list, and hubs, bridges, controllers and border routers sorts out the words.

Keep voice working throughout. Leave both account links in place until the last device moves, but rename the old entries as you go. Two devices called "Kitchen Ceiling" in one assistant produces ambiguity, and the assistant resolves it in whichever way is least useful. Prefix the outgoing one with "Old" the moment its replacement is paired. Naming and room structure that survives 100 devices covers why this matters more than it sounds.

Do not accidentally build a second Thread network. Every ecosystem forms its own Thread network by default, so adding a new controller during a migration is exactly when fragmentation happens. Thread 1.4 credential sharing exists, but it is user triggered, single use and time limited, not automatic merging. Why you have three Thread networks has the per-ecosystem steps.

Step five: what to keep#

Not everything should be replaced, and the pressure to standardize on Matter is not a good enough reason on its own.

Keep it if all four are true: it works, it works locally, nothing else depends on the vendor's cloud to use it, and replacing it costs more than the annoyance it causes.

Specific categories that usually pass that test:

• A working Zigbee or Z-Wave network. Both are local, mature and reliable. Z-Wave in particular is not standing still: Z-Wave Long Range reached 125 certified devices by CES 2026, with around 80 percent of the certification pipeline targeting Long Range. There is no reason to rip out a functioning Z-Wave lock to make it Matter. Zigbee and Z-Wave and Z-Wave Long Range cover both.
• Proprietary radios that were chosen for a reason. Lutron's Caseta line is the standing example: a closed radio, but local, reliable, and with no-neutral options that matter in older US houses. Proprietary radios: Lutron, Hue, Tuya and friends covers when closed is the right call.
• Anything hardwired that works. Replacing a functioning in-wall switch means an electrical job and a hole in your evening. Wait for it to fail.
• Devices whose replacement does not exist yet. Several categories still have no Matter device type at all, including security and alarm panels, keypads, sirens, and multi-room and streaming audio. Waiting is the correct move there. What Matter still cannot do is the current gap list.

Replace it regardless if: the vendor has shut down or announced a shutdown, the app has been discontinued, or the device only works through a cloud service you cannot verify. Those are on somebody else's timeline, not yours.

A realistic schedule#

Migrating a room means: pair the new devices, assign the room, test by voice and by app, rename the outgoing devices with an "Old" prefix, live with it for a day, then remove the old ones and factory reset them.

Failure modes to expect#

• The half-migrated room. Two lights on the new controller, one still on the old, and an automation that only reaches two of them. Finish a room before starting the next one, always.
• Orphaned fabrics. Removing a device in a controller's interface does not reliably send the remove-fabric command, and devices may support only five fabrics. Devices that have been added and removed several times during a migration can start failing to pair, and the failure is badly signaled: pairing appears to progress and then fails at the credential step. A factory reset clears the fabric table. Home Assistant is the rare controller that exposes a manage-fabrics interface for repairing this without a reset.
• Voice ambiguity. Two devices with similar names in one assistant. Prevented by renaming as you go.
• Automations pointing at removed devices. They usually fail silently rather than erroring. Rebuild automations after the devices are settled, not during.
• Household revolt. Caused by migrating the bedroom on a Tuesday night. See the warning above.

Before buying anything to replace anything, run it past the pre-purchase checklist, and check the specific device class and platform combination in the compatibility checker.