Skip to main content

Case Study

Legacy Access Database Replacement

Migrated a long-established business off a 20-year-old Microsoft Access database to a modern web platform — full history preserved, zero downtime.

Digital Royalty

May 27, 2026
Industry Case Study
Focus Custom Development
Year 2026
Published May 27, 2026

The Problem

A long-established UK manufacturing business had been running its core operational records on a Microsoft Access database for nearly two decades. The database held customer records, order history, production scheduling, and dispatch logs going back to the early 2000s — well over a million rows across thirty-something tables, with macros and VBA built up over the years by three different people, none still with the business.

The system worked, mostly, but the constraints were tightening. Access required users to be on the office network, which made the team’s recent shift to partial remote working clumsy. The database file had grown to a size where opening it took several minutes and where the periodic “compact and repair” was treated with superstition. New starters who had never seen Access struggled with the interface. And the IT manager had a recurring nightmare about the day the file became corrupted in a way the backup did not catch.

The business was nervous about replacing it. Every previous conversation with software vendors had ended the same way — quotes for “starting fresh” with a generic ERP, plus the implication that twenty years of granular order history was not worth migrating. That history was not optional for the business; it was how they answered questions like “what did we ship that customer in 2014?”.

The Approach

We treated the data as the priority and the application as the second priority. Step one was a complete extract from Access into a clean relational schema — preserving every row, every relationship, and the operational meaning behind the more unusual columns. Several fields were undocumented but loaded with meaning; we sat with the longest-serving operations staff to capture what each one represented before designing the new schema around it.

Once the data was modelled cleanly, we built a Laravel web application on top of it. The interface deliberately mirrored the muscle memory of the Access front-end where it made sense — same field order on the main forms, same tabbed organisation on the customer record — so existing staff did not have to relearn their job alongside learning a new tool. Where Access habits were genuinely working against the team, we redesigned, but we picked those battles carefully.

The System We Built

A Laravel web application with PostgreSQL behind it, holding the full twenty-year operational history migrated from Access with no data loss. Role-based access from any location, replacing the office-network dependency. A reporting layer producing the same standard reports the team had built up in Access plus the ones they had wanted but the Access skills had not stretched to. An archive of the original Access file retained in read-only form for the first year, accessible from the new system, so anyone wanting to verify a migrated record against the original could do so.

The Outcome

The team moved off Access over an eight-week parallel-run period. By the end, nobody was opening the .mdb file. The remote-working friction disappeared because the new system is web-based. New starters now learn one interface rather than learning Access first.

The data benefits emerged more slowly. Historical analysis that had been “too painful in Access to bother with” became routine — production trends across multiple years, customer lifetime value calculations, seasonality patterns. The business is making sourcing and capacity decisions from data it always had but could not previously interrogate.

What We Learned

The vendors who had previously quoted on this project had been wrong to dismiss the historical data. The business’s operational confidence came in large part from being able to look up what had happened five or ten years ago, and any replacement that lost that history would have failed regardless of how good the new front-end was. Treating the data as primary and the UI as secondary was the right ordering.

Trapped on Access or Another Legacy Database?

If your business runs on a Microsoft Access database that has aged past the point where it is fit for purpose but holds data you cannot lose, get in touch to talk through what a careful migration would look like.

Ready to Start Your Project?

Tell us about the challenge you are facing and we will explore how we can help.

Discuss Your Project View All Case Studies