Replacing Microsoft Access With a Web App (2026)

Somewhere in most established businesses there is an Access database doing far more than anyone intended. It was built by someone competent who has usually left. It runs a real process. And it is accessed through a file link that someone has to re-issue every time the file changes.

It works, right up until it doesn’t.

The symptoms

The database itself is rarely the complaint. What people actually report is a set of consequences:

No real concurrency. Two people editing at once produces conflicts, corruption, or a convention that only one person touches it.
File links that keep breaking. Every update means re-issuing links, and someone is always working from the old copy.
No cloud access. Remote work becomes VPN-and-hope.
Manual workflows around the data. Requests arrive by email, tracking happens in a spreadsheet, and the audit trail is somebody’s inbox.
No integration. The database holds data other systems need, and the transfer is a person exporting a file.

None of these is fatal alone. Together they mean the process has outgrown the tool.

What you are actually migrating

The mistake is treating this as a database migration. The database is the easy half.

The data moves relatively mechanically — Access to SQL Server or PostgreSQL is well-trodden. The work is in what the schema does not say: fields used for two purposes, conventions that live in people’s heads, and the records everyone knows to ignore.

The interface has to be rebuilt entirely. Access forms are tightly coupled to the data, and there is no lift-and-shift path to the web.

The workflows are the part that decides whether the project succeeds. The Access file was usually one component in a process involving email, spreadsheets and verbal convention. Rebuilding only the database leaves the rest of that process intact and the users no better off.

The permissions almost always need to be invented rather than migrated. Access databases typically have one level of access — you can open the file or you cannot. A web application needs to know who may read, who may edit, and who approves.

What the replacement should give you

Working from what we built for SES (formerly Intelsat), whose technical publications database was exactly this pattern — an Access front end and back end, accessed via desktop links, with no cloud hosting and no real-time collaboration:

A proper database behind it. We migrated the Access backend to a custom SQL Server database, which gives concurrency, backups and integration a file share cannot.

A web interface built for the job, replacing the Access front end entirely rather than reproducing it.

Roles that match how the work is done. For SES that meant Administrators, Technical Writers and Reviewers — three distinct levels of access reflecting who does what, in place of a single “can open the file” permission.

The surrounding workflow, not just the data. The rebuild included a redesigned document request form for requesting or revising manuals, and tracking through the review lifecycle. That is the part that removes the email-and-spreadsheet layer.

Integration with the systems that need the data. The new application exports ACT and PCT XML compatible with PTC Windchill, and synchronises product and document metadata with the Oracle Agile database — so the record stops being an island.

You can read the detail in the technical services database case study.

How to approach it

Start with discovery, not a schema. We were engaged initially for discovery and analysis, and the scope expanded to design, development and deployment based on what that found. That order matters: the honest answer to “what does this database do?” is usually larger than the person commissioning the work expects.

Map the process, not just the tables. Sit with the people using it and follow a request end to end. The steps that happen outside the database are where the value is.

Decide about hosting early. Some of these systems can live in the cloud; some cannot. The SES application is hosted on their own infrastructure and accessible only within it, because that is what the content required. Establish this before designing anything, since it constrains everything downstream.

Keep the old system running in parallel. These databases usually hold the only copy of something. Cut over when the new system has been proven, not on a date.

What it is worth

The saving is rarely in the software. It is in what surrounds it: manual effort removed, file-based tools no longer reissued, real-time access instead of a queue, and version control replacing a folder of near-identical copies.

There is also a risk argument that tends to matter more to whoever signs it off. A business-critical process running on a desktop file, maintained by nobody, with no backup discipline and no audit trail, is a single-point-of-failure conversation waiting to happen.

When to leave it alone

Not every Access database needs replacing. If it is used by one person, holds nothing critical, and nobody is waiting on it, replacement is an expensive answer to a question nobody asked.

The trigger is not the technology — it is when the process around the database has grown a workaround for every limitation. That is the point at which the tool is costing more than it saves.

If you have one of these and want a straight assessment of whether it needs replacing, we are happy to take a look.

Replacing a Microsoft Access Database With a Web Application