Direct answer: what should replace a Cisco ASR 900 Series router?

Why the 2026 Cisco lifecycle announcement matters to UAE buyers

Cisco announced end-of-sale and end-of-life milestones for the Cisco ASR 900 on 31 March 2026. The last day to order the affected hardware through Cisco point-of-sale mechanisms is 31 March 2027, and the listed last ship date is 30 June 2027. Cisco also states an end of software maintenance releases milestone of 30 March 2027, aligned in the bulletin to the Cisco IOS XE 17.15.x lifecycle, an end of vulnerability and security support milestone of 30 September 2028, an end of new service attachment milestone of 30 March 2028, an end of service contract renewal milestone of 29 June 2031 and a last date of support of 31 March 2032. The ASR 920 announcement published at the same time uses the same principal dates.

These dates do not mean every installed router must be switched off immediately. They mean the planning window is now measurable. A network with current service coverage may still have years of entitled support, but the commercial and engineering choices become narrower as ordering closes and as software and security milestones pass. Organizations that wait until a service renewal fails, a spare becomes difficult to source, or a feature change requires unsupported software tend to migrate under time pressure. A planned migration is usually safer because it allows the replacement design to be tested against existing MPLS, QoS, timing, multicast, access and management behavior before a production cutover.

The practical UAE decision is therefore not simply whether an ASR 900 router is still functioning. The question is whether the installed network can reach its required operating horizon, support policy, cybersecurity standard and capacity target without depending on an aging platform. A router serving a low-risk lab role may have a different replacement priority from the same model carrying mobile backhaul, critical WAN aggregation or regulated services. Treat lifecycle dates as planning boundaries, then set an internal replacement date based on business impact and migration complexity.

What the ASR 900 platform may be doing in your network

Cisco positioned the modular ASR 900 family as a compact aggregation platform for converged mobile, residential and business services. The ASR 902, ASR 903, ASR 907 and ASR 914 were designed around modular chassis, route switch processors and interface modules, with use cases that include carrier Ethernet aggregation, broadband aggregation and mobile pre-aggregation. The platform can support Layer 2 and Layer 3 VPN services, MPLS transport, multicast and granular quality of service. In mobile and synchronization-sensitive environments, deployments may also rely on functions associated with IEEE 1588, Synchronous Ethernet, BITS, 10 MHz, 1PPS or Time of Day signals.

That history explains why replacement can be deceptively complex. An inventory spreadsheet showing only “ASR-903” does not reveal whether the router is providing simple routed Ethernet, terminating dozens of pseudowires, carrying L2VPN or L3VPN services, acting as a timing boundary in the transport network, using T1/E1 or other legacy interfaces, or supporting a carefully tuned hierarchical QoS policy. Two sites with the same chassis can require completely different successors because the value is in the installed service mix, not the faceplate.

A replacement project should therefore document what the router does before selecting what replaces it. Capture active ports, media types, optics, breakout behavior, subinterfaces, VLAN ranges, routing protocols, MPLS labels and services, VPN instances, multicast roles, QoS policy maps, access control, telemetry, SNMP or streaming monitoring, timing sources, redundancy behavior, MTU settings, link aggregation, failure-detection mechanisms and any scripts or orchestration that assume IOS XE syntax. This service inventory becomes the acceptance checklist for the new platform.

Cisco-listed migration paths for ASR-902, ASR-903, ASR-907 and ASR-914

Cisco’s 2026 bulletin is unusually important because it does not provide a direct replacement for many individual ASR 900 interface modules and route switch processor part numbers. That means a chassis migration cannot safely be built by translating every old part number into a new part number. The design has to be rebuilt around required functions. For example, a site using only Ethernet uplinks and standard MPLS services may be comparatively straightforward, while a site using legacy TDM, E&M, serial, specialized timing or older optical formats may require service conversion, external equipment or a phased retirement of the legacy interface itself.

Cisco 8404 as an ASR 900 migration candidate

Cisco NCS 560 as an ASR 900 migration candidate

Cisco also lists N560-4-SYS, N560-4-SYS-E, N560-7-SYS and N560-7-SYS-E as migration product part numbers for ASR-902, ASR-903, ASR-907 and ASR-914 chassis. The NCS 560 family is an aggregation routing platform that runs Cisco IOS XR. Cisco documentation for current NCS 560 releases includes L2VPN, L3VPN, MPLS, routing, telemetry, programmability, synchronization and segment-routing configuration guides, making the family relevant to service-provider and high-scale aggregation roles where the ASR 900 historically operated.

