Most IT budgets are not wrong because somebody estimated badly. They are wrong because of how they are shaped. A budget is built as an annual operating line, roughly level with last year, while the largest costs in technology are cyclical and arrive all at once.
A laptop fleet bought in the same quarter reaches end of support in the same quarter. A server generation ages out together. A platform migration is a single year’s expense supporting five years of work. Level a budget year over year and you have not avoided those costs, you have guaranteed that one year in four or five becomes a crisis, and crisis spending is always more expensive than planned spending.
This IT budgeting guide covers the six costs that most often break the plan, and how to shape a budget that absorbs them.
What the Benchmarks Actually Tell You
The commonly cited range is that smaller businesses spend somewhere between four and six percent of revenue on technology, and the figure moves a good deal by sector. Financial and professional services sit higher, healthcare in the middle, and light manufacturing or retail lower.
Treat that as a sanity check rather than a target. If you are spending well under the range for your sector, you are probably deferring something that will arrive later. Well above, and you may be carrying tool redundancy or oversized cloud. What the benchmark cannot tell you is whether this particular year should be high or low, which is exactly the question that matters, because a refresh year legitimately should be high. Our overview of what IT strategy is and why it matters covers how that connects to planning.
1. The End-of-Support Cliff
The largest single hardware item facing many smaller businesses right now is not a failure, it is a date. Windows 10 reached end of support in October 2025, which means machines still running it receive no security updates. Any device in your fleet that cannot run Windows 11 is not an upgrade candidate, it is a replacement.
What makes this a budget problem rather than a purchase is concentration. Companies buy laptops in batches, so they hit this line together, and the bill lands in one year for a machine population accumulated over several.
Two things help. Inventory the fleet by capability rather than by age, since some newer machines fail the requirement and some older ones pass. And sequence replacements by exposure, starting with anyone handling client or financial data, so the security risk closes first even if the spend spreads over two budget periods.
2. Refresh Treated as Replacement on Failure
The second cost is the habit that creates the first. Equipment gets replaced when it dies, which feels prudent and is more expensive than a cycle.
Reasonable planning cycles are roughly four to five years for laptops and workstations, and five to seven for servers, switches, and firewalls. For network equipment, security-patch support matters more than age, so a device the vendor no longer patches is at end of life whether or not it still forwards packets.
Replacement on failure costs more in three ways that never appear as a line item. The failure happens at the worst moment, so you pay for expedited hardware. The person is unproductive while it is sorted. And you lose the negotiating position that comes from buying a planned batch instead of one urgent unit. A rolling cycle where you replace a predictable share of the fleet each year converts a lumpy capital problem into a steady line, which is the single most useful change most SMB budgets can make.
3. Licensing That Escalates Quietly
Third is software, and it moves in one direction. Per-seat licensing rises with headcount, so a growing business sees its software line climb without any decision being made. Vendors also move customers up tiers, sometimes because a feature you now depend on was reclassified into a higher plan.
Two specific traps. Seats for people who left, which is remarkably common and pure waste. And plan changes that arrive as an improvement, where a capability you were using moves to a tier you were not on.
Budget software against projected headcount rather than current, review the seat count against your actual staff list at renewal, and check tier changes when they are announced rather than when they are billed.
4. Cloud You Are Not Using
Fourth is cloud waste, and industry estimates consistently put more than a quarter of cloud spending on resources that are unused or oversized. That is not a failure of cloud, it is a consequence of how it gets provisioned: generously, at project time, by someone sizing for a peak that never arrived, with nobody owning the review afterwards.
The pattern repeats. Storage from a migration completed two years ago. A test environment nobody switched off. Instances sized for a launch that stayed quiet. None of it is visible as waste, because it all appears as one cloud bill that is broadly what you expect.
The remedy is scheduled rather than clever: a quarterly review of what is running, what it costs, and who needs it, with a named owner per resource group. Migrations are where most of this originates, which our piece on the hidden costs of cloud migration goes into.
5. Project Labour and Downtime
Fifth is the gap between a project’s price and its cost. Software and hardware carry a visible number. Implementation carries labour, data migration, testing, retraining, and a period where people work more slowly because the tool changed.
Downtime during a planned change is a real cost that rarely gets counted. So is the productivity dip after it, which lasts longer than most plans allow, because people who were fast in the old system are slow in the new one for weeks.
Budget projects with an implementation allowance rather than a licence cost, and schedule changes away from your busiest period even when that delays the benefit. A migration during your peak trading month can cost more in lost work than the entire project saves in a year.
6. The Cost of Not Budgeting
The last cost is what the previous five turn into when they are not planned. Emergency remediation, unplanned downtime, and the productivity loss around each incident, none of which appears in any budget line while all of it comes out of the same money.
Network-related outages cost small businesses over a thousand dollars per incident on average once lost work is counted, and a genuine security incident is a different order of magnitude again. This is why security and recovery are the worst possible places to economise, even though they are the easiest to defer since nothing visibly breaks when you do. Our business continuity planning work exists for precisely this line item.
There is a counter-intuitive version of this worth reading, which is that constrained technology budgets sometimes need to increase rather than tighten. Our case study on what to do when budget restricts your technology spend works through that reasoning, and the dermatology practice case study shows what planned rather than reactive spending produced.
How to Shape a Budget That Holds
The structural fix is to stop budgeting the year and start budgeting the cycle:
- Split the budget into run and change. Run is the predictable monthly cost of keeping things working. Change is projects and refresh. Mixing them is why a refresh year looks like overspending rather than like the plan working.
- Carry a refresh reserve every year, including quiet ones. Set aside a share of the eventual replacement cost annually so the refresh year draws on accumulated provision instead of arriving as a shock.
- Give the plan a three-year horizon. One year is too short to see any of the cyclical items, which is the whole problem.
- Name what you are deferring and when it comes due. Deferral is legitimate and normal. Undocumented deferral is how it becomes an emergency.
- Review quarterly against actuals. Cloud, licensing, and headcount all drift, and a quarterly check catches the drift while it is still small.
A budget shaped this way is not larger than a level one over five years. It is the same money arranged so that no single year contains a crisis, and it makes IT a predictable line rather than an argument. This is one of the main things a strategic advisor should be producing, as our explainers on aligning IT strategy with a growth plan and what a vCIO is set out.
If you would like help turning your current spend into a three-year plan with the cycle built in, book a free strategy call.
Frequently Asked Questions
What percentage of revenue should a small business spend on IT?
Commonly cited ranges put it between four and six percent, varying by sector, with financial and professional services higher and retail or light manufacturing lower. Treat it as a sanity check rather than a target, since a refresh year should legitimately run above your normal range.
How often should we replace laptops and servers?
Plan roughly four to five years for laptops and workstations and five to seven for servers, switches, and firewalls. For network equipment, vendor security-patch support matters more than age, so a device no longer receiving patches is at end of life regardless of whether it still works.
Why does our IT budget keep getting blown by surprises?
Usually because it is shaped as a flat annual line while the biggest costs are cyclical and land together. A fleet bought in one batch reaches end of support in one batch, so a level budget guarantees that one year in four or five becomes a crisis.
What is the most commonly wasted IT spend?
Cloud resources that are unused or oversized, which industry estimates repeatedly place at more than a quarter of cloud spending, along with software seats still billed for people who have left. Both accumulate quietly because they appear inside a bill that looks roughly as expected.
Should we ever cut security spending to balance the budget?
It is the worst place to economise, because nothing visibly breaks when you defer it, which is exactly why it gets chosen. Emergency remediation and downtime come out of the same money, and a single serious incident costs far more than the protection you deferred.
