Retiring Microsoft Access Without Stopping the Shop

There is a very specific kind of call we get. An Access database, built years ago by somebody who has since left, running something the business cannot stop doing. It works on one PC. That PC is old. Everybody knows this is a problem and nobody wants to be the one who breaks it.

This is a solvable problem with a well-worn path, and the path matters more than the technology at the end of it.

Why it got this way

Access is genuinely good at what it was for. Somebody in the business who understood the work built exactly the thing the work needed, without a budget or a project. That is a success story, and it explains why the database fits so well — it was built by a user, not interpreted through a requirements document.

What Access is not good at is twenty years, multiple concurrent users, remote access, and being maintained by somebody who did not write it. The failure is not of judgement. It is of time.

The database is not a mistake. It is a success that outlived its assumptions.

Step one: find out what is actually in there

Before anything else, the whole thing gets documented. Every table, every query, every form, every report, and every macro — including the ones nobody knew were still running.

This stage always turns up surprises. Queries feeding reports nobody reads. A form that is the only way one particular task gets done, used twice a year by one person. Business rules buried in VBA that exist nowhere else — not in a policy document, not in anyone’s memory, only in code.

That last category is the real risk in these projects. Rebuild without finding them and the new system is subtly wrong in a way that surfaces three months later during an audit.

Step two: look hard at the data

Twenty years of data entry leaves residue. Dates as text. The same customer under four spellings. A "notes" field that somebody started using to store a second phone number. Orphaned records pointing at things that were deleted.

This gets found and decided on before migration, not during. Every ambiguous case needs a ruling from somebody in the business, and those rulings get written down. It is the least interesting phase and the one that determines whether the numbers match at the end.

Step three: blueprint, and agree it before code

Old structure mapped to new. Which tables merge, which split, what gets normalised, what stays denormalised because the reporting depends on it. Which screens are rebuilt as-is and which are improved — and improvements are chosen deliberately here rather than accumulating during the build.

You approve this before development starts. It is the last cheap moment to change your mind.

Step four: migrate, prototype, and let people click it

Data moves with validation at both ends — row counts, sums on key numeric columns, spot checks on records people recognise. Then a working front end goes in front of real users, running against real records, before anyone commits to it.

People find things in ten minutes of clicking that no specification review catches. That is the point of the checkpoint, and it is why prototypes save more money than good estimates do.

Step five: parallel run — the part that is worth the money

Both systems live. Work goes into both. Outputs get compared until they agree.

It is duplicated effort and it is unpopular and it is the single most valuable phase. It is where you find that the old system rounded a calculation differently, or that a report excluded a category nobody remembered excluding. Discovering that during a parallel run is a Tuesday. Discovering it after cutover, with the old system gone, is an emergency.

Step six: cutover and handover

Old system read-only rather than deleted, kept for a defined period. Documentation, training, and the credentials — you own the system, the data, and the documentation.

The last part is not a formality. A migration that leaves you unable to change anything without the vendor has moved the dependency, not removed it.

What it does not include

Not every feature comes across, and that is a decision made in the open. Queries nobody has run in five years, reports superseded by other reports, forms for a process that ended. Every one gets listed and consciously dropped rather than silently lost.

And not every Access database needs replacing. Some are fine — single user, stable process, no growth pressure. If that is genuinely the situation, the honest answer is a supported machine, a tested backup, and leave it alone. That answer costs us a project and it is sometimes the right one.

The full process is on the Access migration page, and the scoping quiz will tell you roughly which of these phases is going to carry the risk in your case.