There is also a practical hardware relationship worth examining during migration. Cisco documentation for NCS 560 interface modules lists specific modules such as A900-IMA-8Z and A900-IMA-8CS1Z for NCS 560 use under IOS XR, while the broader ASR 900 end-of-life bulletin states that many individual ASR 900 modules have no migration product. Those statements are not contradictory: support depends on the exact module part number, hardware generation, chassis, RSP and software release. The only safe method is to check each installed module against the target NCS 560 hardware and software compatibility documentation rather than assuming that an “A900” label guarantees reuse.

An NCS 560 path can be attractive where operators want a carrier-oriented IOS XR platform, modular aggregation, high-speed Ethernet growth and modern routing or segment-routing capabilities. It can also reduce the conceptual distance from an ASR 900 deployment that already uses service-provider constructs such as MPLS L2VPN, L3VPN, pseudowires and precision timing. However, feature names and workflows still change, and the migration should be tested as a platform transition. Configuration conversion, license entitlements, routing policy behavior, QoS syntax, interface naming, timing commands, telemetry and operational procedures all need deliberate validation.

Sizing between NCS 560-4 and NCS 560-7 variants should be based on actual slot demand, port density, required redundancy, forwarding capacity, expected growth and the exact route processor generation. A smaller chassis can be more efficient for a compact POP, while a larger chassis may simplify consolidation where multiple ASR 900 systems are being collapsed. The objective is not to recreate every old physical slot but to design the least complex target that carries the required services with acceptable headroom.

ASR 920 replacement needs its own model-level review

The ASR 920 is often discussed alongside the modular ASR 900 family because it serves related aggregation and access roles, but it has its own end-of-life bulletin and a different fixed-platform architecture. Cisco’s April 2026 ASR 920 notice places the last day to order affected hardware on 31 March 2027 and the last date of support on 31 March 2032. A replacement exercise should therefore identify the exact ASR 920 SKU rather than grouping every unit under a generic “ASR 900” label.

Fixed ASR 920 models can be deployed at access, aggregation or mobile backhaul locations where physical depth, power input, port mix, temperature, timing and service scale are tightly matched to a site. Replacing that function with a larger modular chassis may be technically possible but commercially inefficient; conversely, replacing it with an undersized fixed router may reduce capacity or resilience. The right shortlist depends on how many Ethernet ports are active, whether copper and fiber are both required, uplink speeds, synchronization, MPLS features, service count, rack constraints and power architecture.

For mixed estates, FourTeck recommends separating the project into site archetypes. One archetype may cover simple branch or enterprise aggregation, another may cover provider Ethernet, another may cover mobile timing, and another may cover sites carrying legacy service interfaces. This makes the replacement BOM repeatable without pretending that every ASR 920 location is identical. It also helps procurement buy common spares and optics for groups of genuinely similar sites.

The biggest replacement risk: interfaces that do not have a direct successor

The ASR 900 family supported an unusually broad set of access and transport interfaces over its life. Cisco’s end-of-life bulletin lists many affected modules for 1GE, 10GE and 40GE Ethernet as well as T1/E1, DS3/E3, E&M, serial and mixed-service applications. For many of those exact affected part numbers, the bulletin says there is currently no migration product available. That is the signal to redesign the service edge rather than search endlessly for a like-for-like card.

Ethernet migrations are usually the most straightforward, but even there the connector and optic details matter. An old port may use XFP where the new design expects SFP+, a 1G service may be delivered over a specific single-mode wavelength, a 10G connection may depend on an existing patch panel, or a C-SFP arrangement may provide two 1G channels through a physical port strategy that should not be assumed on a new platform. Record the transceiver part number, fiber type, wavelength, reach, connector type and whether the optic is Cisco-supported on the target release. Do not budget only for the chassis and discover during staging that the optics cannot move.

Legacy TDM and serial services require a more architectural decision. If the business still needs T1/E1, DS3/E3, serial or E&M connectivity, determine whether those circuits can be retired, converted to Ethernet, handed off through a purpose-built gateway, or carried through a supported packet-emulation design. The correct answer is service-specific. A circuit carrying an old operational-technology protocol has different constraints from a temporary leased-line service that can be re-ordered as Ethernet. Replacement planning should include the application owner, carrier and any field equipment that expects the legacy electrical interface.

A useful rule is to classify every active interface as “native on target,” “native with new optic or breakout,” “requires external conversion,” or “must be retired before cutover.” That classification creates a clean procurement list and makes the migration schedule realistic. It also prevents a common mistake: purchasing a modern high-capacity router that cannot physically terminate the one legacy circuit that makes the site operationally critical.

