Meraki MR33 End of Life: Migrating to the Wi-Fi 6 MR36

The Cisco Meraki MR33 (PID MR33-HW) was one of the most widely deployed entry-class cloud-managed access points of its generation — an 802.11ac Wave 2, 2x2:2 dual-band unit that found its way into branch offices, classrooms, clinic exam rooms, and retail back-of-house by the thousands. Its lifecycle is now closing. Cisco set End of Sale on May 7, 2021, and the Last Day of Support (LDoS) is July 21, 2026. If you still have MR33s in production, the window to plan a clean, funded refresh is measured in months, not years. The direct successor is the Wi-Fi 6 Meraki MR36 (PID MR36-HW), and this guide explains why the move matters and how to execute it.

What the MR33 end-of-life milestones actually mean

Lifecycle bulletins use precise terms that carry real operational and contractual weight. Here is how each applies to the MR33.

End of Sale: May 7, 2021

Cisco stopped selling new MR33-HW units through normal channels on this date. Any 'new' MR33 you encounter now is old channel inventory or used/refurbished gear. More importantly, the EoS date is the clock that all downstream milestones are measured from — it is why LDoS lands in mid-2026.

Last Day of Support (LDoS): July 21, 2026

This is the hard cutoff and the date that should drive your project plan. After July 21, 2026, Cisco Meraki provides no TAC support, no RMA hardware replacement, and no further firmware or security maintenance for the MR33. Because Meraki is a cloud-managed platform, this last point is sharper than it is for on-prem gear: the dashboard will eventually stop shipping new firmware features and PSIRT fixes to the MR33 hardware class, and an unsupported AP that fails in the field cannot be RMA'd — it is simply down until you replace it.

Why acting before LDoS matters

For regulated buyers — federal and DoD, SLED, and healthcare — running hardware past its Last Day of Support is not just a reliability question, it is a compliance and audit-exposure question.

• No more security patches: once firmware maintenance ends, any newly discovered Wi-Fi or platform vulnerability on the MR33 stays unpatched. For environments under FISMA, FedRAMP, HIPAA, or PCI-DSS, an unsupported, unpatchable device on the network is a documented finding waiting to happen.
• No TAC or RMA: a failed MR33 after LDoS means an unplanned coverage gap with no vendor recourse. You are self-insuring on cold spares of a product nobody sells new anymore.
• Cloud-platform drift: as the Meraki dashboard and newer firmware trains move forward, legacy hardware classes lose access to new features and, eventually, to the firmware versions that pair with current dashboard capabilities.
• Audit and accreditation: atOs (Authority to Operate) renewals and SLED security reviews increasingly flag past-LDoS network gear. Refreshing ahead of the date keeps your hardware inventory clean.

The recommended replacement: Meraki MR36 (Wi-Fi 6)

The MR36-HW is the intended one-for-one successor to the MR33, and Cisco designed it to drop into the same physical and power footprint. That makes it an unusually low-friction refresh — but the performance jump under the hood is significant.

Same footprint, same power budget

Both APs are 2x2:2 dual-radio units with a single 1G (10/100/1000BASE-T RJ45) uplink, and both run inside an 802.3af / 15W PoE budget — about 15W max. That means in most deployments your existing Cat 5e/6 cabling, your existing 802.3af switch ports, and your existing ceiling mounts carry straight over. You generally do not need new switches or a PoE upgrade to move from MR33 to MR36, which keeps the project scope tight and the budget predictable.

What is concretely better

• Wi-Fi 6 (802.11ax) vs. Wi-Fi 5 Wave 2: the MR36 moves to 802.11ax, lifting peak 5 GHz PHY rate to roughly 1,201 Mbps on a 2x2 radio versus the MR33's Wave 2 ceiling.
• OFDMA and MU-MIMO: 802.11ax OFDMA lets the MR36 subdivide a channel and service many small-frame clients in the same airtime slot — exactly the IoT-heavy, high-density profile (clinics, classrooms, conference rooms) where MR33s struggle. The MR33's Wave 2 silicon cannot do this.
• BSS Coloring and Target Wake Time: reduced co-channel interference in dense AP layouts, plus battery savings for IoT and mobile clients — real gains in DoD and healthcare environments saturated with handhelds and sensors.
• Dedicated third security radio: the MR36 carries a separate 24x7 WIDS/WIPS and RF-analytics radio, so air monitoring and rogue detection no longer steal airtime from client serving — a meaningful posture upgrade for security-conscious buyers.
• Integrated BLE/IoT radio: a fourth, built-in Bluetooth Low Energy radio supports beaconing and asset tracking natively, enabling location and IoT use cases the MR33 cannot.
• Higher effective client capacity: the combination of Wi-Fi 6 efficiency and OFDMA pushes practical, comfortable client counts toward ~100 per AP versus the ~50-device sweet spot of the MR33.

Licensing follows the standard Meraki model: the MR36 needs a per-AP Meraki Enterprise (or Advanced) cloud license for the term you choose. Plan the license alongside the hardware so the new APs come online in the dashboard without a coverage gap.

A practical migration plan

1. Assessment and inventory

Pull an exact MR33 count and per-site placement from the Meraki dashboard — it already knows every serial, model, and network. Note any sites where MR33s sit on 802.3af-only switch ports (good news: the MR36 is fine there) and any PoE injectors in play. Capture current SSID, RF profile, and group-policy configuration per network.

2. License transition

Confirm remaining Meraki license term and decide whether to co-term new MR36 licenses to your existing renewal date or start fresh. Order MR36 licenses to match the hardware quantity and term. Do this early — license posture is the most common cause of cutover-day surprises.

3. Config and feature parity

Because both APs live in the same Meraki dashboard, SSIDs, access control, group policies, and most RF settings carry forward when you add MR36s to the same network. Review RF profiles to take advantage of Wi-Fi 6 features (enable OFDMA-friendly settings, revisit channel width and minimum bitrates now that the airtime budget is healthier).

4. Physical, power, and uplink check

Verify each drop is 802.3af-capable (it almost certainly is if it ran an MR33), confirm Cat 5e/6 cabling, and reuse existing mount brackets where the form factor matches. The single 1G uplink is unchanged, so no optics or switch-uplink rework is required for a like-for-like swap.

5. Phased cutover

Stage MR36s in the dashboard, then swap site by site or floor by floor during maintenance windows. Because the dashboard treats both as Meraki APs, you can run mixed MR33/MR36 coverage during the transition with no client disruption, then retire MR33s as each zone is validated.

6. Secure decommission

Remove retired MR33s from the dashboard, factory-reset units before disposal, and for federal/DoD follow your media-sanitization and property-disposal process (NIST 800-88 guidelines, GPC/asset records updated). Document the swap in your hardware inventory to close the audit loop.

Procurement notes for regulated buyers

Lead times on Wi-Fi 6 APs can move with demand cycles, so order ahead of your cutover windows rather than at LDoS. For federal and SLED, confirm TAA compliance and country-of-origin documentation, align purchases with GPC thresholds and contract vehicles, and buy through an authorized Cisco/Meraki partner so warranty, licensing registration, and support entitlement attach cleanly. As an authorized partner, uniqcli can validate your dashboard inventory, scope the exact MR36 and license quantities, and confirm TAA paperwork before you commit.

Review the full lifecycle record for this product on our MR33-HW end-of-life page, browse all current Cisco end-of-life notices, or check live MR36 availability in our catalog.