New network hardware, validated on a bench before it touches production

In July, the lab’s network core was an ER605 router with a managed TP-Link switch under Omada, Deco units in AP mode, and Pi-hole HA DNS behind a VIP. It worked, it had been stable, and it was also the ceiling. The next step on the roadmap was a UniFi core.

The gear for that arrived: a UniFi Dream Machine Pro and a UniFi Standard 24 PoE switch (USW-24-PoE). A router and controller in one box, and a 24-port PoE switch to eventually replace the TL-SG2210P.

The tempting move is to rack it and cut over. The problem is what rides on the flat network: DHCP, and the DNS VIP that every client points at. A new router that comes up wanting to own DHCP, or a switch in an unknown state, plugged into the production LAN is an outage looking for a time to happen.

So part one of the UniFi story was deliberately boring: touch nothing in production, and validate everything on a bench first. This is that work. The cutover came later, on 2026-09-27, and it is part two.

Isolation first, on purpose

The bench was a closed chain: the Mac mini into one port on the UDM Pro, a single uplink from the UDM Pro to the USW, and the UDM Pro’s WAN port empty. The cables were traced port by port to confirm there was no path anywhere near the ER605, the production switch, the Deco mesh, or the AT&T gateway.

Isolation had a second layer: addressing. The bench used a different private subnet from production. A different subnet means even a mistake has nothing to collide with. The Pi-hole VIP can’t be stomped by a device that isn’t on its subnet at all.

Both units had already been factory reset and brought up on that bench: powered on, managed over Ethernet from the Mac mini, logged into locally. No cloud account was needed for any of it.

Intake

Confirmed off the chassis labels: the exact models (UDM-Pro, USW-24-PoE), the reset control on each device, all 24 copper ports, and which ports are PoE-capable. Ownership was checked too: both devices sit under a local-owner context with no unknown prior owner still associated with either.

And the honest residuals, kept explicit: chassis condition inspection, accessory inventory, rack fit, ventilation, and the supporting-hardware and cable inventory were not done. They’re deferred to rack integration, not quietly marked complete. None of this claims physical deployment readiness.

The baseline

What got tested, in order:

A pre-adoption backup, before anything else. Before adopting the switch, a backup was created and downloaded locally. First action on new gear: make sure you can get back to a known state.
Adoption and provisioning. The USW was adopted by the UniFi Network application built into the UDM Pro. That’s also the controller decision: no separate self-hosted controller; the UDM Pro runs it. Pending adoption, to provisioning, to managed, and reachable at its post-adoption bench address.
Version inventory. What’s installed on each device, recorded as the baseline to compare against later. The numbers stay in the private notes; the point is that the baseline exists.
Ports and PoE. All 24 copper ports verified for link presence, and two of them exercised for real with Raspberry Pi units powered over PoE and passing traffic. This round was actually more thorough than the equivalent checks the current Omada gear got when it went in.
Reboots and persistence. The USW rebooted and reconnected to the UDM Pro without needing re-adoption. The UDM Pro rebooted and the USW came back still adopted, the Network application recovered, and the configuration and management address survived both reboots.
A real restore, not just a backup. After validation, a backup restore was actually performed on the UDM Pro. The device came back on its backed-up configuration and stayed functional. Then a fresh post-validation backup was taken.
Health. No abnormal heat, normal fan and display behavior on both devices, no warnings.

Two caveats are kept on the record rather than smoothed over. Traffic was verified on representative ports only, and link-speed negotiation wasn’t tested at all, because the bench had no way to exercise it. And the USW’s own restore path wasn’t separately walked; the UDM Pro restore was accepted as evidence for the UniFi OS mechanism they share. The same goes for SFP/SFP+ ports, which stayed functionally unverified because there were no transceivers or fiber on hand. If any of that becomes load-bearing later, it gets tested before then, not assumed from this pass.

Production never knew

Then the item-by-item confirmation that production was untouched: the ER605 still the gateway, the Omada switch still the production switch, Deco still in AP mode, the subnet unchanged, DHCP, DNS, routing, and firewall unchanged, no rack cabling moved, no production address assigned to either UniFi device, and no outage. Neither device ever left the bench.

What the bench bought

When the cutover happens, the unknowns are already spent. Adoption behavior, persistence across reboots, the port map, and a recovery path that’s been walked rather than read about: those are the things that otherwise get discovered mid-cutover, with the house offline. Finding them on a bench costs an afternoon. Finding them during a cutover costs the DNS the whole network depends on.

Also written down, and deliberately not done on the bench: the addressing plan. The UDM Pro would take over the gateway address, verified from the ER605’s actual configuration before assignment, not assumed. The USW would take over the old switch’s management address. Neither device would get the Pi-hole VIP. And the rule over all of it: no production address goes on a replacement while the device it replaces is still connected. The cutover carried that plan out, one device at a time.

That’s the boundary of this phase. The bench work satisfied the intake dependency, nothing more. The migration itself needed its own authorization, which came on 2026-09-22, and its own plan and validation. Part two has those.