High availability is a system design, not a second firewall

A business can purchase two security appliances and still have a fragile network. If both appliances depend on the same internet circuit, the same unmanaged access switch, the same power strip, the same fibre handoff, the same provider router, or a single Layer 2 path that is incorrectly cabled, the design may still contain a single failure point. Meraki makes the appliance-level HA configuration comparatively straightforward, but the quality of the result depends on the physical and logical architecture around it.

For a Dubai site, the design conversation should therefore begin with the services that must stay online and the failure events the organisation intends to tolerate. A financial office may prioritise internet banking, SaaS access, voice and secure branch VPN. A warehouse may depend on cloud WMS traffic, handheld scanners, IP telephony, CCTV and wireless coverage. A hospitality site may care about guest internet, PMS connectivity, payment systems and staff networks. These requirements drive the number and diversity of uplinks, the switch architecture, the acceptable failover behaviour, the MX performance tier and the support process.

The architecture also needs operational realism. A resilient topology is valuable only if the organisation knows how it behaves during a failure, how alerts are delivered, who investigates, how firmware upgrades are handled, what replacement hardware is available and how configuration ownership is controlled in the Meraki Dashboard. High availability should reduce incident impact, but it does not eliminate the need for monitoring, capacity planning, documentation and periodic testing.

The six layers of a resilient Meraki design

MX pair requirements that must be confirmed before ordering

Routed MX HA: the common branch and campus edge pattern

Routed mode is common when the MX security appliance provides the site’s Layer 3 edge functions such as default gateway services, NAT, security policy, SD-WAN, internet breakout and site-to-site VPN. In this design, both MX appliances participate in the HA relationship and need dependable LAN-side reachability. Cisco recommends that the appliances communicate through downstream switching rather than relying on a direct dedicated HA cable between them.

A fully redundant design normally connects the two MX appliances to redundant downstream switches or to an appropriate switch stack. The objective is to make sure that loss of one switch or one path does not isolate the surviving MX from the production LAN. The downstream switching must also carry the VLANs required for the HA relationship. Cisco notes that MX VRRP heartbeat advertisements are sent across configured VLANs, so switch trunks, STP state and VLAN allowance need to be deliberate rather than assumed.

This is one reason a simple wiring diagram should be reviewed in detail before installation. If each MX is connected only to a single switch and those switches are not correctly interconnected, the passive unit may not have the network visibility required for clean takeover. If too many redundant Layer 2 links are introduced without correct spanning-tree control, the design may create loops. Resilience comes from controlled redundancy, not from adding cables without a topology model.

For a new Dubai deployment, FourTeck can map the intended VLANs, WAN handoffs, switch uplinks and power feeds before the equipment is mounted. This reduces the risk of discovering on the cutover night that the spare appliance is physically present but logically unable to take over the same services.

One-armed VPN concentrator HA for data centres and hub designs

Meraki MX can also be deployed as a VPN concentrator rather than as the primary routed internet edge. This architecture is relevant when the MX provides Auto VPN termination in a data centre or central site while upstream firewalls, routers or switching handle other edge functions. In a high-availability concentrator pair, one unit is active and the second remains passive until failover is required.

The heartbeat path is different from routed HA. In a one-armed concentrator design, the appliances use their uplink connectivity for the HA relationship. Both concentrators should have addressing and Layer 2 reachability appropriate to the shared upstream network. If BGP is also used for routing integration, the organisation should examine BGP session behaviour, route convergence, supported firmware requirements and the failover implications for the surrounding routers.

This distinction is important for organisations that operate a Meraki SD-WAN with many branches. The branch sites may have local MX appliances while the central hub pair terminates Auto VPN in a data centre. Resilience then depends on more than the concentrator pair: the upstream switching, routing adjacencies, data-centre internet or private WAN paths, power domains and application network routes must also survive the intended failure events.

A concentrator design should therefore be quoted only after the existing data-centre topology is understood. Port count, transceiver type, available subnets, BGP requirements, rack location and firewall integration are more useful inputs than a generic request for “two Meraki boxes.”

Licensing: one MX licence does not mean the whole redundant network is licensed once

Cisco Meraki states that an MX security appliance pair configured for HA requires one MX licence for the two appliances; the passive HA unit does not need a duplicate MX licence. This is an important commercial benefit because hardware resilience can be added without doubling the MX licensing quantity. The exact licence class and term still need to align with the selected MX model, Meraki licensing model and required security capabilities.

