Direct answer: what does ASR 900 and ASR 920 replacement mean?

Cisco ASR 900 and ASR 920 replacement is the process of moving services from aging aggregation routers to a currently supported platform while preserving the required Ethernet, IP, MPLS, timing, QoS, resiliency and operational functions. The ASR 920 is widely used as a compact Carrier Ethernet access and aggregation platform, while the broader ASR 900 family includes modular chassis such as the ASR 902, ASR 903, ASR 907 and ASR 914 with route switch processors and interface modules. Because these platforms can sit at cell sites, metro aggregation points, provider edges, enterprise WAN handoffs and utility or transport networks, a correct replacement must be based on the live service role rather than the product name alone.

The main candidates depend on the exact installed model. Cisco’s April 2026 ASR 920 end-of-life bulletin lists multiple Cisco 8010 and NCS 540 systems as migration products for affected fixed ASR 920 models. Cisco’s ASR 900 bulletin lists Cisco 8404 and NCS 560 systems for the ASR 902, 903, 907 and 914 chassis. However, Cisco also states that several individual ASR 900 interface modules and route switch processor SKUs have no direct migration product. That means a UAE buyer should not order a replacement platform from a generic model-to-model table without checking the actual interfaces and services in use.

Organizations that should consider migration planning now include telecom operators, managed network providers, mobile backhaul teams, utilities, government networks, large campuses and enterprises that rely on ASR 900 or ASR 920 equipment in production. The most important factor to confirm is the complete service and interface inventory: physical ports, optics, AC/DC power, timing source, MPLS or L2VPN/L3VPN functions, routing protocols, QoS behavior, CEM/TDM requirements, management integrations and redundancy design. FourTeck can use that information to determine whether an NCS 540, Cisco 8010, NCS 560, Cisco 8404 or another architecture deserves evaluation and to identify where a simple hardware swap is not technically realistic.

Why the 2026 lifecycle announcement matters in the UAE

Cisco’s published end-of-life schedules create a clear planning window rather than an immediate shutdown. For the affected Cisco ASR 900 and ASR 920 products announced in 2026, Cisco states that the last day to order through Cisco point-of-sale mechanisms is 31 March 2027, with last ship date 30 June 2027. The bulletins also show later support milestones, including vulnerability and security support through 30 September 2028 and a last date of support of 31 March 2032 for the products covered by those notices, subject to the terms of active service contracts. Those dates are useful for risk planning, but they should not be interpreted as a recommendation to postpone migration until the final support date.

For a UAE network, waiting can increase several practical risks. Replacement optics or spares may become harder to source. A maintenance contract may not solve an architectural constraint when bandwidth, telemetry, automation or timing requirements grow. New sites may need a different standard platform from the legacy installed base. Security teams may want newer software trains and operational tooling. Procurement teams may also need time for budget approvals, staging, lab validation, change windows and cross-site rollout. In a service-provider environment, a router refresh can affect thousands of downstream circuits or multiple transport services, so the engineering schedule often matters more than the purchase date.

The best use of the lifecycle window is to classify sites. Some ASR 920 locations may be simple fixed-port Ethernet aggregation sites that map cleanly to a current small-form-factor router. Others may use SyncE/PTP, complex hierarchical QoS, MPLS pseudowires, EVPN or legacy handoffs that need deeper validation. Modular ASR 900 deployments may have unusual T1/E1, DS3/E3, serial, CEM or mixed Ethernet modules. Those sites should be treated as migration projects, not commodity replacements. A phased plan can separate low-risk sites from technically exceptional locations, allowing the standard target design to stabilize before the most complex cutovers.

Cisco’s migration direction at a glance

ASR 920 replacement: how to interpret Cisco 8010 and NCS 540 options

The ASR 920 family was designed for compact aggregation and Carrier Ethernet access. Different variants combine 1 Gigabit Ethernet, 10 Gigabit Ethernet, copper or fiber access, AC or DC power, fixed interfaces and in some cases an interface-module slot. Cisco’s migration bulletin therefore lists several possible target systems instead of a single replacement. Examples include 8011-12G12X4Y and 8011-16G8X fixed Cisco 8010 systems as well as N540-6Z18G-SYS and multiple N540X variants. For the older passively cooled ASR-920-10SZ-PD, Cisco’s earlier lifecycle announcement lists N540-6Z14S-SYS-D as the replacement product. These mappings are valuable starting points, but the buyer still needs to decide which target architecture best matches the production service.

