There's a particular kind of legacy system that runs a real business. It's usually an Access database that grew into an empire. Sometimes it's a VB6 app. Occasionally a FileMaker stack that nobody admits to in public. They have one thing in common: the business runs on them, and the business cannot stop running while you replace them.
We've replatformed three of these in the last two years. The most instructive was a £40M aluminium manufacturer whose entire quoting, scheduling and dispatch pipeline lived in a 15-year-old Access database. One person knew how to keep it alive. Quotes took forty minutes. The team needed them in five.
This is what we learned about doing that without taking the business down.
The temptation to start clean
The first instinct of every engineering team faced with a system like this is to throw it away and rebuild from scratch. It's almost always the wrong instinct.
The legacy system you're looking at is not just code. It's the encoded knowledge of how the business actually works — including the workarounds for problems that have since gone away, the special cases that exist because of one particular customer in 2014, and the seventeen tiny rules that determine whether a quote needs a manager's sign-off. You will not capture all of that in a workshop. You will discover most of it the day after you switch over, when something doesn't work and a senior person tells you "ah yes, the old system did X."
Throwing the old system away on day one means losing that knowledge before you've extracted it. Which leads to the first rule.
Rule 1: Keep the old system live until the new one has earned the right to replace it
For ALUK, we did not write a single replacement line of code with the intent of switching off the Access database. We wrote replacement code with the intent of running the new system alongside the old one for months.
What this looks like in practice:
- New system reads from the same source data where possible. The shop floor's MES doesn't care which app is calling it.
- New system writes to its own database. No risky two-writer setup.
- For each workflow we replaced (quoting, then scheduling, then dispatch), the old system stayed runnable. You could fall back at any point.
- Users moved across one team at a time, not one big-bang weekend.
This is unglamorous and feels slow. It is the difference between a replatforming that works and one that ends with the founder shouting at three in the morning.
Rule 2: Embed in the business before you model the domain
[YOU: confirm — for ALUK I recall we spent the first couple of weeks in their offices watching the quoting team work, before writing requirements. Worth saying so directly if true.]
There is a particular kind of insight you cannot get from a discovery workshop, and it is the insight you most need. It's the difference between what people say they do and what they actually do. Workshops surface the first; sitting next to someone for two days surfaces the second.
The Access database had grown organically because the real workflow had grown organically. People had built spreadsheet macros to work around fields that no longer matched reality. They had standard email templates that quietly encoded business rules nobody had ever written down. All of that is data, and all of it has to go somewhere in the new model.
Our domain model for ALUK's quoting system ended up looking very different from what we'd have drawn after a workshop. It had concepts for "blocking issue raised by sales" and "informal hold pending customer confirmation" that no one had named explicitly, but that everyone was using daily. Those concepts existed in the workflow long before we named them in code.
Rule 3: Re-model the data; do not migrate the schema
Every legacy LoB system has a database schema that is partially a model of the domain and partially an archaeological record of every change the business has been through. Tables named Customer_NEW. Columns called OldRef and OldRef2. Free-text fields that contain three completely different kinds of data depending on the row.
If you migrate that schema as-is into a new system, you are buying the technical debt of the old system with your customer's money. Don't.
What we did instead:
- Built a new data model in the new system, designed around how the business actually works today.
- Wrote a one-way import from the old schema to the new model. Lossy in places, deliberately — old
OldRef2data that nobody had touched in seven years did not make the cut. - Ran the import repeatedly during development. Every weekly demo was on real, current data. By the time we cut over, the import had been exercised dozens of times.
This is more work than a straight schema migration. It pays for itself the first time someone says "right, what does this column actually mean?"
Rule 4: Demo every two weeks, in front of the people who will use it
There is one mistake that kills replatforming projects faster than any other: the eight-month silent build. You take requirements, you go away, you come back with software, the users hate it.
For ALUK we demoed every two weeks to the same group of users. Not stakeholders. The actual people who would use the system every day. The quoting team lead, two members of the scheduling team, the dispatch supervisor.
This produced two kinds of feedback:
- Small things: "this dropdown should have these five options in this order." Trivial to fix in the same sprint. Cumulatively enormous for adoption.
- Big things: occasionally, a fundamental misunderstanding of a workflow. Better to find that in week six than week thirty.
A demo every two weeks also forces you to ship something demonstrable every two weeks, which has its own benefits.
Rule 5: Integrate with the things people already trust
ALUK's old system was bad, but it talked to Sage. It talked to the shop-floor MES. Those integrations were doing real work, and the people downstream of them had built their own habits around them.
When we replatformed, we did not break those integrations. The new .NET system spoke to Sage the same way the old Access system did, on the same schedule, with the same data shapes. The MES integration moved into an Azure Function so we could observe and version it cleanly — but from the MES's point of view, nothing changed.
This matters because the integrations are usually where the business's trust lives. The finance team trusts the Sage feed. The shop floor trusts the MES sync. If you break those, you lose political support for the project faster than anything else.
Rule 6: Cut over by workflow, not by user
The moment of cutover is the moment everyone fears. The way we de-risked it for ALUK was to break the cutover into pieces.
- Week 1 of cutover: quoting moves to the new system. Scheduling and dispatch still on Access.
- Weeks 2-4: stabilise quoting. Triage anything that comes up.
- Week 5: scheduling moves. Quoting and scheduling now on the new system; dispatch still on Access.
- Weeks 6-8: stabilise.
- Week 9: dispatch moves.
This is slower than a big-bang switch. It is also dramatically less risky, because at every point in the sequence, the team has the option to roll back the most recent change without rolling back everything.
The other thing it does: it lets you discover and fix the inter-workflow handoffs before they all matter at once. Quoting hands off to scheduling. Scheduling hands off to dispatch. By moving one at a time, you exercise each handoff in production before the next one arrives.
Rule 7: Document what the old system did, while you still can
The single person who knew how to keep ALUK's Access database alive was not going to be on the team forever. Their knowledge was, in a real sense, the most valuable asset in the project.
We treated extracting that knowledge as a deliverable, not a side effect. Weekly half-hour sessions, recorded, transcribed, summarised. By the time we cut over, we had written documentation for the old system that had never existed in fifteen years of it running the business. Some of that documentation went straight into the new system as code. Some of it became user training material. All of it survived.
What we ended up with
[YOU: the numbers in the case study (quotes 40min → under 4min, full audit trail, Sage + MES live) are accurate as far as I have them — confirm or refine if there are better ones to lead with.]
The headline number is that quotes went from forty minutes to under four. The headline number is not the point. The point is that ALUK now has:
- A system whose code is readable by anyone on the team, not just one person.
- A data model that maps to how the business actually works in 2026, not how it worked in 2009.
- Audit trail on every action — which the FCA-adjacent parts of the business now need anyway.
- A clear, low-risk path to extending the system as the business changes.
The new system is in production and has been for [YOU: confirm — I'd estimate around a year by now? "Eleven months" is in the case study but that was duration to delivery, not time in production].
The meta-lesson
Replatforming a line-of-business system is not really an engineering problem. The engineering is straightforward once you've understood the domain. The hard part is not breaking the business while you do it, and that's a problem of pacing, communication, and respect for the people who already make the business run.
The Access database that runs your client's company is not a joke. It is the documented evidence that the business has been working for fifteen years. Treat it with the seriousness it deserves, and the replatforming will go fine.
Red Owl IT is a Microsoft software consultancy in Bath. We replatform legacy line-of-business systems for SMEs and mid-market businesses across the UK. If you have one of those systems, we'd happily look at it.