CASE STUDY · ARCHITECTURE

MERAKI TO CATALYST 9800

Re-architected global enterprise wireless from cloud-managed Meraki to sixteen Catalyst 9800 controllers, then cut over 900 APs site by site.

~900
APs cut over
16
Controllers
4
Regional datacenters
190
WLANs

The problem

Enterprise wireless ran on cloud-managed Meraki, roughly 900 APs across a global footprint, and the platform decision was to move it all to Cisco Catalyst 9800 controllers. That is two problems wearing one project name. The first is architecture: where the controllers live, how they fail, and what guests are allowed to touch. The second is execution, and the catch there is physics: two wireless platforms broadcasting in the same buildings create interference, so a long, comfortable parallel run was off the table. Each site had to cut once and hold.

My role

I re-architected the wireless platform, designed the cutover method, and carried the migration from design through site-by-site execution. The controller layout, the guest policy, and the cutover sequence below were my decisions, and I stood behind them in the windows.

The approach

The controller design is sixteen Catalyst 9800s across four regional datacenters. Each colo runs an identical N+1 set: an HA pair for internal WLANs, a standalone controller carrying an identical configuration as the failure and maintenance spare, and a dedicated guest anchor controller in the DMZ, reached over mobility tunnels. The spare is not idle insurance. Because its configuration matches the pair exactly, losing a controller or taking one down for maintenance becomes an AP re-join, not an engineering event.

One rule was hard: APs join controllers in their own region. CAPWAP from India or the Philippines back to controllers in the US stresses tunnel design and invites problems, so the architecture never allows it.

APs were mapped one to one against the Meraki fleet, with counts increased where density earned it, not everywhere by default.

Guest traffic terminates on the DMZ anchor under a strict policy: all RFC1918 denied except the ISE nodes, DNS, and DHCP. Internet access is restricted to ports 80 and 443 plus VPN services, because visiting guests legitimately need to reach their own companies’ VPNs. The deny list is the design. A guest device can reach exactly what it needs to authenticate, resolve names, and get an address, and nothing else inside the network.

What shipped

Every site was fully pre-staged with the 9800 radios off. The window itself was a tight sequence: cut PoE to the Meraki APs, enable the 9800 radios, verify the SSIDs are broadcasting, test authentication, and watch the flows land in ISE. Corporate wireless moved site by site. Client-specific SSIDs moved per site and per program, so each program’s cutover could be scheduled and verified on its own terms.

The posture was fix-forward, since the old side had to go dark for the new side to breathe. Re-powering the Meraki APs was held as the break-glass option, and it stayed unused.

Where it stands

Roughly 900 APs now run against the sixteen-controller architecture, carrying 190 WLANs worldwide. Post-deployment tuning was treated as designed work rather than ticket triage: idle timers reworked after lunch breaks turned locked screens into logoffs, RRM adjusted per building, band steering set per site. The N+1 spare in each colo means maintenance windows on a controller no longer belong on anyone’s risk register.