Cisco’s current 8011-12G12X4Y platform illustrates why a migration may deliver more than a like-for-like port replacement. Cisco documents 4 ports capable of 1G/10G/25G, 12 ports of 1G/10G and 12 1G SFP ports or a higher cSFP count, along with fixed redundant power supplies. The platform is built around IOS XR. For a network that wants to standardize on a newer Cisco routing architecture, add 25G headroom or modernize operations, that can be attractive. Yet the difference in operating system and the exact physical-interface arrangement means an ASR 920 configuration cannot simply be copied line for line and expected to work.

NCS 540 platforms are also relevant because Cisco positions them for access and aggregation, including hardened and timing-sensitive deployments. Current NCS 540 documentation includes MPLS, Segment Routing, L2VPN/L3VPN capabilities, hierarchical QoS, SyncE, PTP, telemetry, NETCONF/gRPC and YANG-based management on supported models and releases. That functional direction suits mobile backhaul, provider access and modern routed transport, but exact support varies by model and software release. A replacement design must therefore map required production features to the chosen NCS 540 SKU and release rather than assuming every capability is universal across the family.

For UAE deployments, physical environment matters as much as protocol capability. Outdoor cabinets, telecom shelters, street-side aggregation locations and industrial sites can impose temperature, airflow and power conditions very different from a conditioned data room. Some NCS 540X and Cisco 8010 variants are offered with extended-temperature or conformal-coating characteristics, but the precise environmental rating must be checked against the site. A replacement that works in a laboratory rack may be unsuitable if the production cabinet has side-to-side airflow constraints, limited depth, DC feed requirements or strict thermal behavior.

ASR 900 modular replacement: Cisco 8404 and NCS 560 are different design choices

The modular ASR 900 family creates a different migration problem from the fixed ASR 920. An ASR 902, ASR 903, ASR 907 or ASR 914 deployment may combine a chassis, route switch processors, power supplies and specific interface modules selected for a service role. Cisco’s 2026 end-of-life bulletin lists the Cisco 8404 and NCS 560-4/NCS 560-7 systems as migration products for these chassis. That does not mean the target is a chassis with identical slots and behavior. It means Cisco provides current portfolio directions that must be engineered against the installed configuration.

The Cisco 8404 belongs to the Cisco 8000 Series and uses Cisco IOS XR. Cisco describes it as a centralized architecture with options for redundant control and data plane through redundant route switch processors, and the published platform capacity is substantially beyond many legacy ASR 900 deployments. It may make sense where a network wants higher scale, stronger long-term aggregation capacity or alignment with a Cisco 8000 architecture. It may be excessive for a small remote site if the existing ASR 903 carries only a modest number of circuits. A migration decision should therefore consider both technical fit and economic proportionality.

The NCS 560 family may be attractive where the operator wants a modular access and aggregation platform with IOS XR and service-provider features. Cisco’s NCS 560 documentation includes RSP4 options and shows compatibility for certain Ethernet interface modules, including some ASR 900-origin modules on specific NCS 560 configurations. That can be useful in a staged migration, but it must never be generalized to all legacy cards. Cisco’s end-of-life bulletin explicitly marks many ASR 900 interface-module part numbers as having no current migration product. The exact module PID, hardware revision, target chassis, target RSP, software release and feature combination should be checked before any reuse plan is approved.

A modular migration also raises resilience questions. Existing deployments may use dual RSPs, dual power feeds, redundant uplinks and fast convergence tuned around particular maintenance practices. The target platform should be sized not only for steady-state traffic but for failure state: one uplink down, one line card unavailable, a maintenance drain in progress or a route reconvergence event. The replacement design should document what remains redundant, what becomes centralized, what maintenance operation changes and whether the network’s availability objective is still met after the architecture changes.

Model-to-direction reference for common installed platforms

This table is a planning reference, not a bill of materials. Cisco’s migration tables can contain several valid options for one legacy PID, and exact support depends on hardware, software and service requirements.

The most important discovery step: identify what the router is actually doing

An inventory that says only “ASR 920” or “ASR 903” is not enough for a defensible replacement quote. Two routers with the same chassis can perform completely different jobs. One may be a Layer 2 business Ethernet demarcation device with a few EVCs. Another may terminate hundreds of pseudowires, participate in IS-IS and MPLS, provide PTP timing, apply multilevel QoS and connect to an OSS platform through SNMP. A third may carry legacy circuit-emulation services. The hardware label does not reveal those operational dependencies.