The licensing rule should not be generalised to every component in the architecture. Meraki switches that form a redundant pair or stack are separate managed devices and require appropriate licences for the individual switches. Wireless access points likewise require their relevant Meraki licensing. If the solution includes Systems Manager, sensors, cameras or other Meraki platforms, those products have their own entitlement requirements.

For procurement, the quotation should therefore separate edge HA hardware, MX licensing, switch hardware and licensing, optics or DAC cables, support requirements, installation services and any carrier work. This makes renewal responsibility clearer and avoids the common misunderstanding that “one HA licence” covers every redundant device in the network.

A licensing review is also useful when an organisation already owns Meraki equipment. The Dashboard organisation’s current licensing model, expiry position and existing entitlements can influence whether new hardware should be added under the same arrangement, renewed at the same time or procured with a different term that better matches internal budgeting.

Choosing the right MX capacity for an HA pair

Model selection should be based on the workload the active MX must carry, not simply on headcount. Two offices with the same number of employees can have very different traffic profiles. A design team needs to consider internet circuit speed, expected encrypted VPN throughput, application mix, security features, number of remote sites, client count, VLAN design and forecast growth. The performance effect of enabled security services also matters, because the appliance may inspect or shape traffic rather than merely route packets.

A useful sizing exercise separates current demand from contracted WAN capacity and future growth. If the business has a 1 Gbps circuit but normally uses only 150 Mbps, the edge still needs to be sized intentionally: is the requirement to use the full 1 Gbps during backups or major transfers, or is the circuit mainly purchased for burst headroom? If a secondary 1 Gbps circuit is added, should failover preserve the same performance? If the organisation intends to add more branches or move large workloads to cloud platforms, today’s observed utilisation may not describe next year’s requirements.

High availability also argues against sizing at the absolute edge of a platform’s practical capacity. During an incident, the surviving appliance should not be forced into a performance condition that was already marginal during normal operation. The spare is not a second active processing node that doubles available throughput. Each member of the pair should be individually appropriate for the intended production load.

FourTeck can use current circuit speeds, Dashboard statistics from an existing Meraki estate, firewall traffic reports, VPN requirements and growth plans to narrow the suitable MX family. Where the supplied requirement is close to a model boundary, comparing the next larger option can be more useful than choosing purely on acquisition cost.

Switching design: remove the downstream single point of failure

The switching layer is where many HA designs either become credible or remain cosmetic. If both MX appliances connect to one access switch, failure of that switch can disconnect both edge devices from the users they are supposed to protect. Cisco’s recommended routed HA topologies include fully redundant designs using two downstream switches or a downstream switch stack, with connectivity arranged so that one switch failure does not isolate the surviving path.

For Meraki MS switching, physical stacking is often preferred at the distribution layer when supported because it provides a coordinated switching system and can simplify resilient uplink design. A ring stack topology protects against a single stacking-link failure. The precise stack capabilities depend on the chosen MS or cloud-managed Catalyst model, so model-specific stacking ports, cables, bandwidth and member limits should be confirmed before hardware is purchased.

Where Layer 3 gateway redundancy is required and stacking is not available or not desired, supported Meraki switching platforms can use warm-spare VRRP. Unlike the MX HA licensing rule, both switches require their own licences. This architecture also introduces routing and spanning-tree decisions that should be considered alongside the MX layer. The network should have a clear answer for which device owns each VLAN gateway, where the STP root sits, how access switches are dual-homed and what happens when one distribution switch is removed.

It is also important to recognise a design limitation: MX LAN ports do not run LACP. If multiple redundant links exist between an MX and the switching layer, they should not be treated as an aggregated LACP bundle. STP and the recommended Meraki topology should be used instead. This is a good example of why copying a generic enterprise firewall diagram onto Meraki hardware can create unsupported assumptions.

IP addressing and virtual uplink planning

WAN addressing is often the practical constraint that determines how cleanly an MX HA pair can be deployed. Each MX needs its own uplink IP address for Dashboard connectivity. Depending on the selected HA uplink method, a virtual IP may also be used. Where a VIP is configured, Cisco requires it to be in the same subnet as the MX uplink addresses and to be different from the individual appliance addresses.

