Cisco Meraki MR62 End-of-Life: Migrate to MR36 (Wi-Fi 6)

If you still have Cisco Meraki MR62 access points (PID MR62-HW) on the ceiling, the lifecycle clock has already run out. The MR62 went End of Sale on November 15, 2019, and reached its Last Day of Support on November 15, 2024. As of today it is a fully retired platform: no new firmware, no security fixes, and no Cisco TAC or RMA coverage. The good news is that the migration path is clean. The MR62 was an entry-level dual-band 802.11n cloud-managed AP, and its modern successor, the Wi-Fi 6 Meraki MR36, is a straightforward refresh that usually reuses the same mounting and cabling while delivering a generational jump in throughput, client capacity, and security.

This guide is written for the teams who actually own these decisions: US federal, DoD, and SLED operators, healthcare networks, and enterprise IT running Meraki at scale. It covers what each milestone date means for the MR62 specifically, why acting now is a security and compliance issue rather than a nice-to-have, what the MR36 concretely improves, and a practical, phased plan to migrate without surprising your help desk.

What the MR62 end-of-life dates actually mean

Cisco and Meraki lifecycle announcements use a few specific milestones, and they are not interchangeable. For the MR62 the two that matter are End of Sale and Last Day of Support, because this is a hardware platform without a separately published software-maintenance milestone.

• End of Sale (2019-11-15): the last date the MR62 could be ordered new from Cisco. Anything in service today was purchased on or before this date, which means even the youngest MR62 in your fleet is now well past five years old.
• End of Software Maintenance (n/a): the MR62 did not carry a separately published software-maintenance milestone. In practice, firmware support for the platform ended with its support lifecycle, so do not read the absence of this date as ongoing patching.
• Last Day of Support / LDoS (2024-11-15): the date all support obligations ended. After this there are no Cisco-provided bug fixes, no PSIRT security patches, no TAC cases, and no hardware RMAs for the MR62. This is the milestone that turns the AP from supported infrastructure into unsupported risk.

Why acting now is a security and compliance decision

An access point that cannot receive firmware is not a static, frozen-but-safe device. It is a known-good target that stops improving the moment everyone else's stops. Once a platform is past LDoS, any new vulnerability discovered in its firmware, its supplicant handling, its management channel, or an underlying library simply never gets patched. There is no First Fixed Release to upgrade to, because there is no longer anyone shipping releases for it. The only remediation for a post-LDoS security advisory is replacement, and the time to plan that is before an advisory forces the schedule, not after.

For regulated buyers this is also an audit and compliance exposure. Frameworks across federal (FISMA/RMF), DoD, healthcare (the HIPAA security rule), and many SLED programs expect production infrastructure to run vendor-supported, maintained software. An unsupported AP is a recurring finding that you have to write a plan of action and milestones around every cycle until it is gone. There is also a quieter operational cost: when an MR62 fails, there is no RMA, so each failure is an unplanned, full-price emergency purchase of whatever you can find. You can see the full milestone detail for this exact unit on its MR62-HW end-of-life page, and track the rest of your fleet against the same dates on our Cisco End-of-Life hub.

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

The MR36 (PID MR36-HW) is Meraki's entry-level Wi-Fi 6 indoor AP and the natural successor to the MR62. The headline difference is the standard itself. The MR62 was 802.11n, a Wi-Fi standard that predates almost every device on a modern network, with single-digit-stream rates and no modern airtime efficiency. The MR36 is 802.11ax (Wi-Fi 6), which changes the economics of a busy network, not just the peak number.

What the MR36 concretely does better

• Wi-Fi 6 (802.11ax) vs 802.11n: the MR36 is a dual-band 2x2:2 MU-MIMO radio with aggregate rates in the ~1.7 Gbps class, versus the MR62's roughly 300 Mbps-per-band 11n ceiling. The jump is generational, not incremental.
• OFDMA and improved airtime efficiency: Wi-Fi 6 lets the AP service multiple clients in a single transmission and schedule airtime far more efficiently, which is exactly what dense, mixed-client environments (clinics, classrooms, offices full of phones and laptops) need. 802.11n cannot do this.
• A dedicated third radio for security and RF: the MR36 includes a separate scanning radio that powers always-on WIDS/WIPS and Air Marshal rogue and threat detection without stealing airtime from clients, plus a dedicated Bluetooth Low Energy radio for IoT and location. The MR62 had no equivalent dedicated scanning capability.
• Modern security baseline: the MR36 supports WPA3 and Enhanced Open and is on a fully supported firmware train, so it keeps getting Meraki security and feature updates. The MR62 is frozen at its final, unpatched firmware.
• Power and uplink: the MR36 is a 1 GbE AP powered by 802.3at PoE+, where the MR62 ran on lower-power 802.3af. The uplink stays a single Gigabit drop, so existing Cat 5e/6 cabling is reused, but confirm your switch can deliver PoE+ at full port density.

