Rebuild or bridge? What to do with an old Access database

Theoretical Enterprises · September 2, 2026 · 6 min read

Somewhere in a lot of established businesses is a system that works, that nobody wants to touch, and that everyone is a little afraid of. Often it is a Microsoft Access database, a Visual Basic application, or a custom program built by someone who has since moved on. Replacing it feels enormous. Leaving it feels dangerous. There is a middle path, and a way to decide.

First, find out what it actually does

Old systems accumulate behavior. A field that was added for one customer in 2011, a report that finance depends on but nobody else knows about, a nightly process that quietly fixes bad data. Before deciding anything, document what the system really does: the tables and what they mean, every screen and who uses it, every report and who reads it, and every place data comes in or goes out.

This assessment is usually a few days of work and it changes the decision more often than not. Systems that looked like a full rebuild turn out to have two modules that matter and ten that do not.

Three options, not two

The choice is usually framed as rebuild or keep. There is a third option, and it is often the right first step.

Bridge. Leave the old system running and connect it to the new things you need: a web portal, QuickBooks, a reporting dashboard. Access and most old databases can be read directly, so a bridge can pull data out, and often push it back, without changing the old application at all. Lowest risk, fastest payoff.
Migrate. Move the data and the essential behavior to a modern platform, module by module, with the old system still running until each piece is proven. This is how most successful modernizations actually happen.
Rebuild. Start fresh with a new design, migrating only the data. Right when the old workflows are themselves the problem, or when the technology cannot be kept alive safely any longer.

Signs the clock is running

Some situations push the decision from "someday" to "this year".

The system only runs on one machine, on an operating system that no longer gets security updates.
Nobody has the source code, or the only person who understands it is planning to retire.
It cannot be backed up and restored reliably, or nobody has ever tested that it can.
The business needs something the system cannot do: a customer portal, mobile access, a connection to accounting.
Data corruption or lockups are becoming normal. Access files in particular degrade as they grow and as more people use them at once.

Migration is reconciliation, not copying

The part that goes wrong in modernizations is the data. Old systems contain duplicates, orphaned records, dates stored as text, and customers entered four different ways. A migration that simply copies rows carries all of that forward and then breaks the new system in subtle ways.

The right approach treats migration like an accounting close. Decide the rules for cleaning the data. Move it. Then reconcile: record counts, totals by customer and by period, open balances, inventory quantities, all compared against the old system before anyone switches over. Keep the old data readable afterwards, because someone will need to look something up from 2014.

How to keep production running

Nobody can stop taking orders for a rewrite. Run the new system alongside the old one. Move one function at a time, starting with the piece that is riskiest or most painful. Let the two systems share data through a bridge during the overlap. Cut over each module only after the people who use it have run it for real. A modernization done this way has no big-bang weekend, and no point at which the business depends on something untested.