The discovery package should include chassis PID, serial and hardware revision, route switch processor PID where applicable, all interface-module PIDs, power-supply configuration, fan/airflow direction, optics and cable types, port speeds, logical interface configuration, VRFs, routing protocols, MPLS labels and VPN services, QoS policy maps, ACLs, timing configuration, redundancy protocols, logging destinations, AAA/TACACS configuration, monitoring methods, NetFlow or telemetry requirements, and any automation that assumes IOS XE CLI output. Capturing current CPU, memory, forwarding and interface utilization over representative busy periods gives better evidence for sizing than a configuration file alone.

For multi-site UAE networks, classify each site by service archetype and exception count. If 80 percent of locations use the same simple ASR 920 design and 20 percent contain unusual timing or legacy interfaces, standardize the common sites first. That reduces engineering variance and makes procurement more predictable. The exceptional sites can then receive individual designs instead of forcing the standard target platform to accommodate every historical edge case.

IOS XE to IOS XR is an operational migration, not a syntax conversion

A major architectural consideration is software. ASR 920 and ASR 900 deployments commonly run Cisco IOS XE. Current NCS 540, NCS 560 and Cisco 8000 platforms are built around Cisco IOS XR. The two operating systems share networking concepts, but their configuration models, package behavior, commit workflow, operational commands, process architecture and automation interfaces differ. A migration project should therefore allocate time for design translation and operational training instead of assuming that a saved configuration can be pasted into the new router.

Start with intent. For each IOS XE feature, document what service outcome it provides: reachability, traffic engineering, customer separation, fast convergence, timing, QoS, access control or management. Then map that outcome to the supported IOS XR implementation on the exact target software release. This matters because command structure can change and because the preferred modern design may not be a literal equivalent. For example, a network may choose to retain traditional MPLS/LDP during the first migration phase or may use the hardware refresh as an opportunity to evaluate Segment Routing. That is an architecture decision, not a requirement of the hardware replacement.

Operations teams also need revised runbooks. Backup and restore procedures, software upgrade methods, image/package management, configuration rollback, health checks, interface troubleshooting and routing-protocol verification should be tested on IOS XR. Monitoring platforms may need new MIBs or telemetry paths. CLI parsers written for IOS XE output may fail. AAA roles and command authorization can behave differently. Automation based on NETCONF, gRPC, YANG or model-driven telemetry can improve the new environment, but it needs deliberate implementation and change control.

The safest approach is to build a representative lab or staging configuration from a real production service profile. Validate routing adjacency formation, MPLS labels, L2VPN/L3VPN forwarding, QoS counters, timing lock, optics, failure convergence, logging and management access before the field cutover. The lab does not need to reproduce every site; it needs to reproduce every important service archetype and exceptional dependency. That turns the software migration from an unknown into a repeatable deployment pattern.

Interfaces, optics and cabling: where “same speed” can still be incompatible

Port speed is only one part of physical compatibility. A 10 Gigabit Ethernet connection may use SFP+, XFP or another form factor depending on the legacy module. A 1 Gigabit fiber access link may use single-fiber bidirectional optics, cSFP arrangements or standard duplex SFPs. Copper handoffs may rely on RJ45 interfaces that are not present in the same quantity on the chosen replacement. Before a quote is finalized, record the optic PID, wavelength, reach, fiber type, connector type and far-end equipment for every production link that must remain unchanged.

Do not assume that an optic supported in the ASR 920 is automatically supported in an NCS 540 or Cisco 8010. Cisco publishes platform-specific transceiver compatibility information, and support can depend on software release. A migration BOM should list replacement optics explicitly where reuse is not verified. This is especially important when a network uses CWDM/DWDM optics, bidirectional SFPs, long-reach modules or third-party transceivers. The cost of optics can materially affect the project, and an incompatible optic discovered during a midnight cutover can turn a planned migration into an outage.

Higher-speed uplinks create another design choice. Some Cisco 8010 migration options add 25G capability beyond the typical ASR 920 uplink pattern. That can provide useful growth headroom, but the far-end switch or router, optic standard and fiber plant must support the selected speed. It is often sensible to install a platform capable of 25G while initially operating certain links at 10G, provided the exact port and transceiver combination is supported. This allows capacity growth without forcing an immediate upstream refresh.

