The 2009 Access file is still running: replacing an Access database gradually

The Access database an intern wrote in 2009 has run your orders for fifteen years, and nobody dares open it anymore. Replacing it all at once is the best way to lose what it knows. Here is an exit plan that keeps it alive during the transition.

Replacing an Access database starts by not replacing it. Keep it running, move out the most painful part first, and only disconnect the old file once the new tool has run alongside it long enough to be trusted.

Why it is still running

A 2009 Access database survives for a simple reason: it does the job. It knows which customer gets which discount, what gets printed at month-end, and which field stays blank when an order comes from a reseller. Nobody wrote down these rules; they live in forms, queries, and the heads of the two people using it. Another, less readily admitted reason is that the database runs on one person's desktop, with an Office version nobody updates for fear everything will stop. The file has become the only copy of how you work, which is why replacing it is frightening.

What the database knows that nobody wrote down

First, extract that knowledge from the file. Open the database and list three things: the input forms people use every day, printed reports sent to someone (a customer, accountant, or owner), and Excel exports someone performs manually. For each line, note who uses it and what would happen if it vanished tomorrow. The list often fits on one page and is worth more than the file itself: it is the raw material for a requirements document, describing what your tool must do, in French, before any code exists.

Move out in pieces, not all at once

Start with the least risky, most troublesome part: viewing and printing. Rebuilding a monthly report in a modern tool breaks nothing if you get it wrong, since the original database remains authoritative. You immediately gain convenience, learn how your data is organised, and discover forgotten rules when the numbers do not add up. Then take the most-used input screen, the one your colleagues know by heart, and reproduce it exactly before trying to improve it: a fifteen-year habit is hard to move. Input shifts screen by screen, keeping the file writable until the new screen proves itself. Taking over ageing software always follows that order, and moving the data deserves its own cleanup pass, just as with a historical Excel file.

Running both, with an end date

For a few weeks, two tools handle the same work and someone compares them. It is tedious and the price of peace of mind: you catch discrepancies before they become an incorrect invoice. Put the old file's shutdown date in writing on day one, otherwise duplicate entry lasts a year and colleagues end up deciding for themselves which tool tells the truth. On the day, make the database read-only instead of deleting it: it becomes a searchable archive, without anyone entering data out of habit.

What a team of agents changes

Explaining this existing setup used to be expensive, because you had to pay a provider to read your database and quote for it. With an agent team you direct, you describe your forms and rules, the agents propose a requirements document you correct, then break the migration into steps you approve individually. The document stays with you, alongside the code, even if you change tools along the way. Maestro, free during beta, can start from existing software instead of a blank page.

Where to start

Tonight, open the database and list its printed reports. Choose the one someone manually rebuilds in Excel every month because the Access output does not suit them. Rebuild that one, and nothing else. Within a week you will know whether a gradual exit is within reach, and you will have broken nothing.