Skip to main content
DATANOVATECHNOLOGIES

Legacy Modernization

Replacing Microsoft Access With a Web Application

Access applications usually need replacing for operational rather than technical reasons: they run on Windows desktops, the file sits on a share that must be reachable, concurrency is fragile, and the person who built the forms has left. The realistic replacements are a web application over a real database, or a low-code platform when the workflow is standard.

8 min readUpdated

When the constraints are biting and splitting the back end is not enough, Datanova helps businesses rebuild it as a custom web application.

Why Access becomes a problem

Access did something genuinely valuable: it let people who were not developers build a real data application with forms, queries and reports. Many of those applications have been running the business for fifteen years. The problems are almost all about where it runs and who can maintain it:

  • Windows desktop only — no Mac, no browser, no phone, and remote work means VPN or a remote desktop
  • The file lives on a network share, so anyone using it needs to reach that share
  • Concurrency is limited, and a dropped connection can corrupt the file
  • There is one copy and usually no version control or meaningful backup discipline
  • VBA behind the forms, undocumented, written by someone who has left
  • Licensing and deployment friction on every new machine

The realistic options

OptionWhen it fitsEffort
Split the back end to SQL Server, keep the formsThe forms are fine and the pain is corruption or concurrencyDays to weeks
Low-code platformStandard workflow, modest user count, already on Microsoft 365Weeks
Custom web applicationUnusual logic, many users, remote access, integrations, audit needsMonths
An off-the-shelf productThe Access app reimplements something a vendor already sells wellConfiguration, not building

The first row is the option most teams skip. Moving only the data to SQL Server while keeping the existing forms fixes corruption and concurrency for a fraction of a rebuild, and buys years of time.

Migrating without stopping the business

  1. Inventory what is actually used. Access applications accumulate abandoned forms, queries and reports; a good share of what looks like scope is dead.
  2. Extract the schema, then fix what Access allowed — spaces in field names, lookup fields, inconsistent types. The schema is the easy part and rarely transfers cleanly as-is.
  3. Extract the VBA behind the forms and read it. That is where the business rules live, and it is the real specification for the replacement.
  4. Ask the users what they do outside the application. Every long-lived Access app has a step people handle in Excel because the form never supported it.
  5. Rebuild against the current outputs — reports and exports are the test cases.
  6. Run both in parallel for a few weeks, then make the Access file read-only rather than deleting it.

What you gain, and what you lose

Worth being even-handed, because teams are sometimes disappointed by the trade:

  • Gain: browser access from anywhere, real concurrency, per-role permissions, audit history, proper backups, integrations
  • Gain: the application stops depending on one machine and one person
  • Lose: the ability for a power user to add a query or tweak a form themselves in an afternoon
  • Lose: a single file you can copy as a backup
  • Lose: zero hosting cost

That third point is the one people feel most. Access made changes cheap because the person who wanted the change could make it. A web application makes changes safer and slower. When the ability to self-modify is genuinely valued and the constraints are not biting, that is a legitimate reason to stay.

Frequently asked questions

Is Microsoft Access discontinued?

No. Access ships with Microsoft 365 and remains supported. The pressure is practical rather than end-of-life: it is Windows desktop only, it does not run in a browser, and the pool of people who maintain Access applications keeps shrinking.

Can we just move the Access database to SQL Server?

Often yes, and it is the most underrated option here. Splitting the back end to SQL Server while keeping the existing forms removes file corruption and concurrency limits in days to weeks. It does not give you browser access or fix undocumented VBA, but it buys real time.

How long does replacing an Access application take?

For a single-purpose application with a handful of forms, typically 6 to 12 weeks. Larger applications that accumulated a decade of features run longer, and most of the variation comes from reconstructing undocumented VBA rather than from building screens.

Will we lose our data?

Not if the migration is run properly. Access data exports cleanly and the schema transfers with known adjustments. Keep the original file read-only after cutover rather than deleting it — the cost of storage is nothing against the cost of needing a record you discarded.

Running the business on an Access application?

In a free consultation we look at what the application does, what is actually still used, and which of the four options fits — including when moving only the back end buys you the years you need.