Cable management and rack depth should also be included in the site survey. A shallow ASR 920 can fit locations where a deeper platform or different airflow arrangement creates problems. Verify front and rear clearance, patch-panel position, ear orientation, rack standard, grounding, console access and service-loop length. Physical installation details are easy to overlook in network diagrams but can determine whether the selected replacement can actually be installed without cabinet modification.

Timing and synchronization for mobile, utility and transport networks

Timing can be a decisive requirement in ASR 900 and ASR 920 replacement projects. Some deployments participate in SyncE and IEEE 1588 Precision Time Protocol designs, distribute frequency or phase, use external timing connectors, or connect to GNSS-based sources. The replacement must preserve the required timing role, not merely offer Ethernet ports. A model that is perfectly suitable for enterprise WAN aggregation may be inappropriate at a mobile cell site if it cannot provide the exact timing profile, clock class or physical timing interface expected by the network.

Cisco’s current NCS 540 documentation includes SyncE and PTP functions on supported models, with timing capabilities varying by platform. Cisco 8010 documentation also includes timing interfaces and variants designed for access and aggregation environments. These capabilities make both families relevant, but model-level validation remains mandatory. Confirm whether the router acts as a boundary clock, transparent clock, grandmaster-connected node or timing client; record the PTP profile; check SyncE topology; identify external ToD, 1PPS, 10 MHz or GNSS connections; and document redundancy behavior when the preferred timing source fails.

A timing migration should include measurements, not just configuration review. Before cutover, establish the current timing state and alarms. After cutover, verify lock state, parent clock identity, offset, frequency performance and any mobile-network acceptance criteria. Where timing affects radio access or industrial control, coordinate the network migration with the service owner because a router can pass ordinary IP traffic while still failing the timing requirement.

MPLS, Carrier Ethernet and VPN service preservation

Many ASR 900 and ASR 920 routers were purchased because they can deliver service-provider Ethernet and MPLS functions in compact or modular form factors. A replacement project must preserve the exact customer and transport services carried by the node. Inventory Layer 2 circuits, bridge domains, Ethernet flow points, pseudowires, VPLS or EVPN services, Layer 3 VRFs, MPLS label distribution, route-target policy, multicast and OAM functions. The objective is to understand the service graph from customer handoff to core, not only the local router configuration.

NCS 540 documentation includes MPLS, L2VPN, L3VPN and Segment Routing capabilities on supported systems and releases. Cisco 8000 platforms also provide a modern IOS XR routing architecture. Yet a feature name appearing in a family data sheet does not guarantee identical scale or behavior on every SKU. Check the target model’s route scale, label scale, MAC scale, bridge-domain scale, QoS resources and feature combinations against the production requirements. A small access router can support a technology while still being undersized for a dense aggregation role.

Migration sequencing is equally important. For a dual-homed service, it may be possible to introduce the new router alongside the ASR platform and move circuits incrementally. For a single-homed remote node, the migration may require a hard cut with a prepared rollback. Where the design changes from LDP to Segment Routing, from legacy VPLS to EVPN or from one routing-policy model to another, separate the hardware replacement objective from optional service transformation wherever possible. Limiting the number of simultaneous changes usually makes troubleshooting and rollback safer.

QoS and traffic engineering require workload-based validation

QoS is one of the easiest areas to underestimate. ASR 900/920 deployments may classify traffic by VLAN, MPLS EXP/TC, DSCP, CoS, IP fields or service instance, then apply policing, shaping, priority queuing and hierarchical scheduling. A replacement router can have higher raw throughput but still require a different QoS design because queue architecture, scheduler scale, buffer behavior and policy syntax are platform-specific. For business Ethernet, mobile backhaul or wholesale services, QoS behavior is part of the service contract and deserves explicit testing.

Collect each active service-policy, its attachment point, class counters and expected bandwidth guarantees. Identify which classes require strict priority, which use shaping, where policers enforce customer rates and whether hierarchical parent/child policies are essential. Compare these requirements with the target platform’s supported QoS hierarchy and scale. If the replacement introduces much faster uplinks, reassess oversubscription ratios and queue allocations instead of copying historical rate values without context.

Testing should include congestion. A QoS policy that looks correct when links are idle may behave differently at saturation. In staging, generate traffic that exercises priority, assured and best-effort classes, then verify drops, queue depth, latency and shaping behavior. For critical voice, timing or mobile traffic, validate failure scenarios where traffic shifts to a reduced-capacity path. The replacement should meet service intent during congestion and failover, not only during normal operation.

