How to Plan a Multi-Site Network Refresh Without Disrupting Operations

Who This Is For

• You carry a hardware estate at or past end of support.
• You run five or more sites whose builds have diverged over the years.
• You hold an uptime commitment that has to survive the refresh window.
• You face an audit that expects a uniform, evidenced control baseline.

The Problem

Most refresh programmes begin as procurement exercises. Finance approves the budget, your team picks hardware, and delivery dates land before anyone has documented what sits in the rack at site 47. Execution then meets the estate as it exists: undocumented VLANs, firewall rules nobody can attribute, cabling that contradicts the drawing, and a branch manager who never heard that the link drops at 02:00.

The same five decisions cause most of the damage:

• You skip the audit, so the design rests on assumptions that hold at head office and nowhere else.
• You design site by site, which multiplies engineering effort and leaves the estate inconsistent after the spend.
• You cut over without a rollback path, so your first failure runs long instead of reverting.
• You mark a site complete when the installer finishes rather than when the device reports healthy.
• You commission monitoring last, so the riskiest phase of the programme runs blind.

Each of those is a planning decision, and you make all five before the first device ships.

Step-by-Step Approach

Step 1 — Audit the estate before you specify anything

Sample sites across every region, size band, and business function, and include head office. Record hardware age and firmware levels, firewall rule variance, topology differences, cabling condition, link utilization against contracted bandwidth, and the physical limits of each site: rack space, power, cooling.

Commission a wireless survey rather than reusing the original design. Floor layouts change, wall materials change, and client density climbs, so a five-year-old coverage plan describes a building that no longer exists. Certify cabling rather than inspecting it. New switching landed on unverified copper moves the fault instead of removing it.

The audit produces one document: what you have, where it deviates, and which deviations you intend to keep.

Step 2 — Fix one reference build, then prove it before you touch a live site

Design one build and apply it everywhere. The specification names hardware models, port maps, the VLAN and addressing scheme, the firewall policy template, the cabling standard, and the labelling convention. Publish it, take network and security sign-off, then freeze it.

Sites will ask for exceptions, and the requests will sound reasonable. Grant capacity headroom to smaller sites instead of a separate design. A frozen specification lets mixed field teams execute the same work hundreds of times without interpretation, and it gives your auditor one baseline to test against rather than fifty. Genuine exceptions do exist. Record each one as a documented variant of the standard, with a named approver, so it stays visible after handover.

Then prove the build before it meets the estate. Run it on a pilot group that includes at least one difficult site: the oldest cabling, the thinnest link, or the tightest maintenance window. A pilot built from easy sites tells you nothing.

Configure and test every device in staging before it ships. Pre-staging compresses on-site work to rack, cable, cut over, verify, which cuts both window length and exposure. It also moves configuration errors into a lab where they cost you an afternoon rather than a branch.

Close this step with a per-site runbook that carries the rollback procedure and the name of the person authorized to invoke it.

Step 3 — Roll out in waves and close each one on verified telemetry

Group sites into waves by region and business criticality, and schedule cutovers inside real low-activity windows. Confirm those windows with the business. Finance month-end, plant shift patterns, and academic terms rarely align with the IT calendar, and the team on site is the last group to hear about a stock count.

Every cutover needs a rollback the on-site team can execute inside the same window. Set the decision point in advance: if the site has not verified healthy by a stated time, the change reverts and you reschedule. Making that call routine removes the pressure to push a failing cutover through to morning. Allocate spare pre-staged units per wave so one dead-on-arrival device does not stall the schedule.

Commission central monitoring before wave one. Every migrated site should report into a single operational view from the moment it cuts over.

Close a wave only when your NOC has validated each site in it: interfaces clean, policy applied, backups captured, alerts flowing, configuration checked into the change record. A finished installation and a working site are two different states, and the gap between them produces the incidents that surface three weeks after handover.

Carry each wave's defect list into the next one, and fix the cause in the reference build rather than at the site.

Common Mistakes

• Ordering hardware before the audit, which locks in models the estate cannot take.
• Designing per site, which turns one engineering effort into fifty and leaves the drift in place.
• Treating the pilot as a formality by choosing the easiest sites available.
• Configuring devices on site instead of in staging, which stretches every maintenance window.
• Scheduling cutovers against an assumed low-activity window rather than a confirmed one.
• Commissioning monitoring at the end, so the highest-risk phase of the programme runs blind.
• Closing sites on installation rather than on verified health.
• Leaving cabling and power out of scope, then landing modern hardware on infrastructure that cannot carry it.
• Allowing undocumented exceptions, which rebuilds the inconsistency the refresh was funded to remove.

Quick Checklist

• Representative sample of sites audited, head office and worst-case location included
• Wireless surveyed and cabling certified
• One reference architecture published, signed off by network and security
• Exceptions recorded as documented variants with a named approver
• Pilot completed on at least one difficult site
• Devices configured and tested in staging before dispatch
• Per-site runbook written, with rollback procedure and decision time
• Maintenance windows confirmed with the business
• Spare pre-staged units allocated per wave
• Central monitoring live before wave one
• Wave closure gated on remote validation of every site
• Configuration backups and change records captured at cutover
• Defects fixed in the reference build, not patched per site

Final Take

The business judges a refresh by how it felt while the work ran. Teams replace estates at national scale when the plan front-loads discovery, holds one standard against pressure, and treats verification as the completion test. Hardware choice ranks last of those three, which is why your schedule and your runbook deserve more review time than your bill of materials.