Service compatibility: MPLS, L2VPN, L3VPN, multicast and QoS

IOS XE to IOS XR changes the operational model

The modular ASR 900 family runs Cisco IOS XE, while the Cisco 8404 and NCS 560 migration candidates are IOS XR platforms. That operating-system transition is one of the most important planning points on this page. Teams familiar with IOS XE will recognize many networking concepts, but configuration structure, candidate changes, commit behavior, route policy, package and software management, interface naming, troubleshooting workflows and automation interfaces can differ significantly.

Start by separating configuration into functional blocks: management, AAA, NTP and timing, interfaces, routing, MPLS, VPN services, QoS, multicast, access control, logging, telemetry, SNMP, automation and high availability. For each block, decide whether the new design should reproduce the old behavior or modernize it. A migration is a good opportunity to remove dead configuration, old ACL entries, unused services and obsolete monitoring targets rather than copy technical debt into the new router.

Operations teams should rehearse common failure scenarios before production cutover. Engineers need to know how to check route health, label distribution or segment-routing state, pseudowire status, L2VPN and L3VPN state, interface errors, optics diagnostics, QoS counters, CPU and memory, timing lock, environmental alarms and redundancy. They also need a tested process for configuration rollback and software recovery. The goal is not only for the new router to pass traffic; it must be supportable at 2 a.m. during an incident.

Automation deserves the same care. Scripts that scrape IOS XE CLI output can fail silently when command output changes. Templates built for IOS XE interface names may generate invalid XR configuration. SNMP object support and telemetry paths may differ by release. Treat monitoring and orchestration as part of the production service, not an afterthought. If the current network relies on manual administration, a migration can still be completed successfully, but the new operating model should be documented and handed over with runbooks.

Timing and synchronization must be tested as a service

ASR 900 platforms have been used in networks where clocking is fundamental, particularly mobile transport and environments that still bridge packet and legacy timing domains. Cisco documentation for the family references timing capabilities such as BITS, 10 MHz, 1PPS, Time of Day, Synchronous Ethernet and IEEE 1588. If any of these functions are active, a replacement cannot be approved solely on packet throughput and port count.

Document whether each site is a timing source, boundary, slave or transparent element in the overall design. Record the upstream and downstream clock references, profiles, priority settings, holdover expectations and what happens after loss of reference. Verify the target platform, route processor, interface hardware and software release for the exact synchronization mode. Even when two platforms both list “1588 support,” the supported profiles, hardware timestamping path and operational commands may differ.

During staging, test lock acquisition, reference switching, alarms and recovery after failure. During cutover, include timing validation in the go/no-go checklist before dependent radio, transport or industrial systems are declared healthy. For sites where timing is not used, record that fact explicitly. A written “not required” is better than assuming it was overlooked.

How to size the replacement correctly

Sizing starts with present utilization but should not end there. Collect peak and percentile traffic on every uplink, aggregate forwarding, packet rates where available, route and label scale, number of VPN services, pseudowires, VLANs, subinterfaces, ACL entries, QoS classes, multicast state and any hardware-resource counters that indicate pressure. A router running at modest bandwidth can still be scale-limited by routes, labels, queues or service instances. Conversely, a router with many physically installed modules may have significant unused capacity that does not need to be recreated.

Choose a planning horizon. For a stable private network, three to five years of expected growth may be enough. For a carrier aggregation node that will absorb additional access rings or 100G uplinks, the design may need a longer runway. Translate growth assumptions into port and throughput requirements rather than a vague “future-proof” request. For example, identify the number of 10G ports needed on day one, the number likely to move to 25G or 100G, whether redundant uplinks will be active-active, and whether multiple existing ASR 900 nodes will be consolidated.

Redundancy changes capacity mathematics. A dual-homed design may need each surviving path to carry the full load after failure. A chassis with redundant route processors may still need line-card diversity and physically separate uplinks to remove a single failure domain. If the present ASR design uses two independent routers, do not replace them with one larger chassis merely because it has redundant components without reviewing the operational and maintenance failure domains. Chassis redundancy and node redundancy solve different problems.

Service scale should be checked against the exact hardware and software combination being quoted. Avoid using headline system capacity as the only metric. Forwarding capacity, line-rate behavior, route scale, label scale, MAC scale, VPN scale, ACL and QoS resources can be governed by different hardware tables and licenses. The requirement document should name the services and quantities that matter to the network so the design can be verified against current Cisco documentation for the selected release.