Power, environmental and rack requirements for UAE sites

UAE deployments range from modern data centers to telecom shelters, industrial rooms and outdoor cabinets. The replacement must fit the electrical and thermal environment. Record whether the existing router uses AC or -48V DC feeds, whether feeds are A/B redundant, breaker ratings, connector types, grounding arrangement, available rack units, cabinet depth and airflow direction. A target platform may have a supported AC and DC variant, but the physical connector and power budget can still require site work.

Temperature is especially important outside conditioned rooms. Some NCS 540 and Cisco 8010 variants are offered for extended-temperature environments, and Cisco documentation identifies industrial-temperature or hardened options on relevant models. Do not select a standard indoor variant for a cabinet simply because the port map is correct. Use the site’s measured environmental range, cabinet thermal design, solar load, filter condition and airflow path to determine the appropriate hardware. Where a heat exchanger or sealed enclosure is used, confirm that the new platform’s airflow is compatible with the enclosure design.

Power migration should be included in the change plan. If a new router uses a different connector or feed arrangement, have the correct power leads and electrician or facilities support ready before the network window. Confirm grounding and bonding. Test dual-feed failover after installation. A router refresh is also a good time to verify that labels, A/B feeds and breaker documentation match reality; legacy sites often accumulate undocumented changes over years of service.

Licensing and subscriptions should be designed before the hardware quote

Do not treat licensing as an afterthought. Current Cisco platforms can use licensing and consumption models that differ from legacy ASR 900/920 purchasing. Cisco 8010 documentation references the IOS XR Flexible Consumption Model, while NCS platforms have their own software and licensing requirements by model and feature set. The exact entitlement needed depends on the selected target, throughput, features, software release and support strategy. A hardware-only price comparison can therefore be misleading.

The quotation process should identify base software, feature tiers or consumption requirements, support coverage, term length and any management or automation components. Where a customer already has Cisco enterprise or service-provider agreements, verify whether the replacement can align with those contracts. For large phased migrations, consistency in software entitlement can reduce operational complexity. The goal is to know the full lifecycle cost before committing to a platform, not discover after installation that a required feature is gated by an unplanned license.

Licensing also affects lab and spare strategy. If a staging router, cold spare or disaster-recovery unit is required, determine how entitlements apply to those devices. Include the support level needed for production. The end-state design should have a documented process for entitlement registration, software download access, RMA handling and replacement hardware so that an operational incident does not become a procurement exercise.

High availability, redundancy and failure-domain design

A platform replacement is a good time to check whether the original redundancy design still matches business requirements. Fixed ASR 920 deployments may rely on dual power supplies and redundant network paths rather than dual control planes. Modular ASR 900 deployments may use redundant RSPs, power supplies and multiple interface paths. The selected replacement should be evaluated against the required failure domains: power feed, control plane, forwarding plane, line card, uplink, fiber path and upstream peer.

Do not compare only component counts. Two architectures can offer resilience in different ways. A Cisco 8404 design with redundant route switch processors may suit an aggregation location that needs high platform-level availability. Two smaller fixed NCS 540 or Cisco 8010 routers may create a different but equally valid redundancy pattern for a distributed access site. The right choice depends on whether the business prefers chassis redundancy, node redundancy, geographic separation or a combination.

Failure testing should be part of acceptance. Remove an uplink, isolate a power feed, reload a control component where supported, fail a routing adjacency and verify traffic recovery. Measure convergence for critical services rather than relying only on protocol state. Confirm that monitoring raises the expected alarms. A replacement project is complete when the network behaves correctly under failure, not merely when all interfaces are green in steady state.

Management, telemetry, automation and NOC integration

Legacy routers often accumulate years of operational integrations. The NOC may poll SNMP objects, parse syslog messages, use CLI scripts, collect NetFlow, run configuration backups and rely on threshold alarms tuned to the ASR platform. Replacing the router without inventorying these dependencies can create a silent monitoring gap even when traffic forwarding succeeds. Make management integration a formal migration workstream.

Current NCS 540 documentation includes model-driven management capabilities such as NETCONF, gRPC, YANG models and event-driven telemetry on supported software. That can improve visibility and automation, but organizations do not need to modernize everything in one cutover. A practical approach is to preserve essential monitoring first, then introduce telemetry or new automation once the production platform is stable. This avoids turning the hardware migration into an uncontrolled transformation program.

