A file called Database_FINAL_v3.accdb
Somewhere on a shared drive there is an Access file that holds your customers, your jobs, your stock or your quotes. Someone built it years ago, probably a keen member of staff or a relative of the owner, and it has grown ever since. It works, mostly.
The trouble shows up in small ways. Two people cannot edit the same record without one of them getting a locking message. The file has to be compacted every so often or it slows to a crawl. Nobody can open it from home without remoting into an office PC. When it corrupts, and it does, someone restores last night's copy and the team retypes the morning's work.
And there is the quiet fear underneath: if this file breaks properly, the business stops.
Why the database is harder to leave than it looks
The tables are the easy part. The data in an Access file can be exported in an afternoon. What keeps businesses stuck is everything around the tables that nobody wrote down.
- Saved queries that feed the reports people rely on, some of them chained three or four deep
- VBA macros behind buttons that recalculate prices, generate document numbers or send emails through Outlook
- Validation rules buried in form properties rather than in the tables
- Linked tables pointing at spreadsheets or other Access files on someone's C drive
- Business rules that exist only as habits, like "never delete a customer, just tick Inactive"
Previous attempts to replace it usually failed because they started from a fresh design and forgot half of this. The new system looked better and did less, so people kept using the old one.
What staying put is costing you
The cost is rarely a single disaster. It is a steady drip of friction and risk.
| Symptom | What it means day to day |
|---|---|
| Record locking and conflicts | Staff wait for each other or overwrite each other's changes |
| Office-only access | Remote staff ring in for information instead of looking it up |
| Periodic corruption | Lost work, restores from backup and retyping |
| One person maintains it | Changes wait for them, and stop entirely if they leave |
| No audit trail | When a figure is wrong, nobody can see who changed it or when |
There is also the growth ceiling. Access has a hard file size limit and it was never meant for many simultaneous users. As the business grows, the database gets slower at exactly the moment you need it most.
How we move you off it
Our approach treats the Access file as the specification. We do not ask you to describe the system from memory; we read what it actually does.
- Inventory. We open the file and list every table, relationship, query, form, report and macro, and trace which ones are still used. Dead objects are common and are left behind.
- Rule extraction. Each piece of VBA and each query with logic in it gets written out in plain English and checked with the people who use it. This becomes the acceptance list.
- Data model. We design a proper relational schema in PostgreSQL or SQL Server, usually on Azure or AWS, fixing the duplicated fields and free-text columns that should have been lookups.
- Migration scripts. The data moves by repeatable script, not by copy and paste, so we can run it as many times as needed and compare the output with the source row by row.
- Front end. We build a browser-based application whose screens follow the layout your team already knows, with proper user logins, permissions and a change history on every record.
- Parallel running. For a period both systems run. Reports from each are compared, differences are explained, and only then does the old file become read-only.
If the Access front end is genuinely liked, there is a middle option: move the data to a server database and keep Access as the front end temporarily, linked to the new tables. That removes the corruption and locking problems first and buys time for the rest.
What changes once it is done
People log in from a browser, in the office or anywhere else, and several can work on the same customer at once without trampling each other. Every change is recorded against a name and a time. Backups happen on the server without anyone remembering to copy a file.
The reports still come out, because they were on the acceptance list. The rules the macros used to enforce are still enforced, now in code that is documented and can be changed by someone other than the one person who wrote the original.
And the old file sits in an archive folder, read-only, in case anyone ever needs to check what it said.
Signs this is where you are
- Your core records live in an .accdb or .mdb file on a shared drive
- Staff see locking messages or have to wait for someone else to close a form
- You have restored the file from backup more than once
- Only one person understands the macros behind the buttons
- Remote staff cannot use it without remoting into an office machine
- A past attempt to replace it stalled because the new system did less