Why Access files stop working

Most businesses that set out to replace a Microsoft Access database are not chasing something new. They are reacting to a file that used to work fine and now gets in the way every day. Access was built for one person or a small team on one office network, and it does that well. The trouble starts when the business grows past it.

These are the usual signs:

  • One person at a time. Access can share a file among a few people on a local network, but records lock, screens slow down, and people end up taking turns. An Access database with multiple users was always fragile, and a few more staff can break it.
  • Corruption on a shared drive. An Access file on a network share can be damaged when a connection drops mid-save. Someone runs “Compact and Repair”, restores last night’s copy, and hopes nothing was lost.
  • No remote or phone access. Access runs on Windows desktops. Staff in the field, at home or on a phone can’t use it without remote desktop workarounds.
  • The one person who understands it is leaving. Many Access databases were built by an employee who taught themselves VBA years ago. When that person retires, nobody knows why the invoice button does what it does.

You can live with any one of these. Two or three together usually mean it is time to plan a replacement before a bad week forces one on you.

What is really inside the file

Take stock before you compare options. An Access file is not just a database. It is usually five things bundled together:

  • Tables: the data itself, such as customers, jobs, invoices and parts.
  • Queries: saved questions, like “open jobs this month.”
  • Forms: the screens people type into.
  • Reports: printed or exported outputs, such as invoices and monthly summaries.
  • Macros and VBA: the code that runs when someone clicks a button, plus business rules that were never written down anywhere else.

A useful first exercise is to list every form, report and button that people actually use, and who uses each one. Old files often contain dozens of objects nobody has opened in years. Those don’t need to move.

Why the VBA does not carry over

Tables move easily, and almost any database can take them in. VBA is different. It is written for Access and runs only inside Access, so it cannot run in a web browser or on a phone. No converter turns it into a working web app.

That code still matters, because it holds your business rules: how a discount is calculated, what happens when a job closes, which fields are required. Each rule has to be read, understood and rebuilt in the new system. This is usually the largest and least visible part of the work, and it is the part most worth getting right.

Three ways to replace a Microsoft Access database

There is no single right answer. Here are the three common paths and when each one fits.

1. Keep Access as a front end on a server database

You move the tables into a proper server database, such as SQL Server or a cloud equivalent. The Access forms and reports stay in place and point at the new database. This is what people usually mean by “migrate Access to SQL.”

It fits when the main pain is corruption and shared use, everyone works in the office on Windows, and the forms do their job.

Watch for what it leaves unfixed. You still have no browser or phone access, and the VBA still needs someone who understands it. Some queries also run slower over the network until someone rewrites them. This path is a sensible step, but it is often not the last one.

2. A low-code database tool

Hosted tools let you build tables, forms and simple automations in a browser without writing code. Many teams look at these first when searching for a Microsoft Access alternative.

It fits when the database is mostly lists and forms, the logic is simple, and you accept the vendor’s pricing model and limits.

Watch for rules that don’t fit. Complex VBA logic often can’t be expressed in the tool’s automations, so it gets dropped or done by hand. Reports may not match what your customers expect. Your data and your process also live on someone else’s platform.

3. A custom web app

You turn the database into a web app built for your business. It has a real database underneath, screens that work in a browser and on a phone, logins with the right permissions, and your business rules rebuilt properly. This is the usual route from an Access database to a web app.

It fits when the database is central to how you run, the rules are specific to you, people need it outside the office, or you want it connected to other systems such as accounting.

Watch for the upfront effort. It takes more work at the start than the other two paths, and the result is only as good as the builder’s understanding of your process. Choose a builder who asks how work actually flows, not just which fields are on the forms. Our guide to what drives the cost of custom software explains how this kind of project is scoped.

A rough way to choose:

  • If the problem is the file, take path one.
  • If the problem is the tool and your needs are simple, take path two.
  • If the business has outgrown both, take path three.

How the data moves

Whichever path you choose, moving the data follows the same careful steps. Rushing this stage is how businesses lose years of history. A dedicated data migration effort usually covers these steps:

  1. Clean first. Old Access files collect duplicate customers, misspelled names, blank required fields and dates typed as text. Decide which records to merge, fix or archive before anything moves.
  2. Add the missing relationships. Access often lets tables drift apart, so you find things like an invoice pointing to a customer that was deleted. A proper database enforces these links, which means orphaned records have to be found and resolved.
  3. Move the data, then prove it. Compare row counts table by table. Then compare the totals that matter, such as invoice sums by year, open balances and stock counts. The new numbers should match the old file exactly, or every difference should be explained.
  4. Rehearse. The first trial move always finds surprises. Repeat it until the move is predictable.

Running both side by side, then switching off

Don’t switch over on a Monday morning and hope for the best. For a short period, run the old file and the new system together. Staff do real work in the new system while the old file stays available, so you can compare results.

During that period, check the outputs that matter most. Invoices should match, month-end reports should agree, and everyone should be able to do their daily job. Fix gaps as they appear.

When the two systems agree and people are comfortable, take these final steps:

  • Do one last data move.
  • Make the old file read-only.
  • Archive a copy somewhere safe.

Then actually stop using the old file. A system that is “mostly retired” keeps picking up new data that never makes it across.

Illustrative example: a 15-year-old database in a small office

Illustrative example: a hypothetical eight-person property maintenance company has run on one Access file since 2011. The file tracks properties, work orders, technicians and invoices.

The company is feeling the strain on three fronts:

  • The office manager who built the file is retiring.
  • Technicians phone in job updates because they can’t reach the file from the field.
  • The file has been restored from backup twice this year.

Their inventory turns up about forty tables, but only twelve are in active use. Six forms are used daily. Of the reports, only the invoice and the monthly owner statement really matter. One VBA module calculates after-hours rates and flags overdue jobs.

They weigh the three paths:

  • A server database would stop the corruption but leave technicians on the phone.
  • A low-code tool could hold the work orders, but the rate rules and owner statements would be awkward to rebuild there.
  • A custom web app would let technicians update jobs from their phones and the office see changes immediately.

They choose the custom web app. The rate rules are rebuilt and checked against a year of past invoices. Duplicate property records are merged and orphaned work orders are fixed. Both systems then run through one month-end close. When the owner statements match, the old file goes read-only and into the archive.

Where to start

You don’t need a finished plan to begin. Write down four things:

  • What the database does.
  • Who uses it.
  • What breaks.
  • What you wish it did.

Then list the forms, reports and buttons that matter. That list alone makes any conversation with a builder far more productive.

If the custom route looks right, here is how we work. Nadwell AI is a custom software development studio in Denver, Colorado, working with businesses across the United States, and we have built more than 20 projects for our clients.

A fixed quote comes first. We break your software into small working pieces and price each one, and nothing is built until you pay the deposit. Every client project is built in its own private sandbox, with its own repository, environments and access. The full sequence runs from idea to interview, quote, decomposition, follow-up and deposit, and our process page explains each step.

Tell us about your Access database

Tell us what your Access database does today, who relies on it, and what you need it to do next. Rough notes are fine. Describe your project through our start form, and we will follow up to talk it through.