Security controls also need revalidation. Confirm AAA and TACACS/RADIUS behavior, local fallback accounts, SSH policy, management VRFs, ACLs, SNMPv3, certificate handling, NTP, DNS and logging. Review which teams have administrative access and how role-based permissions should work on IOS XR. Where centralized configuration management is used, add the new platform templates and compliance rules before deployment so the device enters production under normal governance.

Finally, update documentation. Device naming, rack elevations, IPAM, circuit records, diagrams, support contracts, spare inventory and escalation procedures should reflect the replacement. A technically successful cutover followed by inaccurate operations data simply moves risk from hardware lifecycle into supportability.

A practical ASR 900 / ASR 920 migration journey

When a smaller NCS 540 or Cisco 8010 may be the better choice

A compact fixed replacement often makes sense when the installed ASR 920 is primarily an access or edge aggregation device with a predictable number of Ethernet interfaces, modest service scale and no requirement for a modular chassis. In this situation, a current NCS 540 or Cisco 8010 option can provide a modern IOS XR platform without introducing unnecessary rack space and complexity. The exact model should be selected by port mix and service needs, not by purchasing the highest-capacity option available.

For example, an ASR-920-4SZ site with only a few 10G uplinks may not benefit from a large modular chassis. A small fixed router with enough 1G/10G connectivity, correct power type, timing support and suitable environmental rating can be operationally cleaner. Conversely, an ASR-920-24SZ-M site using a dense field of 1G fiber circuits needs careful port-count planning. If the new platform provides fewer native 1G access positions, the design may need cSFP, an adjacent aggregation switch or a different model. “Newer” does not automatically mean “fewer boxes.”

Choose the smallest platform that comfortably meets current requirements, failure-state load and credible growth while preserving operational consistency. Oversizing every remote site increases capital cost and may also increase power draw, space requirements and software complexity. Undersizing creates a second migration sooner than expected. A measured capacity plan is more useful than either extreme.

When NCS 560 or Cisco 8404 deserves evaluation

A larger modular or centralized system deserves consideration when the existing ASR 900 chassis performs real aggregation rather than simple access. Indicators include many physical circuits, high forwarding demand, multiple service types, dual control components, substantial routing or label scale, dense 10G/100G uplinks, strict maintenance requirements or a roadmap toward materially higher bandwidth. Cisco’s migration bulletin explicitly lists NCS 560 and Cisco 8404 options for ASR 902/903/907/914 chassis, providing a supported portfolio direction for these use cases.

The NCS 560 family can be attractive where modularity and service-provider access/aggregation functions are central. Cisco’s RSP4 documentation describes 800G-class route switch processor options, and certain Ethernet interface modules have documented compatibility with NCS 560 configurations. Cisco 8404 offers a different centralized architecture within the Cisco 8000 family, with high system capacity and redundant route switch processor options. The two families therefore should not be compared only on headline throughput; they represent different platform and lifecycle choices.

Evaluate rack space, power, interface economics, software standardization, redundancy model, traffic scale, feature roadmap and the operator’s engineering skill set. If the organization already operates IOS XR on NCS or Cisco 8000 systems, standardization may reduce training and tooling effort. If not, the migration plan should include that operational transition. The right platform is the one that supports the service architecture for its expected lifecycle with an acceptable total cost and support model.

Legacy TDM, serial and circuit-emulation interfaces need a separate workstream

Cisco’s 2026 ASR 900 end-of-life bulletin is particularly important for networks using older interface types because it lists no direct migration product for numerous ASR 900 interface-module PIDs. The affected list includes examples of T1/E1, DS3/E3, E&M, XFP and other specialized modules. This is a strong signal that a modern Ethernet/IP replacement cannot always reproduce the physical handoff in the same chassis.

For each legacy circuit, determine whether the service still needs to exist in its current form. Some circuits can be retired because the application has already migrated. Others can be converted to Ethernet or IP at the customer or field device. Some require a dedicated circuit-emulation gateway or another transport platform. A few may need to remain on legacy equipment for a controlled interim period while the endpoint is modernized. The router replacement plan should expose these decisions early because special-interface sites can dominate schedule and risk even when they represent a small percentage of the installed base.