That means the carrier handoff must provide enough usable addresses and the provider router must support the intended behaviour. A circuit that offers only a single usable public IP can require a different design or provider configuration from one that supplies a routed subnet with multiple usable addresses. This should be established before the installation date because public-address changes can involve carrier lead times and firewall policy changes on external systems.

The LAN side needs the same level of discipline. If the MX provides VLAN gateways, the network should have a complete IP plan for interface addresses, DHCP scopes, static reservations, management subnets, voice networks, wireless SSIDs, servers, cameras and any private WAN segments. During migration, overlapping networks or legacy static addressing can complicate the cutover more than the HA configuration itself.

For multi-site organisations, a clean addressing strategy also reduces Auto VPN complexity. Summarised, non-overlapping branch subnets are easier to route and troubleshoot than a collection of repeated RFC1918 ranges inherited from unmanaged sites. High availability is a good opportunity to correct addressing debt if the migration window permits it.

Meraki SD-WAN and Auto VPN resilience

Meraki Auto VPN simplifies the creation of encrypted site-to-site connectivity between MX networks, but high availability still requires thoughtful underlay and hub design. A branch with two WAN uplinks can maintain VPN connectivity when one internet path fails, subject to the configured SD-WAN policy and the reachability of the destination hubs. A branch with an MX HA pair adds resilience against local appliance failure as well.

At the head end, organisations can deploy redundant VPN concentrators or resilient routed hubs. The branch design should consider more than one hub where business continuity requires it. Cloud application traffic may also use direct internet breakout while private applications use the Auto VPN fabric, so the failover plan should distinguish between SaaS access, internet browsing, voice, private data-centre applications and cloud-hosted workloads.

SD-WAN policy is another important design input. Performance classes, VPN traffic preferences and application priorities may behave differently during circuit failure if the surviving path has lower bandwidth or higher latency. A 5G backup link can preserve essential connectivity, for example, but it may not be suitable for the same volume of backup replication, large software downloads or guest internet traffic as a primary fibre circuit. The failover policy should therefore preserve business-critical applications before it attempts to preserve every traffic class equally.

Testing should verify both tunnel establishment and application reachability. A Dashboard indicator showing that an uplink is available is useful, but the business outcome is whether DNS, SaaS, VoIP, remote desktops, cloud applications and internal services continue to work within acceptable performance after the path changes.

Cloud management and what happens if Dashboard connectivity is lost

Meraki networks are managed through the cloud Dashboard, but production packet forwarding is not designed to stop simply because the device temporarily cannot reach the Meraki cloud. Cisco states that Meraki hardware continues to run with its last known configuration when cloud connectivity is lost, until the cloud connection is restored. This is an important distinction between cloud management and the local data plane.

Operationally, however, a cloud disconnect still matters. Administrators may have reduced real-time visibility, new configuration changes cannot be delivered in the usual way and remote troubleshooting can be constrained. The HA design should therefore preserve Dashboard reachability where practical through redundant internet paths and correct appliance uplink addressing.

Administrator access should also be resilient. Organisations should maintain appropriate role-based Dashboard accounts, multifactor authentication, documented organisation ownership and an offboarding process for staff or suppliers. A technically redundant network can become operationally fragile if only one person controls the cloud organisation or if credentials are not recoverable during an incident.

Change control is equally important. Because Meraki makes remote changes easy, production HA networks should use documented maintenance windows, configuration review and rollback planning for changes that affect uplinks, VLANs, routing, VPN or firewall policy. Convenience should not replace governance.

Failover expectations: what users may actually notice

High availability is often described as “seamless,” but buyers should define what that means for their applications. Cisco documents fast VRRP-based takeover for MX hardware and uplink failure conditions, yet application sessions can still be affected by the nature of the failure, path changes, NAT state, upstream provider behaviour, routing reconvergence and the sensitivity of the application itself. A brief network transition may be invisible to web browsing but noticeable to a real-time voice call or a stateful remote desktop session.

The best acceptance test is therefore application-based. Rather than measuring only whether the spare becomes active, the test should observe critical services during the event. Can users resolve DNS? Does the ERP remain reachable? Do cloud phones re-register? Does Auto VPN re-establish? Does the public IP change on a path where external allow lists depend on a fixed address? Do inbound published services remain reachable? These outcomes are more meaningful than a generic promise of zero downtime.

Failback should also be tested. After the failed link or appliance returns, the organisation needs to understand which unit resumes the active role, what happens to sessions and whether monitoring clears the incident correctly. Maintenance workflows should account for planned power cycles, firmware upgrades and device replacement, not only unexpected outages.

