Every organisation that runs more than a handful of locations eventually faces the same problem: the fleet is ageing all at once. Laptops bought in the same procurement cycle reach end-of-warranty in the same quarter. Switches installed during the last office fit-out begin failing within months of each other. The temptation is to treat this as a purchasing exercise, sign off a budget, order the boxes, and let each site sort itself out. That is precisely how refreshes go wrong.
A multi-site refresh rarely fails on technology. It fails on logistics, sequencing, and the assumption that every branch behaves the same way. The machines are interchangeable; the operating realities of a Lagos head office, an Abuja regional hub, and a Port Harcourt field site are not. The work of a refresh is the work of moving change through an organisation without stopping the organisation.
Start with an inventory you actually trust
You cannot refresh what you have not counted. Most organisations overestimate how well they know their own estate. Asset registers drift: machines get reassigned, peripherals walk between desks, a "decommissioned" server quietly keeps running a payroll job nobody documented.
Before any budget conversation, establish a current, reconciled inventory per site, device, age, warranty status, role, and the business process it supports. That last column matters most. A three-year-old workstation on a reception desk and a three-year-old workstation running a branch's core banking client are the same age and entirely different risks.
The unit of planning in a refresh is not the device. It is the business process the device serves.
This is also where you separate a refresh from a redesign. If the goal is simply newer hardware doing the same jobs, the project is bounded and predictable. If the goal is also to consolidate vendors, change your power and cabling, or move workloads, that is a larger programme, and conflating the two is the fastest way to blow a timeline.
Sequence by risk, not by geography
The instinctive rollout order is geographic: do the head office first because it is nearest, then work outward. This optimises for the project team's convenience and almost nothing else.
A better model sequences by operational risk and reversibility:
- Pilot at a low-risk, representative site. Pick a location large enough to surface real problems but not so critical that a bad day there becomes a board-level incident. Prove your imaging, your network configuration, and your handover script here.
- Roll out to similar sites in waves. Group locations by how alike they are same connectivity profile, same applications, same support model, so each wave reuses the lessons of the last.
- Save the highest-stakes site for last, when your process is boring. The head office, the data centre, the branch that processes the most transactions: these go when nothing about the method is still a question.
Each wave should be small enough that a problem is contained and large enough that you are not still running the project two years later. For most mid-sized Nigerian enterprises, three to six sites per wave with a one-to-two-week gap between waves is a sustainable rhythm.
Pre-stage everything you possibly can
Downtime is created at the desk, not in the warehouse. The single most effective way to protect operations is to push work off the cutover day. Image machines before they leave the staging area. Pre-load applications, certificates, and profiles. Label devices to their destination desk. Pre-provision network ports and switch configurations so a replacement device is a plug-in event, not a configuration session.
A well-staged refresh turns the on-site work into something a branch can absorb in the quiet hours: swap, verify, confirm the user can log in and reach their core applications, and move on. The user should arrive to a working machine, not to an engineer halfway through a build.
Build a rollback that is real
Every wave needs a defined way back. Keep the outgoing device intact and reachable until the new one is confirmed in production for an agreed period, typically a full business cycle for that site. "We can rebuild it" is not a rollback plan; a labelled, powered-down, still-configured predecessor machine is. The cost of holding old hardware for two extra weeks is trivial against the cost of a branch that cannot transact on a Monday morning.
Treat handover and training as part of the deployment
A refresh that leaves users confused has not finished, however many boxes were delivered. Each cutover should end with a short, scripted handover: the user confirms they can log in, open their core applications, print, and reach shared resources. Anything unresolved is logged and owned before the engineer leaves the floor.
Where a refresh changes how people work, a new operating system, a different collaboration suite, relocated peripherals, fold lightweight training into the rollout rather than treating it as a separate project that never gets scheduled. This is exactly the discipline our deployment and implementation practice is built around: installation, configuration, testing, and training treated as one accountable handover, not four disconnected steps.
Hold one partner accountable end to end
The hidden cost in most multi-site refreshes is coordination. Hardware comes from one supplier, cabling from another, the network team is internal, and the branch managers answer to a fourth chain of command. When something slips, the finger-pointing begins and the timeline dies.
A single accountable partner, responsible for procurement, logistics, deployment, and the support that follows, removes that seam. It is also what makes the enterprise and multi-branch model work in practice: one plan, one schedule, one number to call when a wave hits a problem.
A workable shape for the whole programme
Pulling it together, a refresh that protects operations tends to follow this arc:
- Reconcile the estate and tie every device to a business process.
- Decide refresh versus redesign, and resist scope creep between them.
- Sequence by risk and reversibility, in contained waves.
- Pre-stage aggressively so cutover days are dull.
- Confirm with a scripted handover and a real rollback per wave.
- Account for the whole thing through one partner, not four.
Done this way, a refresh stops being an event the business braces for and becomes something it barely notices, which is exactly the point. The measure of a good refresh is not how new the hardware looks. It is how little anyone outside IT remembers it happening.