Finally, reserve realistic headroom. Operating a replacement at its tested limit on day one creates a second migration problem. Headroom should account for growth, failover, traffic bursts, route events, maintenance states and changes in security or telemetry requirements. The amount of headroom is a design decision, not a universal percentage, but it should be explicit in the proposal.

Rack, power, airflow and environmental planning in UAE sites

Physical migration is frequently underestimated because an ASR 900 chassis may be installed in compact telecom racks, remote POPs or cabinets with strict depth, airflow and power limitations. The ASR 900 family was designed with compact and shallow deployment options, including environments where space is constrained. A replacement chassis that is technically ideal in a data sheet can still be wrong for the site if rack depth, cable bend radius, intake temperature or power feeds do not match.

For each UAE location, record rack type, available rack units, usable depth, front and rear clearance, airflow direction, ambient temperature range, dust exposure, grounding, AC or DC feeds, breaker capacity, redundant power circuits and PDU connector types. Photographing the rack front and rear is useful during design review because it reveals cable congestion and neighboring equipment that spreadsheets miss. If the replacement is deeper or uses a different airflow pattern, model the rack layout before delivery.

Power calculations should use the quoted configuration rather than a generic chassis maximum alone. Include route processors, line cards, optics, fans and redundancy. Confirm whether both feeds are intended to carry load concurrently or whether either feed must support the full chassis after failure. In remote or utility environments, DC power requirements may be decisive. For high-temperature sites, verify the supported environmental range for the exact platform and modules rather than inheriting assumptions from the ASR 900 installation.

Cabling is part of the migration BOM. New optics, fiber jumpers, breakout cables, patch panels or copper conversions can determine the length of the maintenance window. Label both ends before cutover and produce a port-mapping sheet that shows old interface, service, target interface and optic. This simple document reduces human error more effectively than trying to reconstruct cabling decisions during the outage.

Licensing, subscriptions and support are part of the architecture

A replacement quotation is incomplete if it lists only chassis and interface hardware. Cisco software and licensing models evolve across platform generations, and the ASR 900 to IOS XR migration may introduce different entitlement, smart licensing or subscription requirements depending on the selected hardware, features and commercial program. Exact requirements should be verified for the final bill of materials at quotation time because licensing can change independently of the physical platform.

Build a feature-to-license matrix. List the routing, MPLS, VPN, telemetry, encryption or other software capabilities the design expects and identify the entitlement that enables them. Include term length where subscriptions apply, account or smart-account requirements, renewal ownership and what functionality or support changes at expiration. This prevents a technically capable router from being deployed without the commercial entitlement required for the planned service.

Support coverage should also reflect the service criticality. Decide whether the site needs standard support, faster hardware replacement, software access, TAC entitlement or an operational service from a local integrator. If the old ASR 900 has an active contract, capture contract expiry and serial numbers so the migration schedule can avoid paying for unnecessary overlap while still maintaining coverage during parallel running.

Cisco also notes its Technology Migration Program and Cisco Refresh options in the lifecycle bulletin. Eligibility and availability can vary, so these should be treated as commercial options to investigate rather than guaranteed discounts or supply. For long-lived UAE networks, the stronger procurement objective is a supported target architecture with a defined lifecycle and spare strategy, not the lowest initial hardware price.

A practical ASR 900 replacement project plan

For multi-site UAE estates, run one or two representative pilot sites first. A pilot should include the hardest service pattern, not only the easiest location. Once the template is proven, lock the standard hardware and software baseline, configuration method, test script and rollback criteria. That converts a risky collection of one-off migrations into a repeatable program. Sites with exceptional TDM, timing or physical constraints can then be handled as controlled exceptions.

Cutover validation: what “successful migration” should mean

A green interface is not a complete acceptance test. Define success at the service layer. For routed networks, compare expected prefixes, next hops, routing-neighbor state and convergence. For MPLS, verify label and LSP health where applicable. For L2VPN and pseudowire services, confirm attachment circuits, remote endpoints, MAC learning and end-to-end traffic. For L3VPN, verify VRF routes and reachability across representative destinations. For multicast, validate joins and actual application streams. For QoS, confirm counters increment in the correct classes and that shaping or policing behavior matches the design.

Physical checks matter too. Inspect optic diagnostics, receive/transmit levels, CRC or input errors, link flaps, temperature, fan and power status. Where the replacement changes optics or patching, capture pre- and post-migration optical readings so degraded fiber is not incorrectly blamed on the new router. For redundant systems, test one controlled failure path before declaring completion: an uplink, route processor, power feed or routing adjacency as appropriate to the design.