Where an application has an extremely low interruption tolerance, network HA may need to be combined with redundant application servers, DNS services, load balancers, data-centre paths and power infrastructure. The network can preserve reachability, but it cannot make a single application server highly available by itself.

Power, rack and environmental resilience

Power design is easy to overlook because it is outside the Dashboard, yet it can determine whether two devices fail together. Where the site has dual electrical feeds, the two MX appliances and redundant switches should be distributed intelligently. Where only one feed exists, UPS capacity should be sized for the required runtime and for the actual load of the network equipment, not just the nameplate rating of one device.

Rack planning should consider physical separation, airflow, cable management and serviceability. If both redundant devices are installed so tightly that replacing one risks disturbing the other’s cables, maintenance itself becomes a failure risk. Labelled WAN, LAN, management, stacking and power cables reduce troubleshooting time during incidents.

For switches that support redundant power supplies, the power architecture can be extended beyond the edge firewall pair. Critical wireless access points, IP phones and cameras may depend on PoE from the switching layer, so switch power loss can affect far more than wired connectivity. A UPS that protects only the MX pair but not the PoE distribution switches may preserve the internet edge while users still lose phones and wireless service.

Dubai environments also make cooling and room conditions relevant. Network equipment should be installed in a suitable conditioned communications room or rack environment within the hardware’s specified operating limits. High availability cannot compensate for both members of a pair overheating in the same unsuitable enclosure.

Migration from an existing firewall or SD-WAN platform

A Meraki HA project often replaces an existing firewall rather than starting from an empty rack. The migration workload can be larger than the physical installation because current rules, NAT objects, VPN tunnels, DHCP services, VLAN gateways, static routes, public IP dependencies and application exceptions need to be understood before they are translated into the Meraki design.

The first step should be discovery. Export or document the existing configuration and compare it with observed usage. Old firewall policies often contain rules for retired servers, temporary projects or forgotten third parties. Migrating every legacy object without review can preserve technical debt. At the same time, deleting an apparently unused rule without application-owner validation can cause an outage. A controlled migration classifies rules as required, obsolete, uncertain or needing redesign.

Public services require particular care. If inbound NAT publishes mail, web, VPN or application servers, the cutover may change the public IP, upstream ARP relationship or provider routing. External partners may have allow-listed the old address. DNS TTL values may need to be lowered before the migration. Remote-access users may need a new hostname or client profile. Site-to-site tunnels to non-Meraki peers may require coordinated changes on both ends.

The HA pair should ideally be staged in Dashboard before physical deployment. Cisco recommends configuring the secondary in Dashboard before it is connected into a routed HA network so that it obtains the intended role and configuration. Staging also allows firmware, organisation settings, network tags and templates to be reviewed before the production window.

A rollback plan should specify exactly what happens if the cutover does not meet acceptance criteria. Keeping the previous firewall configuration, carrier addressing details and labelled cabling available can shorten recovery time. High availability on the new platform does not remove the need for a safe migration process.

A practical implementation journey

Monitoring, alerts and incident response

A failover that nobody notices is better than an outage, but it still needs investigation. If the primary MX fails and the spare takes over, the network may remain usable while the organisation has silently lost redundancy. A second failure could then become service affecting. Meraki allows alerts to be configured for HA failover and other device conditions, so the operational process should route those alerts to people who are expected to act on them.

Incident response should distinguish between restoration and root cause. If the spare is active because the primary WAN circuit failed, the immediate priority may be confirming that critical applications are stable on the surviving path. The next action is to engage the carrier, inspect local handoff equipment and determine whether the path can be restored without destabilising the working service. If the primary appliance itself failed, replacement logistics and RMA procedures become more important.

The Dashboard event log, appliance status, uplink information and network-wide monitoring can help reconstruct what happened. For larger environments, alerts may also be integrated into ticketing, syslog, SIEM or monitoring workflows as permitted by the organisation’s toolset. The purpose is to make a failover an observable event with ownership rather than an invisible condition.

Periodic review should also look for degraded redundancy before an incident. Examples include a second WAN circuit that has been down for days, a stack member that is offline, a UPS with failed batteries, an expired support entitlement or a spare MX that was removed from inventory. Availability is a maintained state, not a one-time installation outcome.

Firmware upgrades and maintenance windows

