Start with the current system, not the assumed design
The invoice from your hosting provider or infrastructure supplier is the most visible cost of a legacy system, but it is usually the smallest. The true cost of keeping an older application running is distributed across your team’s time, your product roadmap, and your operational efficiency. For business owners and operations managers, understanding this distribution is the first step towards making an informed decision about modernisation.
Legacy running costs generally fall into four categories:
- Direct maintenance and infrastructure: The ongoing spend to keep the servers powered, the databases stored, and the underlying software libraries patched. As frameworks and operating systems reach the end of their supported lives, this infrastructure often becomes more expensive to host because it requires specialised environments or older hardware.
- Knowledge silos: When a system is built on older technology, the pool of developers familiar with that stack shrinks. If your business relies on one or two contractors to fix issues, their daily rate effectively becomes a core running cost of the application. If they leave, the cost of replacing that knowledge is substantial.
- Operational drag and workarounds: Legacy systems frequently lack modern integration capabilities, such as RESTful APIs. When your system cannot talk to your accounting software, your CRM, or your reporting tools, your staff compensate. They export spreadsheets, re-key data, and manually reconcile records. The cost here is measured in wasted salary hours and the errors that manual processes introduce.
- Opportunity cost: Every hour your internal developers or external suppliers spend keeping an old system alive is an hour they cannot spend building new features, improving customer experience, or automating other parts of the business. This is the hardest cost to quantify, but it is often the largest.
Understanding these categories in the abstract is useful, but the costs become tangible when you apply them to specific business functions.
| Assessment area | What to establish | Evidence to retain |
|---|---|---|
| The bespoke CRM scenario | Consider a UK business running a ten-year-old bespoke CRM. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
| The customer portal scenario | A SaaS founder wants to introduce a new subscription tier to their customer portal. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
| How to measure your own costs | To move from guesswork to a practical assessment, ask your team to track their time for a single month. | Documented assumptions, exclusions, ranges, approval limits and actual-versus-plan reporting. |
| Limitations of cost analysis | You cannot perfectly quantify every downside of a legacy system. | Documented assumptions, exclusions, ranges, approval limits and actual-versus-plan reporting. |
The bespoke CRM scenario
Consider a UK business running a ten-year-old bespoke CRM. The system functions correctly and the staff know how to use it. However, it cannot integrate with modern cloud accounting software. An operations manager spends two hours a day exporting data, cleaning it in a spreadsheet, and uploading it to the finance team.
The hosting bill for the CRM might be relatively low. But if that manager’s fully loaded employment cost is £35 per hour, those two daily hours represent an illustrative £18,200 per year in direct operational cost—before accounting for the inevitable data entry errors that require further time to resolve. The legacy system is not broken, but it is actively draining operational budget.
The customer portal scenario
A SaaS founder wants to introduce a new subscription tier to their customer portal. The portal was built on a framework that is no longer actively maintained. The founder approaches a development agency for a quote. Because the codebase is undocumented and relies on outdated dependencies, the agency must allocate significant discovery time just to understand how to make a safe change. The quote for a simple feature is disproportionately high, and the timeline is extended. The cost here is delayed revenue and inflated development invoices.
How to measure your own costs
To move from guesswork to a practical assessment, ask your team to track their time for a single month. Separate time spent on "keeping the system running" (bug fixes, server issues, manual workarounds) from time spent on "moving the business forward" (new features, process improvements). Compare this split to the cost of a modern alternative or a targeted rebuild. Even a rough time audit reveals whether your legacy system is a cheap utility or a hidden tax on your operations.
When evaluating whether to continue maintaining a legacy system, businesses frequently make a handful of predictable errors.
Confusing stability with low cost. A system that does not crash is not necessarily cheap to run. If it takes three weeks and a specialist contractor to approve a simple process change, the business is paying a heavy price in lost agility. Stability is a requirement, but it does not equal efficiency.
Treating modernisation as an IT problem. Because the costs of a legacy system are spread across different departments—developer time in one budget, manual admin work in another—the total figure is rarely visible to a single decision-maker. The operations team absorbs the workaround costs, while the IT budget absorbs the maintenance costs. Without consolidating these figures, the business cannot make an accurate build-versus-buy or build-versus-modernise decision.
Ignoring the cost of inaction. Deferring a modernisation project is an active decision to continue paying the hidden costs for another year. Assuming the system will be replaced "next year" without budgeting for the transition simply guarantees another twelve months of operational drag.
Limitations of cost analysis
You cannot perfectly quantify every downside of a legacy system. Staff frustration with a clunky interface contributes to higher turnover, which carries recruitment and training costs, but linking a specific resignation directly to a piece of software is difficult. Treat the costs you can quantify—developer hours, manual workarounds, hosting premiums—as a minimum baseline. The true cost is almost certainly higher.
Key checks to run now
- What proportion of your development budget is spent on new features versus maintaining the existing system?
- Is there a single point of failure in your team’s knowledge of the codebase?
- What are the annual salary costs of the manual tasks your staff perform to compensate for the system’s limitations?
- If you needed a non-trivial change delivered next month, what would the quote and timeline look like compared to a modern platform?
Turn the assessment into a controlled next step
Answering these questions does not automatically mean a full rebuild is the right next step—sometimes a targeted modernisation or integration layer is more appropriate. But until you understand what the legacy system is actually costing your business across all these areas, you cannot accurately compare it to the cost of replacing it.