Net effect: the MR36 typically supports far more concurrent clients per radio at usable throughput than an MR62, while adding the dedicated security scanning the older unit never had. For most spaces this means the same physical footprint delivers a dramatically better experience, and in some high-density rooms you can cover the area with fewer APs than the 11n design required. You can review MR36 availability and configuration options in the Meraki wireless catalog.

A practical MR62-to-MR36 migration plan

Because both platforms are cloud-managed through the same Meraki dashboard, this is one of the cleaner refreshes in the Cisco portfolio. The work is mostly in inventory, licensing, and a disciplined cutover rather than in deep reconfiguration.

1. Assessment and inventory

Pull a list of every MR62 from the dashboard, including serials, network assignment, mounting location, and the SSIDs and policies applied. Note which APs share a switch and what that switch can deliver for PoE. This inventory is both your bill of materials for the MR36 order and your cutover checklist. A light RF survey is worth the time here: Wi-Fi 6 cell behavior differs from 11n, so confirm whether you are replacing one-for-one or can consolidate.

2. License transition

Meraki APs do not function without an active license, and MR62 licensing does not transfer to MR36 hardware. Plan a license for each new MR36 on the term and tier (MR Enterprise or Advanced, depending on whether you need the advanced security and analytics features) that matches your environment. If your organization is on co-termination, line up the new license dates with your existing co-term so renewals stay synchronized; if you are on per-device licensing, claim each MR36 license against the device. Confirm this before the order so counts and renewal dates are correct on day one.

3. Config and feature parity

This is the easy part of a Meraki refresh. SSIDs, group policies, RADIUS settings, and firewall and traffic-shaping rules live in the dashboard network configuration, not on the AP, so claiming an MR36 into the same network inherits the existing wireless config. Validate WPA3 and any 802.1X/RADIUS interactions against your supplicants before broad rollout, since the MR36 supports security modes the MR62 could not, and you may choose to tighten policy as part of the move.

4. Physical: power, uplinks, and mounting

Confirm each MR36 location has 802.3at PoE+ available. A closet that only ever powered af-class MR62s may be at its PoE budget once you add PoE+ APs, which can turn an AP refresh into a switch refresh. The MR36 reuses the existing 1 GbE drop and standard Meraki mounting, so cabling and brackets typically carry over. Verify the mounting plate and any ceiling-tile hardware fit before swap day to avoid surprises on a ladder.

5. Phased cutover

Do not big-bang a wireless refresh. Claim the MR36s into the dashboard ahead of time so they download config and firmware on first boot. Swap a pilot area first, validate roaming, authentication, throughput, and any captive-portal or RADIUS flows, then expand floor by floor or building by building. Doing it in waves keeps the help desk sane and lets you re-tune channel and power per area as the new radios come online.

6. Secure decommission

Remove each retired MR62 from the dashboard so it stops counting against licensing and is de-associated from your organization, then factory reset the unit. For federal, DoD, and healthcare environments, follow your media-sanitization and asset-disposal policy and record serials for the audit trail. If the old gear is going back under a trade-in, confirm each serial is de-claimed before it ships.

Procurement notes for regulated buyers

Two things drive the procurement timeline. First, compliance: federal, DoD, and many SLED buyers need TAA-compliant hardware and Global Purchasing Compliance (GPC) sourcing, so the MR36 and its licensing should be quoted through an authorized channel with that documentation in hand, not picked up on the gray market. Second, lead time and license alignment: order the MR36 hardware, the matching per-AP license term, and any PoE+ switching together so nothing arrives stranded waiting on a license or a power upgrade.

As an authorized Cisco partner, uniqcli can confirm TAA and GPC status, line up MR36 licensing against your existing co-term, and scope the PoE budget before anything ships, so the refresh lands clean. When you are ready to size and price your MR62-to-MR36 migration, get a quote and we will build the bill of materials, licensing, and any switch or power dependencies into a single, defensible number.