Legacy System Integration for UK Businesses | 2026 Guide

A Sage 50 setup that's been running unchanged since 2014 often doesn't expose a modern REST API — it may have an export button, an old connector, or a workaround that depends on nobody changing the file format. That's a common starting point in the legacy integration projects we scope in London: a business has invested in a modern CRM or a customer-facing portal, and then discovers the old finance or stock system it needs to talk to was never designed to talk to anything.

This isn't a niche problem. It's the default state for UK SMEs that have grown organically over 10–15 years, layering new tools on top of whatever ran the business in 2012. This article covers what legacy integration actually involves, what it costs in 2026, and the specific technical decisions that determine whether a project finishes on time or turns into a six-month saga.

What this article covers

• What "legacy system integration" actually means
• Middleware, not a rip-and-replace
• Where integration typically goes wrong
• Realistic costs and timelines
• AI on top of legacy data — what's realistic
• Security and data handling during migration
• Full replacement instead of integration — when it makes more sense

Key takeaways

• A single-system API bridge for legacy integration typically costs £8,000–£15,000 and takes 6–8 weeks; multi-system middleware projects run £25,000–£45,000+ over 12–16 weeks.
• Most legacy systems like Sage 50, AS/400 installs, or old .NET Framework monoliths were never built with an API — integration means building a translation layer, not flipping a switch.
• A 3–5 day data audit before quoting a fixed price is the single most effective way to avoid mid-project change orders caused by inconsistent legacy data.
• A DPIA is only required for high-risk processing (large-scale profiling, sensitive data, or solely automated decisions with significant effects) — not for every legacy integration project.
• Sometimes integration is the wrong call entirely — unsupported infrastructure or undocumented system logic can mean a rebuild is the safer long-term option.

What "legacy system integration" actually means

It means building a bridge between a system that wasn't designed to be integrated and one that expects modern APIs. In practice this usually falls into one of three shapes: exposing data from an old system via a new API layer, syncing data on a schedule between two systems that will never talk directly, or replacing a manual export/import process with an automated pipeline.

We've built this bridge for AS/400 systems still running UK manufacturing floors, for Sage 200 installations feeding into custom logistics portals, and for .NET Framework monoliths that needed to expose order data to a new customer-facing web app. None of these systems had a REST API. All of them had usable data once you found the right access point — an ODBC connection, a scheduled CSV export, or in one case, a stored procedure nobody had touched since 2016 but which still ran every night at 2am.

Middleware, not a rip-and-replace

The instinct for a lot of ops directors is to assume the old system has to go. It usually doesn't. Ripping out a working ERP that holds fifteen years of transaction history is expensive, risky, and often unnecessary — the better move in most cases is a middleware layer that sits between old and new, translating data formats and handling the awkward bits (retry logic, rate limits, data validation) so neither system needs to change.

This is the approach behind the partner bidding exchange we built for a logistics client — the client's legacy quoting system stayed exactly where it was. We built a middleware layer around it instead of forcing a rebuild.

Where integration typically goes wrong

The most common cause of a legacy integration project running over isn't the code — it's discovering mid-project that the legacy system's data is inconsistent in ways nobody flagged at scoping. Duplicate customer records, inconsistent date formats across a decade of manual entry, product codes that changed meaning in 2019 without anyone updating the old records. A clean-looking export can hide years of manual workarounds.

We always run a short data audit before quoting a fixed price on integration work. It typically takes 3–5 days and it changes the quote more often than clients expect — sometimes down, occasionally up. Skipping this step is the single most common reason a fixed-price integration quote turns into a change order.

Realistic costs and timelines

Legacy integration pricing depends heavily on how many systems are involved and how well-documented (or undocumented) the legacy side is. As an indicative Code Melodies working range: a single-system API bridge — exposing one legacy database to one modern application — typically runs from £8,000, with delivery in 6–8 weeks. A multi-system middleware project connecting an ERP, a CRM, and a warehouse management system, with data reconciliation and error handling built in, moves into the £25,000–£45,000+ range and commonly takes 12–16 weeks.

Final cost depends on project scope, data volume, number of integrations, and ongoing support requirements. A recent example: a middleware project connecting a Sage 200 install to a custom stock management portal was quoted at 10 weeks. It ran to 13 — the legacy database had three different product coding schemes layered on top of each other from previous software migrations, and reconciling them took longer than the actual integration build.

Integration typeTypical costTypical timelineCommon legacy source Single API bridge (one system exposed)£8,000–£15,0006–8 weeksSage 50, Access database, small SQL Server Bi-directional sync (two systems)£15,000–£28,0008–12 weeksERP to CRM, order system to warehouse software Multi-system middleware£25,000–£45,000+12–16 weeksERP + CRM + WMS, AS/400 environments Data reconciliation add-on£3,000–£10,0002–4 weeksInconsistent product/customer records

AI on top of legacy data — what's realistic

Once legacy data is accessible through a reliable API or integration layer, AI workflows become much more feasible — automated invoice matching, demand forecasting from historical sales data, natural-language querying of stock levels. Before that layer exists, most AI ambitions stall, because you can't build a reliable automation on top of a nightly CSV export that sometimes fails silently.

This is a large part of why we treat legacy integration as foundational rather than a separate line item — it's the piece that makes everything downstream possible. Read more about how AI automation fits into this in the April Triple article, which covers where AI co-pilots genuinely add value versus where they add noise.

Security and data handling during migration

Any integration touching customer or employee data needs to be assessed under UK GDPR's accountability principle — not because every project needs formal documentation, but because you need to be able to explain, months or years later, how data moved between systems and who could access it at each stage. A DPIA is required only where processing is likely to result in high risk — large-scale profiling, sensitive data categories, or solely automated decisions with significant effects. Most legacy integration projects don't meet that bar, but it's worth assessing at scoping stage rather than assuming either way.

Security and access control matter more than usual on legacy projects — old systems often have weaker access controls than anything built in the last five years, and the integration layer is frequently the first place those gaps get noticed.

Full replacement instead of integration — when it makes more sense

Sometimes the honest answer is that integration isn't the right move. If the legacy system is on unsupported infrastructure, if the vendor no longer exists, or if the system is so undocumented that nobody in the business actually understands its logic anymore, building a bridge just extends the life of a liability. We've walked clients out of an integration scope and into a rebuild conversation more than once — it's a harder sell in the room, but it's the right call when the old system is the actual risk.

Code Melodies Ltd's bespoke software development services for UK & European businesses cover both paths — integration and rebuild — and the featured projects & case studies page has examples of both approaches in practice. You can also read more about Code Melodies Ltd and how the team approaches legacy work generally.

If your business is sitting on a system that holds the data but not the flexibility you need, a 90-minute discovery session is enough to tell you which of the two paths — integrate or replace — actually fits your situation. Let's talk about your project and get a straight answer before you commit to either.