The person who built the Microsoft Access database your business depends on has left the company. The database still works, but nobody wants to touch it because nobody knows what might break. That is a stressful situation, especially when the database handles customers, orders, invoices, scheduling, inventory, or some other part of the business that absolutely cannot just stop working on a Tuesday morning.
The good news is that a working Access database is not automatically a disaster just because its developer is gone. You do not need to immediately throw it away, move everything to the cloud, hire a full-time IT department, or become a VBA programmer yourself. You need to protect what works, find out what you actually have, and make a sensible plan before something forces you to make a rushed decision.
First, figure out whether you have an emergency or a planning problem. If people cannot enter orders, print invoices, run payroll, or access critical information today, then deal with that specific failure first. This is not the time to launch a grand modernization project while somebody is waiting on month-end reports.
But if the database is still doing its job and the concern is simply that nobody knows how to maintain it, then you have something valuable: time. A working system gives you breathing room to investigate carefully, preserve what is important, and decide how to support it going forward.
Before anyone changes anything, find the actual pieces of the system. In many Access applications, the file employees open contains the forms, reports, queries, buttons, and VBA programming. That is commonly called the front end. The actual business data may be somewhere else entirely, often in a separate Access database file on a shared network folder. It might also be in SQL Server, SharePoint, Excel files, or some other data source.
Do not assume that the shortcut on somebody's desktop is the whole system. That shortcut is usually just the front door. You need to know where it leads.
Find the application files, the data files, and the backups. Identify which employees or company accounts can access them. If the database uses a shared drive, make sure it is really a company-controlled shared drive and not a folder on the former employee's workstation that everyone quietly depended on for years.
You should also find out whether an editable development copy exists. Access developers often distribute an ACCDE file to users. An ACCDE is a compiled version of an Access application that users can run but cannot easily modify. The editable development version is normally an ACCDB file. If the ACCDB file is available, protect it. If it is missing, look through backups and company storage first. If appropriate, contact the former developer and ask whether they have a copy.
A missing editable source file does not necessarily mean the system must be rebuilt, but it does mean you should get an experienced Access developer to assess the situation before anyone makes big promises. There is a big difference between "this is inconvenient to maintain" and "this is impossible to maintain."
Next, look for the things around the database that may not be obvious. Access applications often depend on more than just tables, forms, and reports. They can rely on linked spreadsheets, network folders, imported text files, scheduled tasks, printers, email accounts, Outlook settings, external databases, and services configured under a particular employee's login.
Maybe somebody downloads a spreadsheet every month and saves it in a particular folder so Access can import it. Maybe a button emails invoices through an account nobody else knows the password for. Maybe a report pulls information from a file on an old computer under someone's desk, next to three years of coffee cups and a printer that has not worked since 2019.
Those are all dependencies. They are the supporting pieces your database expects to find. You do not have to understand every technical detail immediately, but you should make a simple list of what people know. Document important folders, recurring imports and exports, automated emails, special reports, outside services, and anything that happens on a schedule.
This is how you avoid discovering six months later that the month-end process stopped because an account was disabled when the former employee left.
Now let us talk about backups, because this is where a lot of businesses get a false sense of security. You want backups of both the application and the data. If your database is split, backing up only the front end is not enough. Backing up only the back end is not enough either. You need both.
More importantly, test the restore process. A backup that has never been restored is like a spare tire you have never checked. It may be there. It may also be flat, missing, or belong to a lawn mower.
Restore a copy somewhere safe and make sure it opens. Make sure the data is present. Make sure users can perform the basic tasks they need to perform. Record where the backups are stored, who can access them, and what date they represent. Keep an off-site copy too, whether that means cloud storage, another location, or a properly managed backup service.
Also, do not let someone experiment directly on the live database. The live system is called production, because that is where the real work happens. Production is not where we conduct science experiments. Preserve a known-good copy first, then let any investigation, repair, or development happen in a separate test copy.
Your employees also know more about the system than they may realize. They might not know VBA, table normalization, or the difference between an inner join and a left join, but they know how the business uses the database every day. That knowledge is incredibly valuable.
Have key employees demonstrate their normal work. Record or document how an order is entered, how an invoice is printed, how a customer return is handled, how a special price is applied, and what management expects from end-of-month reports. Pay special attention to exceptions, workarounds, and those little steps that everyone knows but nobody has ever written down.
A strange-looking button on a form may appear unimportant to a new developer. Then someone explains, "Oh, that is how we handle our largest customer's special shipping arrangement." Suddenly that odd button is not so odd anymore.
This is business documentation, and it is different from technical documentation. Business documentation explains what people do and why. Technical documentation explains how tables, queries, forms, reports, and code work together. Eventually, a future developer needs both. But do not wait for perfect documentation before getting help. Perfect documentation is a mythical creature, right up there with the empty inbox.
If possible, look inside your company for someone who is interested in becoming the internal point person. This does not mean the business owner has to become an Access programmer. Running the business is already enough work. But perhaps you have an office manager, bookkeeper, operations person, or power Excel user who enjoys figuring things out.
Someone who already understands the business has a major advantage. They know what a correct invoice looks like. They know which report causes panic on the last business day of the month. They know what the staff means when they say, "It is doing that thing again."
An interested employee can start by learning the Access basics: tables, queries, forms, reports, and some basic troubleshooting. They may eventually be able to handle simple tasks, answer routine questions, and communicate more effectively with an outside developer. Do not expect them to instantly inherit a complicated application full of old VBA code and undocumented business rules. That would be like handing someone a wrench and declaring them an automotive engineer.
For many small businesses, the best long-term arrangement is a combination of internal and outside help. The internal person understands the business and can coordinate requests. The outside Access developer handles repairs, complicated programming, database design, and larger changes.
If you need outside help, look for someone with experience taking over existing Access applications. That is a different skill from building a shiny new database from scratch. A good developer should begin by understanding what exists, preserving what works, identifying risks, and helping you make informed decisions.
Ask practical questions before there is an emergency. How do they communicate? What information will they need? What is their availability for urgent issues? How do they handle support requests? Can they provide same-day help during business hours if that matters to your business?
Do not assume that a consultant is automatically available at 9:00 on Monday morning because something broke over the weekend. If your business needs rapid response, discuss that expectation before the day you need it.
It is also reasonable for an experienced developer to charge for an assessment. An unfamiliar Access application may contain years of forms, reports, queries, VBA code, linked tables, hidden dependencies, and business rules that were never documented. What appears to be a simple request on the surface can have consequences throughout the system.
However, make that assessment a defined purchase. Ask what the developer will examine, how the fee is determined, what spending limit applies, and what you will receive when the assessment is finished. You should come away with useful information: a basic system overview, known dependencies, immediate risks, missing files or credentials, and recommended next steps.
Even if you decide not to continue with that particular developer, you should be in a better position than when you started. If the proposal is vague, ask questions. If the price seems unreasonable, get another opinion. Compare the work being proposed, not just the largest number at the bottom of the estimate.
One thing to watch out for is turning a maintenance concern into an unnecessary replacement project. You may hear that Access is old, everything needs to move to the cloud, or you need to throw away the current system and build a modern web application. Maybe you do. But "maybe" is not a business case.
Ask what actual problem a replacement is supposed to solve. Is Access failing to meet a real business requirement? Is the current design fundamentally broken? Are there security, performance, remote-access, or support issues that cannot reasonably be addressed? Or does the consultant simply prefer a different platform?
The same standard works both ways. Keeping Access should be a deliberate decision based on whether it still serves your business well. But replacing it has costs far beyond making prettier screens. Someone has to understand the old business rules, migrate the data, test the new system, train employees, and recreate all those important little workflows that nobody remembered until they vanished.
A modern-looking web page is not automatically an equivalent business system.
Finally, use this experience to prevent the next knowledge gap. Assign someone internally to coordinate database information. Keep company-owned credentials, support contacts, backups, documentation, and source files under company control. Do not let essential access live only in one person's memory or personal account.
The goal is not to create one new keeper of all the database secrets. The goal is to make sure the knowledge belongs to the business. If the person who understands the system is unavailable tomorrow, somebody else should know where the files are, how the backups work, who provides support, and what the database is supposed to do.
If your Access developer has left but the database is still working, do not panic. Protect it. Document it. Back it up. Find the dependencies. Capture the business knowledge your staff already has. Then build a support plan that combines internal coordination with outside expertise when necessary.
That is usually a much smarter first move than tossing a working system into the dumpster just because the person who built it is no longer in the building. Watch the embedded video for the full discussion and a few more practical considerations.
Live long and prosper,
RR
No comments:
Post a Comment