Management acceptance should verify syslog, SNMP, streaming telemetry, NTP, AAA, TACACS or RADIUS, backups, configuration compliance and alerting. Security teams may also require vulnerability-scanner visibility, logging and access-policy confirmation. If automation is used, run the production scripts against the new platform rather than assuming the lab template represents every site.

Close the migration only after diagrams, asset records, support details, licenses, spares and operational runbooks are updated. Decommissioning should include secure configuration removal from retired hardware and an approved disposition path. Cisco’s lifecycle notice references takeback and recycling programs, but the appropriate UAE disposal and data-handling process should follow the organization’s policy and applicable supplier arrangements.

Common ASR 900 replacement mistakes to avoid

When a direct Cisco migration path may not be the best answer

Cisco’s named migration products are useful reference points, but an end-of-life project should still challenge the original role. A site designed ten years ago may no longer need the same architecture. If the ASR 900 is now carrying only a small number of enterprise routed links, a large service-provider aggregation chassis may be unnecessary. If the site has grown into a major core or peering function, replacing it with a similarly sized aggregation device may be too conservative. If legacy TDM is the only reason the old platform remains, the better project may be to modernize the service handoff rather than preserve the legacy interface indefinitely.

The correct alternative depends on the network domain. Provider and metro aggregation may favor NCS or Cisco 8000 options. Enterprise WAN edge requirements may point toward a different Cisco routing family if SD-WAN, security integration or branch features dominate. Data-center interconnect may require a platform selected around high-speed Ethernet and routing scale rather than traditional aggregation interfaces. The replacement study should state why a target family fits the current role and why obvious alternatives were rejected.

This balanced approach prevents lifecycle migration from becoming vendor-part-number administration. The objective is a supportable network architecture for the next operating period. The ASR 900 end-of-life event provides the deadline; the organization’s applications, topology, resiliency and operations define the destination.

UAE deployment considerations and sourcing

UAE projects often span a mix of enterprise data centers, telecom rooms, industrial sites, branches and remote cabinets. The replacement design should therefore distinguish equipment-room assumptions from field-site reality. Cooling, dust, access windows, power standards, rack depth, fiber availability and the distance between engineering teams and remote locations can all change the practical migration method. A hardware configuration that works in a central Dubai data center may require a different physical plan in a compact remote cabinet.

Procurement should allow enough lead time for chassis, route processors, interface modules, optics, power components, licenses and support activation. Availability can vary by exact part number and program, particularly as an old family approaches end-of-sale. Replacement orders should be based on a validated BOM with country, delivery site and support entitlement defined. Avoid buying isolated hardware before the full design is checked; a discounted chassis is not useful if the required module, optic or license cannot be supplied in the needed timeframe.

For UAE project coordination, FourTeck UAE can be used for local infrastructure sourcing and consultation. Broader service planning and implementation support can be coordinated through FourTeck IT Services UAE. Network-security dependencies around the routing change can be reviewed through Firewall Dubai by FourTeck, while organizations with regional or international procurement requirements can reference FourTeck global.

The most useful information to send with an enquiry is not simply “replace ASR 900.” Provide show-inventory output or a hardware list, running software, active interface summary, topology, service count, required routing and MPLS features, timing needs, rack and power details, desired support level and target migration date. That allows the quotation to address engineering reality rather than guess at a generic successor.

Buyer questions that should be answered before purchase

Technical discovery checklist for a quotation

Decision recap

What FourTeck needs to prepare an accurate ASR 900 replacement proposal

Send the exact installed model information and the business target. For one device, a show-inventory capture, active interface list, topology and service summary may be enough to begin. For a fleet, provide a spreadsheet of devices, locations, modules, software and support status, then identify representative site types. Add expected traffic growth, required interfaces, MPLS and routing functions, timing, redundancy, rack and power constraints, desired support, quantity and migration dates. If legacy TDM or serial services exist, list them separately with the connected application and carrier handoff.

Build the ASR 900 replacement around your live services, not a generic part-number swap

FourTeck can review the installed Cisco ASR 900 or ASR 920 estate, identify which services and interfaces need preservation or redesign, compare Cisco migration platforms, and prepare a UAE-focused bill of materials and implementation scope. The result should make the lifecycle transition predictable: verified hardware, supported software, correct optics and licensing, realistic capacity, documented cutover and a clear support path.