Cisco Meraki MR32 EoL: Migrate to MR36 Wi-Fi 6 Guide

The MR32 is past Last Day of Support: why this matters now

If you are still running Cisco Meraki MR32 access points (PID MR32-HW), the clock has already run out. The platform reached its Last Day of Support (LDoS) on March 31, 2024, more than two years ago. The APs may still light up in your Meraki dashboard and pass traffic, but Cisco no longer ships security firmware fixes, provides TAC engineering support, or honors RMA hardware replacement for the model. In practical terms, every MR32 on your floor is now a frozen, unpatchable device sitting at the edge of your network where users and guests connect.

For regulated buyers this is not a soft deadline. Federal and DoD environments operating under RMF, FedRAMP-adjacent controls, or DISA STIG guidance, healthcare networks under HIPAA, and SLED organizations under state security frameworks all share the same expectation: edge infrastructure must be vendor-supported and receiving security updates. An access point that can no longer take a PSIRT patch is a documented audit finding waiting to happen. Cyber-insurance carriers increasingly ask the same question. Acting now converts an open exposure into a planned, defensible refresh.

What each milestone date actually means

• End of Sale (March 31, 2018): the last date Cisco/Meraki sold a new MR32 through authorized channels. After this you could only source units on the secondary market.
• End of Software Maintenance (n/a for this platform): Meraki firmware is delivered as a cloud-managed train rather than per-model maintenance releases, so the MR32 did not carry a separate SW maintenance milestone. The functional cutoff for security fixes is LDoS.
• Last Day of Support / LDoS (March 31, 2024): the hard line. No TAC cases, no RMA, no new security firmware. This is the date that matters for audit and risk posture, and it has already passed.

The replacement: Cisco Meraki MR36 (MR36-HW)

Cisco's mainstream successor for the MR32's office-density role is the Wi-Fi 6 Meraki MR36. It keeps the same 2x2:2 design philosophy and the same cloud-first management model, so it slots into existing mounting and cabling with minimal disruption while bringing the air interface forward a full generation. For spaces where the MR32 was already saturated, Cisco positions a 4x4 platform or the Catalyst Wireless CW9164I for higher-density and Wi-Fi 6E coverage.

Concretely, what the MR36 does better

• Wi-Fi generation: MR32 is 802.11ac Wave 1 (5 GHz 802.11ac plus a 2.4 GHz 802.11n radio). MR36 is 802.11ax (Wi-Fi 6) on both bands. Both are 2x2:2, but the MR36 modulates to 1024-QAM and supports longer OFDM symbols for better range and efficiency.
• OFDMA: the headline upgrade. The MR32 has no OFDMA; every client gets the whole channel for its turn. The MR36 subdivides each channel into resource units, so it can service many small-frame clients (VoIP, barcode scanners, badge readers, IoT) in a single transmission. In high client-count rooms this slashes latency and contention far more than the raw rate increase suggests.
• Throughput: aggregate climbs from roughly 1.2 Gbps on the MR32 to about 1.5 Gbps on the MR36, with up to 1201 Mbps on 5 GHz and 286 Mbps on 2.4 GHz.
• Dedicated security radio: both carry a third radio for 24x7 WIDS/WIPS and automated RF optimization, and both include an integrated Bluetooth Low Energy radio for beaconing and scanning, so you keep the air-monitoring and location features you relied on.
• Client capacity and battery life: Wi-Fi 6 features such as target wake time (TWT) and OFDMA scheduling let the MR36 hold more concurrent clients comfortably and extend battery life on mobile and IoT endpoints.
• Power: both are IEEE 802.3af PoE class devices; the MR36 draws up to ~15W. Existing 802.3af switch ports and injectors that powered MR32s will generally power MR36s, so you typically do not need to re-cable or upgrade PoE budget for a like-for-like swap.

A practical migration plan

1. Assessment and inventory

Export your MR32 list from the dashboard with serials, network assignment, firmware, and mount locations. Pull per-AP client counts and channel utilization for a representative busy week. APs that consistently run hot are candidates to upgrade to a 4x4 or CW9164I rather than a 1:1 MR36 swap. Confirm each switch port's PoE class and uplink speed while you are at it. Your full device list and dates also live on the MR32 end-of-life page.

2. License transition

Meraki licenses do not migrate between models, so budget a new Enterprise or Advanced license per MR36. Decide between per-device and co-termination licensing and align the term with the rest of your Meraki estate so you renew everything on one date. Get the license counts and term modeled before the hardware PO so nothing arrives unlicensed.

3. Configuration and feature parity

Because the MR36 joins the same dashboard organization, most configuration is inherited from the network it is added to. Validate that your RF profiles make sense for Wi-Fi 6 (revisit minimum bitrate, band steering, and channel width now that OFDMA changes airtime behavior), confirm SSID and group-policy mappings, and verify any location or BLE-beacon use cases still behave on the new BLE radio.

4. Physical: mounts, power, uplinks, cabling

The MR36 reuses standard Meraki ceiling and wall brackets, so existing mounts usually accept the new AP. Confirm the switch port delivers at least 802.3af and that your Cat 5e/6 uplink is healthy. For sites where you are also upgrading the density tier, verify the access switch can supply higher PoE and, ideally, mGig uplinks so the AP is not bottlenecked at 1 Gbps.

5. Phased cutover

Run MR32 and MR36 side by side. Swap one floor, wing, or building at a time, validate roaming and client experience, then move to the next zone. Mixed operation is fully supported in the same network, so you avoid a single high-risk cutover window and can roll back a zone instantly if needed.

6. Secure decommission

Once a zone is fully on Wi-Fi 6, remove the MR32s from the dashboard, factory-reset each unit to clear config and any cached credentials, and dispose through an asset-recovery process that meets your data-handling and (for federal) property-disposal rules. Keep a record of serials retired for your audit trail.

Procurement notes for regulated buyers

Source MR36 units through an authorized partner to guarantee genuine hardware, valid licensing, and a clean warranty/support chain; secondary-market or gray-market APs can carry transfer and licensing problems. For federal buyers, confirm TAA compliance and country of origin, and align the buy to your GPC thresholds or contract vehicle. Lead times on Meraki hardware fluctuate, so place orders with buffer if you are tied to a fiscal-year deadline. Browse current models and configurations in our catalog, and review related milestones across the portfolio on the Cisco EoL hub.