Let’s start by giving Access some respect. The database that counts as a legacy burden today was a good decision fifteen or twenty years ago: someone in the company built a tool that fit their process exactly, for a fraction of what custom software would have cost back then. That is why these solutions live so long – they work. Until they don’t. If you are reading this, your Access solution has probably reached its limits, and the question is: how do you get out without losing twenty years of data and the company knowledge built into it?

How you know the limit has been reached

The symptoms are strikingly similar from company to company. The file sits on a network drive, and as soon as several people work at once, things stall: records are locked, the application freezes, occasionally Access reports a corrupted database and someone runs the repair function – with a pounding heart. The file keeps growing toward the two-gigabyte ceiling. Working from home only works through detours; access from a phone doesn’t work at all.

And then there is the person question: the whole thing is maintained by the one colleague who taught themselves VBA – or by nobody, because that colleague has retired. You are in large company here: according to the Lünendonk study “IT-Modernisierung zwischen Legacy, Cloud und KI” (2025), half of the companies surveyed report that operating, maintaining and evolving their legacy systems is no longer assured in the medium to long term. At the latest when the IT department asks when “that Access thing” will finally go away, because old Office versions are a security issue, the time has come.

The most important step happens before the first record: taking stock

An Access application consists of four layers, and all four contain business knowledge: the tables with the data itself, the queries, which often hold a surprising amount of logic, the forms with their input rules and the VBA code behind them, and the reports, whose layout customers and the tax advisor may well have grown used to.

Before any migration, all of this gets inventoried: which tables are actually being filled, which queries really run, what does each piece of VBA do? Almost always, this turns up rules nobody had on their radar anymore – the discount that kicks in automatically above a certain quantity, the validation check in a form. These inconspicuous rules are what gets lost in a careless move. Not the data – the rules.

Layer	What it holds	Typical risk during the move
Tables	The data itself, often grown over decades	Duplicates, dates stored as text, orphaned references
Queries	A surprising amount of business logic	Logic gets overlooked and is missing in the new system
Forms + VBA	Input rules, validation checks, small automations	Undocumented rules disappear silently
Reports	Layouts customers and the tax advisor are used to	Recipients suddenly receive different-looking output

The move itself: repeatable, not heroic, with no hard cutover

Moving the data is craft, but craft with a method. Grown Access tables carry typical baggage: duplicates, orphaned references, fields filled differently depending on the year, dates stored as text. None of that gets patched by hand. It is handled in an automated migration routine that can be run as often as needed.

This is the core of the method: the migration is built as a repeatable process and rehearsed until it runs through cleanly. After every run, the results are reconciled – record counts, sums over amounts, spot checks at field level. On switchover day, nothing new happens anymore; it is just the umpteenth run of a routine that has long since proven it works.

Even for a comparatively small Access replacement, we advise against a hard cut. Better: the new application goes live while the old database keeps running for a while, or at least stays available read-only. The team works in the new system but can always check the old one to confirm a number from the past.

The old file gets set to read-only for this period – otherwise two versions of the truth emerge during the transition, and merging them afterwards is more painful than the entire migration. It is only shut down and archived once nobody has looked into it for weeks.

What is better afterwards – and what will feel unfamiliar

The gains are tangible: a real multi-user database instead of a file on a network drive, no locking conflicts, no repair runs, automatic daily backups. Access in the browser, which means from home and from the phone. Roles and permissions, so not everyone can change everything anymore. And an application that is documented and no longer depends on one person.

Honestly, you also lose something: the freedom to tinker. In Access, the savvy colleague could quickly adjust a query or add a column. In a properly operated application, that no longer happens casually – changes go through an orderly path. For the company this is a gain in reliability; for individual power users it initially feels like a loss. Address that openly and involve these people early: they know the application better than anyone and are the best testers you will ever get.

Effort and timeline: an honest assessment

A typical Access replacement – an application with a handful of forms, grown tables, and some VBA logic – is a project of roughly six to twelve weeks for us. The range depends less on the amount of data than on the logic: moving tens of thousands of records is routine; reverse-engineering three hundred lines of undocumented VBA is work.

One more piece of advice: don’t use the replacement as an occasion to overhaul all your processes at the same time. First bring the existing solution cleanly into the new one, so the team recognizes their work – then, on a stable foundation, improve. Doing both at once doubles the risk, and in the end you can no longer tell whether a discrepancy is a migration bug or an intended change.