Cutting over from mesh Wi-Fi to a managed network, live

Project 1 built the services: HA DNS, recursive resolution, monitoring, Proxmox. They ran on a flat network with a Deco mesh doing routing, DHCP, and Wi-Fi all at once.

Project 2, Phase 1, moves routing and DHCP onto dedicated gear: a TP-Link ER605 and a managed PoE switch under an Omada controller, with the Deco dropped to access-point mode. A live cutover, with a house full of clients and a DNS stack that everything depends on.

The target

ONT -> AT&T Gateway (IP Passthrough)
     -> ER605                 router / firewall / DHCP
     -> TL-SG2210P            managed PoE switch
        - Deco APs            AP mode only, Wi-Fi, no routing
        - Proxmox host
        - ashpi-1 / ashpi-2   HA DNS nodes (PoE)
        - clients

The hardware isn’t the point. Separating roles that a mesh collapses together is. The ER605 routes and hands out DHCP. The switch does L2 and powers the Pis over PoE. The Deco just does radio. That separation is what makes VLAN segmentation possible later, and this phase is the foundation it sits on.

Doing it without dropping DNS

What made this safe was that the DNS layer was already resilient. Pi-hole HA with a Keepalived VIP means clients point at one address (192.168.68.20) regardless of which node answers. As long as the new network kept that VIP reachable and kept handing it out as the DNS server, clients wouldn’t notice.

So the plan was ordered around validation, not speed:

ER605 online on the WAN, LAN configured on the existing subnet.
Managed switch adopted into Omada, port map confirmed.
Deco to AP mode.
Move DHCP authority to the ER605, same subnet, same DNS server handed out (the VIP).
Validate every dependent service before calling it done.

ER605 system status: WAN link up, dynamic IP, running as the
router

ER605 LAN and DHCP configuration: 192.168.68.0/24, DHCP server enabled,
handing out the Pi-hole VIP as DNS

The TL-SG2210P adopted and online in the Omada controller

Omada switch panel: ports 3 and 4 delivering PoE, 5.5W of 61W used,
powering the two Pi-hole nodes

Validation, the actual work

A cutover isn’t done when traffic flows. It’s done when you’ve proven the things that depend on it still work. After DHCP moved:

A client leases from the ER605:

Windows ipconfig /all: IPv4 lease with DHCP Server 192.168.68.1, the
ER605, not the old Deco

DNS still resolves through the Pi-hole VIP:

nslookup from a client: Server pi.hole, resolving google.com, so the
HA DNS VIP is still the resolution path after the
cutover

Then, one by one: the HA DNS VIP reachable, Pi-hole still logging queries, Proxmox reachable, Grafana loading, the Omada controller itself, RustDesk. Every service from Project 1, confirmed up on the new network.

Omada topology after the cutover: WAN to ER605 to managed switch to the
Pi-hole nodes, Deco APs, and clients

What the managed stack buys

Beyond being a prerequisite for VLANs, the visibility changed day-to-day. The mesh app showed “devices.” Omada shows the router’s WAN state, the switch port map, which port powers what, PoE draw, and per-client connection detail. Those are the things you need when something’s wrong and you’re trying to find where.

Closing note

A few things I’d carry forward. Build on the resilient layer: the HA DNS VIP is what made a live DHCP cutover a non-event, because clients kept pointing at one address that kept answering. Keep the subnet the same and change one variable at a time, in this case who’s authoritative for routing and DHCP, not three at once. AP mode is the right bridge; it keeps the mesh’s coverage and drops its routing so the ER605 can take over cleanly. And validation is the deliverable. “It works” is a screenshot of every dependent service, not a ping.