Legacy Software Modernisation: What to Do With the 2012 System Your Business Still Runs On

Quick answer

Somewhere in most established businesses is The System — the Access database, the bespoke Windows app from a developer who retired, the ancient CRM everything secretly depends on. It still works, which is why it is still there; and it is quietly accumulating risk: unsupported platforms, one person who understands it, data locked inside. The modernisation menu has four options — wrap it, migrate the data to off-the-shelf, rebuild it, or retire it into a bigger platform — at UK costs from a few thousand to £50,000+. The universal rule: never big-bang. Every successful modernisation runs old and new in parallel; most horror stories start with a hard cutover date.

The risk signals that say “act now, not eventually”

• Key-person risk: one employee (or one retired contractor on a goodwill basis) is the only person who can fix it. Businesses run years on this arrangement, then lose it in a week.
• Platform death: it needs an OS, browser plugin or runtime that vendors no longer patch — a security and compliance problem, not just an inconvenience, once customer data is involved.
• The workaround economy: staff maintain shadow spreadsheets because the system cannot do what the business now does — the signal that the system stopped fitting years ago (and a cousin of the problems in the spreadsheet escape guide).
• Data imprisonment: you cannot get reports out, connect it to modern automation, or answer questions the business now asks. Data you cannot use is inventory you cannot sell.
• It blocks growth plans: the new branch, the webshop, the acquisition — and the answer to “will the system cope?” is nervous laughter.

The four options, honestly priced

The commonest mistake is defaulting to rebuild out of sentiment — “our system is special” — when migration analysis shows the market caught up a decade ago. The second commonest is the opposite: forcing a genuinely distinctive workflow into generic software and losing the edge that made the business work. The decision discipline is the same as custom vs off-the-shelf, applied with archaeology.

How the successful projects actually run

1. Document before deciding. Nobody fully knows what The System does — including the person who runs it. Two or three days mapping its real workflows, hidden rules and data quirks reshapes the option choice more often than not.
2. Free the data first. Whatever option you pick, step one is automated, repeatable exports into a modern database — instantly reducing key-person and platform risk while you decide the rest. Often this is a small integration project in its own right, and sometimes it turns out to be all you needed.
3. Parallel-run, always. Old and new side by side for two to eight weeks, reconciling outputs, before the old one is demoted to read-only archive (kept a year; never deleted at launch).
4. Phase by workflow, not big-bang: move quoting first, then jobs, then reporting — each phase small enough to roll back, each one banking value before the next begins. This is the shape of every modernisation we run through the custom software service.

The cost of “it still works”

Do the honest sum: hours lost to workarounds and re-keying, opportunities the system blocks, the realistic cost of an emergency migration after failure (2–4× a planned one, plus downtime), against the modernisation quote. “It still works” is usually the most expensive option on the menu — it just bills you invisibly, in instalments.

The discovery phase, and why paying for it separately protects you

The single most useful thing you can buy before committing to any of the four options is a paid discovery — a fixed-scope piece of work that produces documentation rather than software. In the UK this typically runs £1,200–£4,000 for a small business system, or three to eight days of a developer or analyst’s time, and it should deliver five things you can hand to any supplier afterwards:

• A written map of every workflow the system performs, including the ones staff do not mention because they are automatic.
• A data inventory: tables, record counts, field-level quality, and the free-text fields where the real business logic has been hiding for a decade.
• The integration list — what feeds it, what it feeds, and what breaks if it stops.
• The rules embedded in it: pricing tiers, discount logic, VAT handling, approval thresholds. These are the crown jewels and they are almost never written down anywhere else.
• A risk register with the key-person and platform exposures named explicitly.

Commission this from someone who will not be bidding to build the replacement, or at minimum insist that the documentation is yours to take elsewhere. Discovery bought inside a fixed-price rebuild quote tends to discover, remarkably often, that a rebuild is required. The output also doubles as the foundation of the specification you will send out for quotes — the anatomy of which is set out in how to brief a software project, and a properly documented legacy system produces the tightest, cheapest quotes most owners will ever receive.

Migration costs, itemised

“Move the data across” is where budgets break, because it is quoted as a task and delivered as an archaeology dig. A realistic breakdown for a system holding, say, 12,000 customers and 40,000 job records:

Two rules save real money here. First, migrate less: agree a cut-off — live customers and three years of jobs move; everything older becomes a read-only archive you can query but need not transform. Halving the migration scope routinely halves this entire table. Second, clean before you migrate, not after, and do the cleaning with your own staff where possible; nobody knows which of the four “Smith Builders” records is the live one better than the person who invoices them.

The hidden costs of leaving it alone

The existing system rarely appears on a cost line, which is exactly why it survives. Go looking and it usually has one:

1. Infrastructure kept alive for one application. An unsupported server, a legacy database licence, a VPN, or a machine under a desk that nobody dares reboot. £600–£3,000 a year is common, and the extended-support surcharges on end-of-life platforms are deliberately punitive.
2. Insurance and contract exposure. Cyber insurers increasingly ask directly about unsupported software, and commercial customers with security questionnaires ask too. An honest answer can raise a premium or lose a tender; a dishonest one can void the cover.
3. The retention obligation. HMRC expects business records to be retrievable for six years, and “the system it lived in no longer runs on any computer we own” is not a defence anyone wants to test. Whatever route you choose, the archive must remain readable, not merely stored.
4. The recruitment tax. New staff take longer to become productive on an idiosyncratic old system, and the good ones notice during the interview.
5. Ongoing maintenance you are already paying informally — the retired contractor’s occasional invoices, the internal firefighting hours. Compare it honestly against what a supported modern system costs to keep running, which is set out in what maintaining custom software really costs, because the comparison is frequently closer than owners expect.

The contract clauses that decide whether this happens again

Every legacy nightmare was once a new system built without these terms. Insist on them now:

• Source code ownership or full escrow, stated in writing, with the repository accessible to you — not “we’ll give it to you if anything happens”.
• Documented database schema and an export routine delivered as part of the build, tested at handover. If you cannot get your data out on day one, you never will.
• No single-person dependency: ask who else at the supplier could pick this up, and require that the answer is not “nobody”.
• Standard components over exotic ones. The reason 2012 systems are unmaintainable is usually an unusual framework, not old code as such.
• An exit plan clause: what happens, at what cost, if you leave. Suppliers who resist this are telling you something useful.

Where the middle path fits

Between “wrap it” and “rebuild it” there is a route that suits a surprising number of small businesses: rebuild the parts staff touch daily as a modern browser-based tool, and leave the reporting and archive where they are. Quoting, job scheduling and site data move to something usable on a phone at 7am; the year-end reports keep running off the old database until they are retired naturally. The reason this works is that most of the pain in a legacy system is concentrated in a handful of screens used a hundred times a day, and rebuilding just those as a web application banks most of the benefit for a fraction of the full-rebuild cost.

It is also worth pricing a no-code or low-code assembly for the simpler half of the workload before assuming bespoke development — some legacy systems are, underneath the intimidating interface, a form, a list and a report, and the honest comparison of that route against custom build is laid out in no-code versus custom development. The failure mode to avoid is deciding by folklore: “we tried something like that once” is not analysis, and the tooling in this space has changed more in three years than the legacy system has in fifteen.

Sources & Further Reading

• Small Business Cyber Security — NCSC
• UK GDPR Guidance — ICO
• Business Record Keeping — GOV.UK