Every IT manager in Nigeria has faced the same conversation: a piece of equipment fails, the repair quote arrives, and someone asks whether it would be better to replace it entirely. The instinct is usually to repair, the cost is visible, the alternative seems extravagant, and the budget for replacement was not set aside. But that instinct frequently leads to the wrong decision, and the cost of the wrong decision compounds quietly over time.
A structured framework for the refresh-or-repair question does not guarantee the right answer in every case. It does ensure the question is being asked consistently, with all the relevant factors on the table rather than just the ones that are easy to quantify.
Why the "cheaper to repair" argument is often wrong
The error in most repair decisions is accounting only for the direct cost of the repair and ignoring the indirect costs of keeping ageing equipment in service. These indirect costs are real, they simply do not appear on a purchase order.
Downtime and productivity loss. Ageing hardware fails more frequently, and each failure event carries a cost in lost staff productivity, delayed outputs, and, in some environments, regulatory exposure. A workstation that costs thirty thousand naira to repair but then causes four days of reduced productivity across a team represents a cost that is not captured in the repair bill.
Security exposure. Hardware beyond the manufacturer's support window typically runs software that is no longer receiving security updates. This is not a theoretical risk. Unsupported operating systems and firmware are the attack surface that ransomware and data-exfiltration campaigns actively target. In an environment where NDPR compliance is a legal obligation, running out-of-support infrastructure is not just a technical problem, it is a governance one.
Repair frequency and diminishing returns. A component that has been repaired once has a higher probability of failing again than one that has not been repaired. Each subsequent repair event returns less value per naira spent. At some point, continued repair is a series of down payments on a replacement that was always going to be necessary.
The four-factor framework
A consistent decision process evaluates four factors for every repair-or-refresh decision. Apply them in sequence.
Factor 1: Remaining useful life
How much service life remains in this asset if the repair is successful? An asset with three or more years of expected remaining useful life, assuming the repair restores it to normal operating condition, is a candidate for repair. An asset that, even after repair, is likely to need replacement within twelve months is a poor candidate. You are paying to delay a decision rather than to solve a problem.
The key question is not the asset's age in isolation but its age relative to the manufacturer's support timeline. A four-year-old server that is mid-lifecycle for its product line is a different proposition from a four-year-old laptop that is at or near end-of-support.
Factor 2: Total cost of ownership over the comparison period
Compare the total cost of repair against the total cost of replacement over an equivalent period. The repair option must include not just the direct repair cost but:
- An estimate of increased maintenance frequency over the remaining period.
- The productivity cost of any downtime the asset is likely to generate.
- The security remediation cost, if any, of keeping the asset in service on unsupported software.
The replacement option must include not just the purchase price but freight, customs, deployment, data migration, and any downtime during the transition. In Nigeria, import lead times for hardware can run to several weeks, which is a relevant factor in continuity planning.
Factor 3: Criticality of the asset
Not all hardware decisions carry the same stakes. A workstation used for low-intensity administrative tasks that can be covered by a spare carries different risk from a server running a core banking application or a router at the heart of a hospital network.
For critical infrastructure, the acceptable downtime window is shorter, the tolerance for repeated failure events is lower, and the justification for refresh over repair strengthens accordingly. For lower-criticality assets, repair may be the right call even when it would not be for a mission-critical equivalent.
The question is not just "what does it cost to fix?", it is "what is the cost to the business if this fails again in six months?"
Factor 4: FX and procurement timing
In the Nigerian context, hardware procurement carries a foreign-exchange component for most international-specification equipment. If an asset is likely to be replaced within twelve to eighteen months regardless of the repair decision, a refresh decision made now may benefit from current pricing and lead-time conditions. A repair decision made today and a replacement decision made in twelve months may face a materially different cost environment.
This is not an argument for always refreshing early, it is an argument for including procurement timing and FX exposure in the analysis rather than treating them as exogenous.
Applying the framework: three scenarios
Scenario A, Repair is clearly right. A three-year-old server suffers a failed hard drive. The replacement drive cost is modest, the server is mid-lifecycle with at least three years of expected remaining service, it is running current and supported software, and failure events have been infrequent. Repair is the correct decision.
Scenario B, Refresh is clearly right. A seven-year-old workstation runs an operating system that has passed end-of-support. A power supply failure would cost significantly to repair. Even after repair, the workstation will run software that cannot receive security patches, and it is likely to fail again within eighteen months. The cumulative risk and cost of continued operation exceeds replacement cost. Refresh is the correct decision.
Scenario C, The borderline case. A four-year-old laptop with a failed screen and a battery that no longer holds charge. Repair cost is meaningful. Remaining useful life after repair is estimated at eighteen to twenty-four months. It handles moderately critical work but can be covered by a spare while a decision is made. This is the case where the framework surfaces the trade-offs but the organisation must exercise judgement based on its specific circumstances, budget position, and upcoming refresh cycle.
Building refresh into planning rather than treating it as a crisis
The most practical contribution a framework like this makes is not to individual decisions in isolation, it is to shifting how the organisation thinks about hardware at a portfolio level. An asset register with purchase dates, support timelines, and condition notes makes refresh decisions foreseeable rather than reactive.
Organisations that plan IT procurement systematically, knowing which assets will reach end-of-life in year one, year two, and year three of their planning horizon, are able to budget for refresh in advance, negotiate better terms on volume purchases, and avoid the premium that emergency procurement carries. The repair-or-refresh decision is easiest to make well when it is made deliberately, with time to plan, rather than under the pressure of an asset that has already failed in production.
Working with an experienced technology advisory partner adds an objective lens to these decisions, one that is not influenced by the internal political difficulty of recommending expenditure, or by familiarity with ageing equipment that has gradually become invisible as a risk.
Frequently asked questions
Is there a standard asset age at which refresh is automatically the right decision?
No single age threshold applies across all asset types and operating environments. A well-maintained server in a stable power environment may serve well beyond five years; a workstation subjected to frequent power fluctuations may degrade in three. The framework above, remaining useful life, total cost of ownership, asset criticality, and procurement context, produces a more reliable answer than any fixed age rule.
How do we manage the budget for refresh when it was not planned?
This is where the pain of reactive hardware management is most visible. Emergency procurement costs more, lead times are longer, and the business case cannot be built with adequate time. The medium-term answer is to implement lifecycle tracking now, so future refreshes are foreseeable. The short-term answer is to use a managed procurement partner who can move quickly and whose supplier relationships provide some lead-time advantage.
Should we repair equipment ourselves or always use the manufacturer or a specialist?
For equipment within the manufacturer's support window, using authorised repair channels preserves warranty coverage and ensures the repair uses supported components. For equipment past the support window, authorised repair may no longer be available, and the decision shifts to whether a reliable third-party repair is feasible and cost-justified. In either case, the repair quality must be assessed against the expected remaining useful life, a cheap repair on an asset with twelve months of useful life remaining is a different proposition from the same repair on an asset with three years remaining.
What happens to replaced hardware in Nigeria?
Responsible disposal of IT hardware is a genuine obligation, not an afterthought. Devices that contain data must be securely wiped before disposal or refurbishment. Some equipment may have residual resale value in the local market; some may be suitable for refurbishment and redeployment to lower-intensity uses. E-waste disposal should follow applicable environmental guidance. These considerations should be part of the refresh planning process, not an afterthought when the equipment has already been replaced.
