Cisco Meraki MS220-48 EoL: Migrate to the MS120-48

If you still have Cisco Meraki MS220-48 switches (PID MS220-48-HW) humming away in wiring closets, they are now past every Meraki lifecycle milestone that matters. The MS220-48 reached its Last Day of Support on July 29, 2024. From that date forward Cisco provides no firmware updates, no security fixes, and no TAC support or RMA hardware replacement for this model. The switch still forwards frames, which is precisely why these units quietly survive in production long after they should have been retired. A cloud-managed switch that can no longer receive a firmware push is a uniquely awkward liability: it depends on a live connection to the Meraki dashboard, yet it can never again be patched. This guide explains what the end-of-life dates mean for an operating fleet, why the recommended MS120-48 is the right landing spot, and how to plan a clean migration on the supported Meraki switching platform.

What the MS220-48 actually was

The MS220-48 (MS220-48-HW) is a 1U Layer 2 cloud-managed access switch: 48 ports of 10/100/1000BASE-T edge connectivity plus four dedicated 1 Gigabit SFP uplink ports for fiber or DAC links back to the distribution layer. It is the non-PoE member of the MS220 family (the powered variants were the MS220-48LP and MS220-48FP). As a Layer 2 switch it handles VLANs, 802.1X access control, ACLs, QoS, and switch-port profiles, but it does not route — all inter-VLAN routing has to live upstream. Like every Meraki switch, it has no traditional CLI and no on-box configuration of record; it is provisioned and operated entirely through the Meraki dashboard, with all telemetry, topology, and packet-capture flowing to the cloud. For a high-density wiring closet in 2014, it was an elegant zero-touch access switch. The hardware that anchored it is now a decade old.

Why acting now matters

The danger of an EoL switch is not that it stops working. It is that it keeps working while the support floor disappears beneath it. For a cloud-managed device the exposures stack up in a specific way:

• No firmware or security fixes. After LDoS the MS220-48 is frozen on its final firmware build. When a new switching, dashboard-agent, or protocol-stack vulnerability is disclosed, this hardware will not receive a patched image. Any CVE that touches that code path on this model is permanent — and unlike an air-gapped legacy box, a Meraki switch is by design always reachable from the dashboard control plane.
• No TAC or RMA. A failed unit cannot be opened as a Meraki support case or swapped under warranty or contract. Your only recovery is a cold spare you bought before LDoS or a secondary-market unit of the same dead-end model — and even a replacement must be claimed against a valid license to come online.
• Audit and compliance exposure. The frameworks federal, DoD, SLED, and healthcare buyers operate under (FedRAMP, CMMC 2.0, the HIPAA Security Rule, PCI DSS 4.0, and CISA directives) expect supported, patchable infrastructure. An access switch carrying authenticated user traffic that can never be patched is a finding waiting to happen, and 'the vendor no longer ships fixes for this model' is not a defensible remediation plan.

There is also a license trap unique to the Meraki model. The MS220-48 consumes a Meraki switch license in your organization's co-termination or per-device pool. As long as the dead hardware sits in the dashboard it keeps burning license entitlement you are paying for, and that license does not silently roll over to a replacement chassis — it has to be deliberately reassigned. Retiring the hardware and rationalizing the licensing are the same project.

What each milestone means in practice

• End of Sale (2017-07-29): the last day Cisco accepted new MS220-48 orders. Everything after this date has been consuming the support tail.
• End of Software Maintenance: for cloud-managed switches Meraki does not publish a separate maintenance milestone the way IOS platforms do; firmware eligibility tracks the hardware lifecycle, so the practical software cutoff is LDoS.
• Last Day of Support / LDoS (2024-07-29): the hard stop. No firmware, no security fixes, no TAC, no RMA. From this date the switch is operating entirely at your own risk.

The recommended replacement: Meraki MS120-48

The functional successor is the Cisco Meraki MS120-48 (PID MS120-48-HW). It is the same shape of product — a 1U Layer 2 cloud-managed access switch with 48 ports of 10/100/1000BASE-T and four 1 Gigabit SFP uplinks — so it drops into the MS220-48's role without forcing a redesign of your access layer. The decisive difference is not the port count; it is that the MS120-48 is a current, fully supported platform that continues to receive firmware and security updates on the active Meraki MS firmware trains, with live TAC and RMA behind it. You are trading a decade-old frozen device for one that stays patched.

Concretely, here is what the MS120-48 brings to this product slot:

• Same access footprint, supported silicon: 48x GbE access ports + 4x 1G SFP uplinks in 1U, matching the MS220-48's port profile so existing copper drops and fiber uplinks map one-for-one in most closets.
• Layer 2 feature parity plus refinement: VLANs, voice VLAN, 802.1X and MAC-based authentication, RADIUS, port ACLs, storm control, STP/RSTP, LLDP, QoS, and Meraki switch-port profiles — the same operating model your team already knows, on firmware that is still maintained.
• Active firmware and PSIRT coverage: the MS120 line is on the supported MS firmware trains, so disclosed switching and dashboard-agent vulnerabilities get fixed images you can actually deploy. That single fact is the whole reason for the migration.
• Cloud-managed continuity: it lives in the same Meraki dashboard organization, inherits the same network template, and supports zero-touch provisioning — claim the serial, push the existing switch template, and the new unit comes up pre-configured.
• A clean upgrade path if needs grow: if you later need Layer 3 routing, multigigabit access for Wi-Fi 6/6E uplinks, or higher PoE budgets, the broader current MS catalog (MS130, MS150, MS210/225, MS250/350/355) sits one tier away on the same dashboard — but for a like-for-like Layer 2 GbE access refresh, the MS120-48 is the correct, cost-disciplined target.

A practical migration plan

1. Assess and inventory

Export your switch list from the Meraki dashboard and pull every MS220-48-HW by network, closet, and rack position. For each unit capture the bound switch template or per-switch config, the VLAN map, the uplink topology (which SFP goes where, copper vs fiber, and the optic type), and whether any ports carry 802.1X, voice VLAN, or special ACLs. Note the firmware build for the record. This inventory is also where you reconcile licensing: count how many switch licenses the MS220-48 fleet currently consumes and confirm your co-termination date.

2. Plan the license transition

Meraki switch licenses come in Enterprise and Advanced tiers; Layer 2 access switching is covered by Enterprise, which is almost certainly what an MS220-48 was running. New MS120-48 hardware needs its own license claimed against your organization, and depending on whether you are on co-termination or per-device licensing the mechanics differ. Plan to right-size license quantity and term to the new fleet rather than blindly mirroring the old count — units you are decommissioning should free their entitlement. Do not assume the old license 'moves' automatically; reassignment is a deliberate dashboard step.

3. Confirm config and feature parity

Because both switches are cloud-managed in the same dashboard, configuration parity is the easiest part of this migration — far easier than a CLI-to-CLI port. Bind the MS120-48 to the same network template the MS220-48 used and the VLANs, ACLs, and port profiles replicate automatically. Verify a short list explicitly: Layer 2 only (remember the MS220-48 did not route, so confirm your distribution/core still owns inter-VLAN routing — do not accidentally expect L3 from the MS120 either, as it is also Layer 2), 802.1X/RADIUS settings, voice VLAN assignments, STP root and priorities, and any link aggregation on the SFP uplinks.

4. Physical: rack, power, uplinks, optics

Both are 1U, so the rack slot, rail kit footprint, and power feed carry over for the non-PoE swap. Reuse your existing SFP optics and DACs where they are still in good order and supported on the MS120 — verify each transceiver against the MS120 compatibility list before assuming it transfers, particularly third-party optics. Keep the uplink fiber runs and copper drops exactly where they are; the matching port layout means most cabling does not move. If you are stepping up to a PoE MS120 variant, recheck the closet's power circuit and total PoE budget against the new switch's wattage.

5. Phased cutover

Stage the MS120-48 in the dashboard first: claim the serial, assign the template, and let it pull configuration while still on the bench. Schedule the physical swap closet-by-closet in a maintenance window — power down the MS220-48, rack the MS120-48, move uplinks then access ports, and watch the dashboard bring the new unit online with its inherited config. Validate before you leave: link status on all uplinks, client authentication on a sampled set of access ports, voice VLAN registration on a phone, and a quick spanning-tree topology check. Keep the old unit racked and cold for the window in case you need to fall back, then remove it once the closet is confirmed healthy.

6. Secure decommission

Removed MS220-48 units must be retired properly, not shelved. Remove each serial from the Meraki dashboard organization so it stops consuming license and stops appearing in your supported-asset inventory. For federal, DoD, and healthcare environments follow your media-sanitization policy (NIST SP 800-88 guidelines) for any device that held configuration or credentials, document the chain of custody, and dispose through an approved e-waste or asset-recovery channel with a certificate of destruction where required.

Procurement notes

Buy the MS120-48 — and any PoE variant or optics — through an authorized Cisco/Meraki partner so the hardware arrives with valid, claimable licensing and clean lifecycle provenance. Secondary-market Meraki gear frequently carries license-claim and entitlement problems that surface only when you try to bring it online. For public-sector buyers, confirm TAA compliance for the specific PIDs, align the purchase to your GPC thresholds or contract vehicle, and plan for lead times on both the switches and any matching optics. As an authorized partner serving federal, DoD, SLED, healthcare, and enterprise customers, uniqcli can scope the right MS120 variant, reconcile your Meraki licensing, and stage a phased closet-by-closet cutover. Browse current switching options in our catalog, see the full milestone record for this model on its EoL detail page, or review other end-of-life Cisco hardware in the EoL library. When you're ready to size the refresh, get a quote and we'll build the bill of materials — switches, optics, and right-sized licensing — around your actual closet count.