Inherited Access databases
Your Access developer left. Now what?
Somewhere in your company there is a Microsoft Access database that runs something important. Invoicing, scheduling, check writing, inventory, a report the owner reads every Monday. The person who built it is gone: retired, moved on, or passed away. Nobody left in the building understands how it works. And this morning, or last week, or three months ago, it started misbehaving, or somebody asked for a change nobody knows how to make.
If that is why you are reading this page, here is what I want you to know first: this situation is common, it is fixable, and it is almost never as bad as it feels. I have spent fifteen-plus years working on exactly these applications, and this page tells you what to do right now, what not to do, and what a specialist actually does with an inherited Access database.
First things first
What to do right now
Make a copy of the database file, today, before anything else happens. Find the file, or the two files if there is a "front end" on each PC and a "back end" on a shared drive, right-click, copy, paste, and put the copies somewhere safe. Do this even if everything currently works. An Access database with no backup and no developer is a business running without insurance, and a copy costs you two minutes.
Then write down what the database does for you, in business terms. Who uses it, what they use it for, what would stop happening if it stopped working. You do not need to understand how it works. The what is enough, and it is the first thing any specialist will ask you.
If the database still works, resist the urge to have someone poke around inside it. Access will happily let a curious employee open things that should not be opened, and I have seen more damage done by well-meant exploration than by the original problem.
Common mistakes
What not to do
Do not assume the application must be replaced. The reflex answer from most IT consultants is "Access is obsolete, you need a rewrite," followed by a proposal with a lot of zeros and a timeline measured in years. Sometimes a rewrite is genuinely the right call. Far more often, the application that has quietly run your business for fifteen years needs stabilization and documentation, not replacement, at a small fraction of the cost. Be suspicious of anyone whose diagnosis is "replace it" before they have looked at it.
Do not hand it to a general programmer. Access with VBA is a specialty. A talented web or .NET developer confronting an inherited Access application is a talented mechanic confronting a piano: capable hands, wrong instrument. They will be slow, expensive, and tempted to conclude it should be rewritten in something they know.
And do not wait for the next failure. The best time to bring in help is while the application still mostly works. Every problem is cheaper to fix before it takes the invoicing down on the last day of the month.
The work
What a specialist actually does
The first engagement is usually an assessment. I take a copy of your database, read the code the departed developer left behind, and map what the application actually does: the tables, the logic, the reports, the scheduled jobs nobody remembered existed. You get that back in plain English, a document your company owns, so the knowledge that lived in one person's head now lives on paper.
From there the work is whatever the situation calls for, and nothing more. Fixing the errors users have been clicking past for months. Making the fragile parts sturdy. Adding the change that was requested before the developer left. Setting up proper backups. Moving the data to SQL Server if the application has outgrown its back end. Documenting as I go, so you are never again dependent on what one person remembers.
The money question
What this costs
Less than you fear, and I will tell you before we start. Most inherited-database situations begin with a bounded assessment measured in hours, not weeks, and the assessment tells both of us what the application needs before you commit to anything further. You will never get a surprise invoice or an open-ended engagement you did not agree to. Compare that with the cost of the application failing during month-end close, or with the rewrite proposal, and the math tends to make itself.
The short version
Copy the file. Then email me.
Copy the file today. Write down what it does for your business. Do not let anyone experiment on it, and do not sign a rewrite proposal reflexively. Then send me a short description of the application and what happened, and I will tell you honestly what I think it needs, including if what it needs is not me.
rob.evans@evanscoapps.com