Converting an MS Access database to a web app: four real options

You can move a Microsoft Access database to the web in four ways: keep Access as the front end and move the data to SQL Server, stream the desktop app through a browser, rebuild it on a low-code platform such as Power Apps, or have a custom web application built. None of them is a one-click conversion. The right choice depends on who needs access and from where, how much logic lives in VBA, and how long the tool has to last. In every case, the data and the hidden business rules matter more than the screens.

This guide is written for the business owner or operations lead who inherited an Access database the company now depends on, and who wants a clear picture before talking to vendors.

Why Access databases hit a wall

Access has done remarkable work. Somewhere in your company, a resourceful employee built an order tracker, a job log or an inventory system in a few weeks, and the business has run on it ever since. The problem is not Access. It is what the business now asks of it.

Documented technical limits

Microsoft's own Access specifications (checked November 6, 2026) cap a database at 2 GB, including system objects, with a theoretical maximum of 255 concurrent users. In practice, a database shared from a network drive gets fragile long before that: record locking, slow forms, files that need compacting and repairing, backups done by hand.

A desktop app in a mobile world

Access is a Windows application installed on each machine. It does not run on a field technician's tablet, a salesperson's phone, a Mac, or a customer's browser. Every new remote access need gets solved with remote desktop or a VPN, with the licensing and security overhead that comes with them.

Older versions are out of support

Access 2016 and Access 2019, like the rest of Office 2016 and 2019, stopped receiving security updates on October 14, 2025, according to Microsoft's end of support notice. Databases opened in those versions still work, but on software that will no longer be patched.

The single point of failure

The most common trigger is not technical at all. The person who built the database has left or is about to retire, and nobody dares change a query or a report. Our article on technical debt for business owners describes the same pattern in other kinds of software.

Option 1: SQL Server behind, Access in front

Microsoft provides a free tool, SQL Server Migration Assistant for Access (page updated April 20, 2026), that moves tables to SQL Server or Azure SQL. Your Access tables are then linked to the server: forms, queries and reports keep working, but read and write data on the server.

What you gain: a sturdier database, proper backups, no more 2 GB ceiling, and a foundation a future web app can read from.

What you do not gain: the interface is still Access on Windows desktops. Microsoft's documentation lists post-migration issues to expect: queries that slow down because Access pulls whole tables locally, VBA that needs adjusting for autonumber fields, hyperlink fields turned into plain text, and passwords stored in clear text in linked tables if you use SQL Server authentication instead of Windows authentication.

Good fit for: an in-house team on site that wants a more reliable database now, or a two-step migration to the web.

Option 2: stream Access through a browser

Remote desktop services and application virtualization tools can display the existing Access application inside a browser. Users get remote access the same week, and nothing is rewritten.

It is a stopgap, not a migration. The app is still the same desktop software, with the same limits, the same single author, and the same interface designed for a mouse and a large screen. It works poorly on phones, and you now pay for and secure an extra layer. Use it to buy time while a real replacement is built, not as the destination.

Option 3: Power Apps or another low-code platform

Power Apps is Microsoft's low-code platform. You rebuild the screens, data lives in Dataverse, SharePoint lists or SQL Server, and the app runs in a browser or on mobile. Microsoft's Power Apps pricing page lists the Premium plan at $20 per user per month, billed annually (checked November 6, 2026; local prices vary). Other platforms, such as Caspio or Zoho Creator, follow a similar model with their own pricing.

The strengths are real if you already live in Microsoft 365: sign-in with existing accounts, connections to Teams, Outlook and SharePoint, quick results for simple data entry forms.

So are the limits. Nothing converts automatically from Access. Complex business rules become hard to read and test in formulas. Cost scales with headcount. Opening the app to customers or partners requires different licensing and setup. And the app cannot leave the platform it was built on. We compare both routes in depth in Power Apps vs a custom app.

Good fit for: a Microsoft 365 company, internal users only, simple forms, a stable number of users.

