Why this matters
Switches and firewalls sit in the path of every packet. A switch replacement changes VLANs, trunks, spanning tree, link aggregation and Power over Ethernet. A firewall replacement changes routing, network address translation, VPN tunnels, security zones and inspection. One missed trunk or one missing NAT rule can take down phones, cameras, Wi-Fi, payment terminals and factory systems at the same time.
Older gear also hides design debt. Firewall rules get added for one project and never removed. Switch ports go undocumented. A replacement forces you to see the mess and decide what to keep. That is good if you plan for it and painful if you do not.
How to plan switch and firewall replacements is a staging project, not a shopping exercise. The goal is to limit the blast radius. Replace one closet or one firewall pair at a time. Know what depends on each unit. Have a rollback that you have tested. Plan the work so a failed cutover costs minutes, not a full weekend.
Before you start
Collect facts before you pick models. For each switch, record the model, serial number, firmware version, support end date, port count, PoE budget, uplink type, stacking cables and licenses. For each firewall, record throughput, session capacity, interface count, high availability state, VPN tunnel count, ISP handoffs, public IP addresses and certificates. Export the running configuration and the startup configuration to text. Save them outside the device.
Draw the topology. Show each closet, rack, uplink, redundant path, power circuit and UPS. Label every cable. Map VLANs to subnets and to business owners. Map firewall zones, static routes, dynamic routing neighbors, NAT rules, VPN peers and published services. List the systems that depend on each rule or VLAN. If nobody owns a rule, mark it for review.
Decide the scope. A like-for-like swap is lower risk because the design stays the same. A redesign can fix bottlenecks and clean up rules, but it adds testing and change control. Choose a cutover unit: one access switch, one stack, one floor or one firewall pair. Check lead times for transceivers, direct attach cables, rack rails and power supplies. Confirm rack space, power draw and cooling. Get the maintenance window approved before you order.
How to do it
Build a staging rack or use a lab. Load the new configuration on the new hardware. Compare old and new command output for VLANs, trunks, spanning tree, routing and policy. Test PoE devices, link aggregation, firewall high availability sync, VPN tunnels and NAT. Fix problems in staging, not at midnight.
Cut over in small units. Move one access switch or one firewall pair at a time. Keep console access through a local cable or a console server. Keep the old configuration and the old hardware available until the new unit has passed checks. Use the steps below as the working order.
- Build the as-built record. Export running configurations, port maps, VLAN lists, firewall rules, NAT tables and VPN settings. Photograph racks and label every cable. This record becomes your rollback baseline.
- Choose the target design. Decide between a like-for-like swap and a redesign. Size PoE, uplinks, firewall throughput, interface count and high availability. Pick models that are in support and have spare optics available.
- Map ports and policies. Create a port-by-port and rule-by-rule mapping from old to new. Mark rules with no owner or no hit count for review. Include NAT, routing, VPN and certificates in the map.
- Order hardware and optics early. Buy spare power supplies, transceivers and cables with the switches. Check lead times and compatibility before you commit. Confirm rack space, power and cooling.
- Stage and test the new gear. Load configurations in a lab or staging rack. Test VLAN trunks, PoE, routing, high availability sync, VPN and policy. Compare old and new logs and counters.
- Set the cutover and rollback plan. Pick a window per closet or firewall pair. Write the rollback steps and keep old configurations offline. Assign a console operator and a tester.
- Cut over in small batches. Move one access switch or one firewall pair at a time. Verify links, VLANs and traffic before the next unit. Keep the old gear powered off but intact.
- Validate and watch. Run the checks in the next section. Watch logs, errors and alerts for the first hours. Register support and schedule configuration backups.
How to check it worked
Check the physical layer first. Look at link lights, negotiated speed and duplex, interface errors, PoE draw and transceiver readings. Check spanning tree root and topology. Check link aggregation bundles. Test VLAN reachability and DHCP relay on each subnet. Confirm that phones, access points and cameras power up and register.
Check routing and policy. Verify routing neighbors, route tables, firewall high availability sync, session tables and NAT translations. Test each VPN tunnel and each published service. Check that logging reaches syslog or your SIEM. Look for denied traffic that should be allowed and allowed traffic that should be denied. Compare rule hit counts with the old device where you can.
Run a failover test. Pull power on one firewall in the pair and confirm that sessions continue. Test a switch stack member or an uplink failure if the design supports it. Confirm that monitoring alerts fire and that backups run. Keep the old gear powered off but intact until you have watched the new gear through a full business cycle.
Mistakes to avoid
Do not copy the firewall rule base without review. Old rules hide shadowed rules, unused objects and temporary exceptions. Copy as-is only for the first cutover if you must, then clean up with owners and hit counts. Do not forget NAT, VPN, certificates and routing. A firewall is not just an access control list.
Do not lose out-of-band access. If you rely on the network to reach the network gear, a bad cutover locks you out. Use a console server, a local console cable or a backup path. Keep spare transceivers, patch cables and power supplies on site. Confirm that the new optics match the old ports and the fiber type.
Do not undersize PoE or uplinks. Add up the draw from phones, access points and cameras, then leave headroom. Check uplink speed and oversubscription between access and core. Confirm stacking or redundancy behavior before you depend on it. Check that the new switch supports the same spanning tree mode and link aggregation method.
Do not skip rollback and monitoring updates. Keep the old configuration offline and the old hardware ready. Update monitoring, SNMP, syslog and backup jobs to the new addresses. If you need an independent inventory and refresh plan, the Hardware and endpoint review from Cloudverg is a $4,500 fixed price option among others.
Frequently asked questions
How long does a switch and firewall replacement take?
It depends on the number of closets and firewall pairs. A single access switch can cut over in a short window, while a firewall pair needs more testing for rules, NAT and VPN. Plan weeks for preparation and small cutover windows per unit.
Can I replace a firewall without downtime?
Yes if you have a redundant pair and can fail over to the new unit in a staged way. A single firewall needs a maintenance window because sessions and VPN tunnels drop. Test the failover path before the real cutover.
What should I check before replacing a core switch?
Check spanning tree root, VLAN trunking, link aggregation bundles, routing adjacencies and PoE budget. Confirm the new switch supports the same optics and stacking method. Have console access and a rollback configuration ready.