Legacy Access Database Replacement

The Problem

A long-established UK manufacturing business had been running its core operational records on a Microsoft Access database for many years. The database held customer records, order history, production scheduling, and dispatch logs going back a long way, spread across a sprawl of tables, with macros and VBA built up over time by people who had since left 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 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 years ago?”.

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, so we sat with the longest-serving operations staff to capture what each one represented before designing the new schema around it. This data-first ordering is the same discipline that runs through our work on legacy modernisation.

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, with the same field order on the main forms and the 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 operational history migrated from Access. 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. We also retained an archive of the original Access file 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 move off Access ran in parallel with the old database until the team was ready to stop using it. Because the new system is web-based, working away from the office no longer depends on the office network. New starters learn one interface rather than learning Access first.

Historical analysis that was too painful to attempt in Access becomes practical: production trends across several years, customer lifetime value, seasonality. The business can make sourcing and capacity decisions from data it always had but couldn’t easily query.

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 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 here, the same lesson that shows up when we move a team off spreadsheets in our spreadsheet to internal platform migration work, and when the records being preserved are operational procedures rather than orders, as in our internal SOP platform for a distributed team.

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. You can also browse more proof of this kind of work across our case studies.