High availability can reduce maintenance risk, but firmware work should still be planned. The organisation should review Meraki release notes, select an appropriate stable release track and understand the upgrade behaviour of the HA pair and downstream switches. A maintenance window is still appropriate for changes that may affect traffic, reboot devices or alter routing behaviour.

Before an upgrade, confirm that both HA members are healthy, WAN paths are available, Dashboard communication is stable and no unresolved hardware alarms exist. Upgrading while the network is already operating in a degraded state reduces the safety margin that HA is intended to provide. The same applies to switch stacks: a failed stack link or offline member should be corrected before routine maintenance where possible.

Post-upgrade validation should go beyond checking green status icons. Test internet access, key VPN routes, DNS, voice, wireless authentication and critical applications. If the environment uses non-Meraki VPN peers, dynamic routing or custom integrations, verify those explicitly because they may depend on protocol behaviour outside the Meraki platform.

A well-documented HA network makes maintenance easier because the administrator knows which links can be removed, how the spare should react and what success looks like. That operational confidence is one of the practical returns on good design documentation.

Common design mistakes to avoid

When Cisco Meraki HA is a strong fit

Meraki HA is a strong fit for organisations that value central cloud management, consistent policy across multiple sites and a relatively simple operational model. It is particularly attractive when the rest of the estate already uses Meraki MX, MS or MR and the IT team wants one Dashboard view for device status, configuration and troubleshooting.

The model also works well for distributed enterprises where branches need secure SD-WAN and Auto VPN connectivity without maintaining complex per-site routing and VPN configurations. A standard branch blueprint can include dual MX appliances at critical sites, dual WAN, resilient switching and centrally controlled policy, while smaller sites use a lower-cost design proportionate to their downtime risk.

However, not every site requires the same level of redundancy. A small satellite office with a handful of users may be better served by one appropriately sized MX with dual WAN and a documented replacement plan. A headquarters supporting hundreds of users, voice, data centre access and customer-facing services may justify dual MX, dual carriers, redundant switching and redundant power. The value of HA should be compared with the financial and operational cost of downtime.

The correct recommendation therefore depends on business impact rather than on a blanket rule that every firewall should be doubled. FourTeck can provide both HA and non-HA options where a comparison helps the customer decide.

When a different or larger architecture should be evaluated

A Meraki MX HA pair may be only one component of the right design. If the required throughput, interface density, routing complexity, segmentation model or security inspection workload exceeds the target MX platform, a larger MX model or a different Cisco security architecture may be more appropriate. High availability should never be used to justify undersized hardware.

Organisations with sophisticated data-centre routing, very large BGP tables, complex east-west segmentation, specialised firewall clustering requirements or advanced multi-tenant designs should confirm that the intended Meraki feature set matches those requirements. The strength of Meraki is operational simplicity and cloud-managed consistency; a design that depends on highly customised protocol behaviour may need a different platform or a hybrid architecture.

The switching layer may also need a different model if the project requires higher-speed uplinks, modular interfaces, advanced stacking, redundant power or large PoE budgets. Access switch requirements should be derived from endpoint count, PoE class, uplink bandwidth, rack layout and growth rather than simply matching the brand of the firewall.

A balanced proposal should make these boundaries visible. If the requirement sits close to a hardware or architectural limit, the customer benefits from seeing the alternative before purchase rather than discovering it during implementation.

Dubai deployment considerations

A Dubai network project often involves coordination across building management, telecom providers, structured cabling teams, IT stakeholders and security teams. Carrier handoffs may be located in a shared telecommunications room rather than directly beside the customer’s rack. Before the HA topology is finalised, the project should confirm where each circuit terminates, how it reaches the network rack and whether the diverse services remain physically diverse all the way to the customer equipment.

Office relocations and fit-outs introduce additional timing dependencies. The Meraki hardware may be available before the circuits, or the circuits may be installed before the comms room has final power and cooling. A staged plan should therefore separate Dashboard preparation, bench configuration, rack installation, carrier activation and production migration. This avoids using the final cutover window for tasks that could have been completed earlier.

For multi-tenant towers, access to provider rooms and risers may require building approvals. If the HA design depends on a second cable route, that route should be surveyed and approved rather than assumed. Similarly, UPS placement, rack power and grounding should be coordinated with the facilities contractor where required.

FourTeck UAE can support local consultation, supply coordination, staging, installation and migration planning. Buyers can also visit FourTeck UAE for broader UAE technology services and regional contact information.