Do not solve this problem by purchasing used legacy hardware as the default architecture. Refurbished equipment can be useful for temporary spares or a transition period when supported and appropriate, but it does not remove the underlying lifecycle issue. For critical UAE infrastructure, the long-term objective should be a supportable service architecture with documented replacement paths and available expertise.

Typical UAE deployment scenarios

Procurement guidance: what should be included in a replacement BOM?

A complete replacement bill of materials goes beyond the base chassis. For a fixed platform, it may include the exact AC or DC system PID, rack kit, optics, timing accessories, console or management accessories, software entitlement and support. For a modular platform, include chassis, route switch processors, line cards or interface modules, power supplies, fan trays, blanking panels, rack accessories, optics, licenses and support. If the existing site uses special patch panels, wire-wrap adapters, GNSS components or external timing cabling, determine whether those items are reusable or need replacement.

Spares should be planned at fleet level. A network with hundreds of identical fixed routers may justify a small pool of complete spare units plus commonly failed optics. A modular deployment may need spare power supplies, fan components, route switch processors or interface modules depending on operational policy. The support contract and RMA SLA should influence how much stock is held locally. For critical services, calculate the business impact of waiting for an RMA against the cost of on-hand spares.

Quotation accuracy depends on the information supplied. If the request says only “replace 20 ASR 920 routers,” the quote must either contain assumptions or remain incomplete. A better request includes model PIDs, quantity by model, port population, optic types, power source, software functions, site environment, required support term, migration services and whether staging is needed. That allows procurement to compare technically equivalent offers instead of comparing prices for different scopes.

Availability and lead time should be confirmed when the final BOM is approved because supply conditions change. If a migration is tied to a contract renewal or network launch, include schedule risk in the design. In some cases, choosing a standardized target that is easier to procure and spare across the UAE can be more valuable than optimizing each site around a different minimum-cost SKU.

FourTeck support for ASR 900 and ASR 920 migration in the UAE

FourTeck can support the planning stage by turning an installed-base inventory into a replacement shortlist and quotation scope. The useful starting point is evidence from the network: exact PIDs, configurations, interface and optic inventory, service requirements, utilization and site constraints. From there, the target can be compared against Cisco’s published lifecycle and migration information, and gaps can be identified before procurement.

For UAE procurement and infrastructure discussions, visit FourTeck UAE. Organizations coordinating broader vendor or regional requirements can also review FourTeck. Where the project includes staging, structured rollout, monitoring changes or ongoing operational support, FourTeck IT Services UAE provides a relevant services route. Network-security changes that accompany edge redesign can be discussed through Firewall Dubai by FourTeck.

The commercial objective should be a technically complete BOM, not a forced recommendation for the largest current router. If an NCS 540 is sufficient, the proposal should explain why. If a modular NCS 560 or Cisco 8404 is justified, the proposal should identify the scale or resiliency requirement that drives it. If the legacy service has no clean modern equivalent, that gap should be made visible before the customer purchases hardware.

Buyer questions and practical answers

Official lifecycle references used for this replacement guidance

Cisco’s “End-of-Sale and End-of-Life Announcement for the Cisco ASR 920,” updated 1 April 2026, states a 31 March 2027 end-of-sale date for the affected hardware and lists Cisco 8010 plus NCS 540 family migration products for numerous ASR 920 PIDs. Cisco’s “End-of-Sale and End-of-Life Announcement for the Cisco ASR 900,” also updated 1 April 2026, uses the same hardware end-of-sale date for the affected ASR 900 products and lists Cisco 8404 and NCS 560 migration products for ASR 902/903/907/914 chassis while showing no direct migration product for numerous individual legacy modules.

Because Cisco lifecycle documents and software support matrices can change, the final procurement decision should be validated against the current Cisco documentation for the exact PID and intended software release at the time of order. This page explains the migration logic and buyer decisions; it does not replace Cisco’s official ordering and compatibility tools.

Decision recap

What FourTeck needs for an accurate replacement quotation

Build the ASR replacement around your live network, not a generic successor list

The most reliable UAE migration starts with the installed hardware and service inventory, then maps each site to a supported current architecture. Fixed ASR 920 locations may align with Cisco 8010 or NCS 540 options; modular ASR 900 aggregation sites may justify NCS 560 or Cisco 8404; legacy-interface sites may require a different transition design. FourTeck can help turn those technical inputs into a practical shortlist, BOM and migration scope.