Option 4: a custom web application

You keep the data model (the most valuable thing in your Access file), clean it, and build a web application on top: a server database such as PostgreSQL or SQL Server, screens designed around each role, business rules rewritten on the server, and proper permissions per profile.

What you gain: access from any browser and from phones, the option to open the tool to customers or subcontractors, integrations with accounting or the ERP, and no per-seat licence imposed by a platform. Ownership of the code and the data follows the rights defined case by case in the contract, so read that clause before you sign. Our guide on how much a custom business application costs breaks down the budget lines.

What it takes: a real project, with scoping, development and ongoing maintenance. It is the most durable route, not the fastest.

Good fit for: a tool that runs the core of the business, external users, rich business logic, a horizon of several years.

Side-by-side comparison

There is no bad option, only a mismatched one. Keeping Access in front of SQL Server for five people in one office can be the best decision you make this year.

Take inventory before you choose

An old Access database is like a house extended several times: some rooms are no longer used. Before asking anyone for a quote, list:

1. Tables and relationships. Which hold live data, which are copies or archives.
2. Forms people actually open. Ask each user for the ones they use weekly. The number is usually far smaller than the total.
3. Reports. Delivery notes, job sheets, monthly summaries: each becomes a page or a generated document.
4. Macros and VBA modules. What they do, what triggers them, and whether they write to other files (Excel, Word, Outlook emails).
5. External links. Linked tables, file imports, exports to accounting.
6. Users and permissions. Who should see what, and who should edit what.
7. Hidden rules. A default value, a validation rule, a calculation in a query: business rules that were never written down anywhere else.

The inventory shrinks the scope, and therefore the budget, and it prevents the classic surprise of a forgotten rule discovered after go-live.

Migrating the data

Data migration is a project of its own, covered step by step in our legacy data migration guide. With Access, the same issues come up almost every time:

• catch-all text fields: a "Notes" field holding a phone number, a date and a status;
• duplicates: the same customer entered three times, spelled three ways;
• loose data types: dates stored as text, amounts with mixed decimal separators;
• missing keys: tables without primary keys, relationships never declared;
• attachments: attachment fields, or file paths pointing to a network drive that has since been remapped.

The golden rule: run at least one full test migration, checked by users on their own records, before the real switchover.

Rewriting macros and VBA

No serious tool turns VBA into a web application. The sound approach is to read the code to extract the business rules, then rebuild them properly:

• input checks become server-side validation nobody can bypass;
• calculations (pricing, discounts, lead times) become functions with automated tests, using real cases taken from the old database;
• automations (generating a document, sending an email, exporting a file) become explicit actions or scheduled jobs;
• dead code disappears, which is often the biggest saving in the project.

During the transition, compare both systems on the same data. If the web app's quote differs from the one Access produces, one of them is wrong, and you need to know which before switching over.

Migrate in stages, not in one weekend

Whatever the final option, the safest path runs in stages:

1. Secure what exists: automated backups, a working copy, minimal documentation of the tables.
2. Move the data to a real database server, with Access screens linked to it.
3. Build the first web module on the process that gains most from leaving the office (field data entry, a customer portal, order tracking).
4. Run both side by side on that scope, then retire the matching Access screens.
5. Repeat module by module, until Access is only used to look up old records, then not at all.

The business keeps working throughout, and every stage delivers a visible gain.

When not to migrate

A database used by two people on the same network, for a stable and non-critical task, can live on. Move it to a supported version, automate its backups, document its tables, and spend your budget where it earns more. Migration becomes worth it when the tool starts limiting the business: no remote access, costly entry errors, dependence on one person, or a wish to serve customers online.

Where to start

Start with the inventory above, even a rough one. Then the most effective step is to see the future tool before committing a budget. We build a free visual prototype from your existing database, presented over video within 5 working days, so your users can compare their Access screens with the web version on their own cases before anything gets built. Our article on prototypes, MVPs and proofs of concept explains what a prototype can and cannot tell you.