Use cases for Cisco Meraki high availability

Security policy in an HA design

High availability does not change the need for a disciplined firewall policy. The active and passive MX appliances in the same HA network follow the Dashboard configuration for that network, which helps keep the pair consistent. The more difficult part is ensuring that the policy itself reflects current business requirements and that failover paths do not bypass intended security controls elsewhere in the network.

Segmentation should separate traffic classes where there is a genuine security or operational reason. Corporate endpoints, voice, servers, guest wireless, CCTV, building systems and IoT devices often have different trust levels and access requirements. The VLAN design should be planned together with firewall rules, DHCP, DNS, wireless SSIDs and switch port profiles so that the network remains coherent after failover.

Outbound security services and content controls need to be considered in capacity planning. If the selected Meraki licence tier enables security inspection features, those features may influence throughput and therefore the appropriate MX model. The quote should not assume that a device sized for basic stateful routing will necessarily provide the same performance once additional inspection is enabled.

For regulated or security-sensitive environments, logging retention, syslog export, SIEM integration, administrator access and change records should be included in the solution scope. A highly available firewall that is poorly governed can still create significant operational risk.

Wireless availability depends on the wired network underneath it

Meraki MR wireless access points are distributed devices rather than a pair of physical controllers in the traditional sense, so wireless resilience is approached differently from MX appliance HA. Multiple access points can provide overlapping coverage and capacity, but their availability still depends on PoE switching, VLAN trunks, DHCP, DNS, authentication services and the upstream network.

A business that considers Wi-Fi critical should therefore look at switch redundancy and PoE design. If every access point on a floor is powered by one access switch and that switch fails, the wireless service on that floor can disappear even though the MX pair remains healthy. Where justified, access points can be distributed across separate stack members or redundant switch blocks while maintaining an RF design that avoids unnecessary co-channel interference.

Authentication dependencies matter as well. Enterprise SSIDs may use RADIUS, Active Directory or cloud identity systems. A failover test should verify that users can still authenticate after the network path changes and that the required servers remain reachable through the surviving WAN or VPN path.

This illustrates the central principle of Meraki HA: the service experienced by users crosses several layers. The availability target should be assigned to the service path, then each network component should be designed to support it.

Procurement details that improve quotation accuracy

A useful quotation is more than a line for two firewalls. It should account for the topology that will actually be installed. The most important commercial inputs are the exact MX model or performance requirement, quantity, licensing term, WAN count, circuit speeds, public addressing, switch models, required port speeds, optic types, stacking components, rack accessories and installation scope.

Lead time should be checked for every dependent component, not just the MX appliance. A project can be delayed by a missing stack cable, unsupported transceiver, power module or carrier handoff even when the main devices are already on site. For fibre links, confirm connector type, optic wavelength, distance and whether the carrier presents copper Ethernet or optical Ethernet at the demarcation point.

If the customer already owns compatible Meraki hardware, provide serial numbers and Dashboard organisation details during the design phase. This helps identify whether the proposed pair is a net-new installation, an expansion or a replacement. It also prevents a quotation from accidentally duplicating hardware or ignoring existing licence commitments.

Services should be scoped separately where useful: design, onsite survey, Dashboard staging, configuration migration, rack installation, after-hours cutover, failover testing, documentation, training and ongoing support. This allows the customer to select the level of assistance they actually need.

Support and lifecycle planning

The useful life of an HA design extends well beyond installation day. Hardware support status, firmware support, licensing, replacement procedures and capacity growth should be reviewed periodically. As internet circuits become faster and more applications move to cloud platforms, an MX pair that was comfortably sized at deployment can eventually become a bottleneck even if it is still functioning correctly.

Lifecycle planning should also account for coordinated replacement. Because an MX HA pair uses matching hardware, an end-of-life event can require replacement of both appliances to preserve the pair architecture. Waiting until one old member fails can create a constrained migration if the same model is no longer readily available.

Switch stacks and redundant distribution pairs have similar considerations. Stack compatibility, firmware branches, transceiver support and power modules can change between product generations. Keeping an updated inventory with serial numbers, licences, rack positions and support contacts makes renewal and replacement easier.

A periodic architecture review is therefore valuable even when the network is stable. The goal is to confirm that the original availability assumptions still match the business, the application landscape and the telecom services now in use.

Buyer questions

Decision recap