Microsoft Access vs a Web App: An Honest Comparison
Microsoft Access still wins on single-user work, rapid prototyping and one-off analysis, where a desktop file beats a web application on both speed and cost. Access stops working at four thresholds: several people writing at once, staff who need the data from outside the office, the 2GB file ceiling, and an application nobody left in the business can maintain.
The usual declaration first: I rebuild Microsoft Access databases as web applications for a living, so one side of this comparison is my invoice. That is why the first half of this post is the case for keeping Access, argued as well as I can argue it. A comparison that concedes nothing is worth nothing to the person reading it.
Where Microsoft Access still wins
Access has outlived thirty years of predicted obituaries because it is genuinely excellent at four jobs, and none of them is a consolation prize.
One person, one database, one machine
A Microsoft Access database used by one person on one PC is close to the most efficient arrangement in business software. There is no sign-in, no server, no connection to lose, no hosting account, no monthly bill and nobody to phone when it breaks. The file opens in seconds and behaves the same whether the internet is up or not.
A web application replaces all of that with infrastructure: a server, a database service, certificates, backups, an account for the one person using it. Every part of it is overhead bought to solve problems a single user does not have. Where one person keeps a parts list or a job book on their own machine, Access is the correct tool, and I have said so and lost the work.
Building something in an afternoon
Access is one of the fastest tools ever made for getting from an idea to a working screen. A table, a form wizard, a couple of queries, a report, and by mid-afternoon somebody is entering real data. No web stack comes close from a standing start.
That speed matters most when the process is not yet decided. Half the databases I am sent began as somebody modelling a workflow nobody had written down, changing it weekly until it settled. Access lets you be wrong cheaply, which is what a prototype is for. Commissioning a custom build before the process has stopped moving is how organisations pay to have their first draft engineered.
Ad-hoc reporting and one-off analysis
Access is a fine analysis tool for questions asked once. Link a CSV, write a query against it, cross-tab the result, export it, and delete the file when the meeting is over. Joining three sources in a query designer beats writing throwaway code. Building a screen for a question nobody will ask twice is waste.
It costs nothing to run, and it works offline
The licence was bought years ago and the file sits on a disk you already own. There is no per-user fee, no renewal, no hosting invoice and no vendor who can change the terms next year, which is a growing advantage in a market that otherwise prices by the seat.
Offline matters more than the industry admits. A surveyor in a field, a laptop on a train, an engineer in a site hut with no signal: Access works in all of them, because the data is on the machine. A web application needs a connection, and honest offline support in a browser is a project of its own.
The four thresholds where Access stops
None of that stops being true when a database crosses one of the following lines. What changes is that the strengths stop being worth the price the business now pays every week.
More than a handful of people writing at once
Microsoft's Access specifications put the hard ceiling at 255 concurrent users, and Microsoft's guidance is far lower where data changes often: no more than 25 to 50. The reason is architectural. Access has no server process, so the database engine runs on each user's PC and writes into a shared file over the network.
You have crossed this threshold when somebody in the office has become the person who runs the repair, or when a message goes round asking everyone out of the database. The mechanism, and the fixes that genuinely help, are in why multi-user Access databases keep corrupting.
People who need it from outside the office
Access was designed for a file on a local network. Lengthen the link and the design that makes it fast in the office makes it painful everywhere else, because the engine on each PC drags database pages across the connection one round trip at a time. Every workaround has a real price: a VPN is slow and risks the file, a terminal server works but bills a licence per user forever, and Microsoft advises against opening a database from OneDrive or a SharePoint library at all. I priced all four in what VPN, Remote Desktop and cloud storage each really cost.
You have crossed this threshold when somebody drives to the office to run month end, or when a second site keeps its own spreadsheet because the database is unusable from there.
The 2GB ceiling
Microsoft caps each Access file at 2 gigabytes, minus the space needed for system objects. The limit is per file, so a split database gets its own 2GB for the front end and the back end, and no setting or edition raises it. Files reach it long before the data does: deleted records, temporary query space and embedded attachments all count. What that failure looks like, and the four ways out, are in the 2GB limit on every Access file.
You have crossed this threshold when Compact and Repair has become a scheduled chore rather than an occasional tidy-up.
Nobody left can maintain it
This is the threshold that actually moves people, and it is not technical. The person who wrote the VBA has retired, or left, or was a contractor in 2011. Sometimes only the compiled .accde survives. The application still runs, and every change request ends in a shrug.
The lifecycle sits underneath that risk. Access 2016 and Access 2019 lost support in October 2025, and Access 2021 follows on October 13, 2026, which is when your answer to "is all your software vendor-supported?" changes on the next insurance or compliance questionnaire. Nothing switches off on that date, as I set out in what Access 2021's end of support actually changes. What changes is who carries the liability.
Verified against Microsoft's Access specifications and Microsoft's lifecycle page for Access 2021 on August 16, 2026.
The options, weighed against each other
The choice is never simply Access or a bespoke web application. Five options deserve weighing, and three of them involve no work from anyone like me.
Keep Access and fix the plumbing. Split the database, put every user on a wired connection with the folder rights Microsoft specifies, and move the reporting load off the live file. That is an afternoon of work, it carries a well-behaved small team for years, and it tells you whether the design or the environment was at fault.
Move the tables to SQL Server and keep the Access front end. This fixes the data tier properly: no 2GB ceiling, real transactions, proper backups, and far better behaviour over a VPN, because the server does the work instead of the network. It is well trodden and much cheaper than a rebuild. What it does not touch is the desktop dependency: Access still installed and licensed on every machine, a front-end file to redistribute on every change, and nothing for a phone or a tablet.
Power Apps. Microsoft's own path, and it works well for simpler applications, particularly where the data already lives in Microsoft 365. Two costs deserve stating plainly. Standalone applications need a paid per-user licence that continues for as long as the application runs, and Dataverse capacity is charged separately once you outgrow the plan, as Microsoft's licensing overview sets out. And a Power Apps application is not portable: no source code to hand to another developer, and no way to take it with you if the platform or the pricing changes. That is a fair trade for a tenant already committed to Microsoft, and an uncomfortable one for a business whose core process would live there.
A low-code platform. The same shape as Power Apps, with different logos. Low-code tools reach a first working screen faster than any custom build, and for a straightforward workflow that is a genuine win. Trouble tends to arrive at the specific rather than the complicated: an unusual pricing rule, a report customers expect in a particular layout, an integration nobody planned for. Pricing is per seat and grows with headcount, and where an export exists it returns your data rather than your application.
Rebuild as a custom web application. This is what I sell, so weigh the paragraph accordingly. Forms, queries, VBA and reports become a browser-based application on a proper database server: no 2GB ceiling, no Office licence on any machine, real concurrency, access from any device. The differences from the two options above are ownership and the shape of the bill. You get the source code, so any competent developer can maintain it, and you pay once rather than per seat forever. What happens to the code itself I covered in what translates when Access VBA becomes web code.
| Option | What it fixes | What it costs | Who this suits |
|---|---|---|---|
| Keep Access, fix the plumbing | Most corruption; some of the speed | An afternoon | Small teams on one site whose database is otherwise sound |
| SQL Server back end, Access front end | Size ceiling, concurrency, backups, VPN speed | Server or Azure costs, migration work, Access licensed per machine | A sound Windows-only front end whose data outgrew a file |
| Power Apps | Multi-user, remote access, mobile | A per-user licence indefinitely; no source code to take with you | Microsoft 365 tenants with simpler applications and stable requirements |
| A low-code platform | Multi-user, remote access, speed to a first version | Per-seat pricing that grows with headcount; a ceiling on unusual logic | Straightforward workflows where nothing is peculiar to your business |
| Custom web application | All four thresholds at once | The largest up-front cost, and a real project | Business-critical, multi-user or remote databases you intend to own |
What a rebuild honestly costs
Money, up front. A rebuild is much the most expensive option here. It earns that back through per-seat fees you never pay and a system you own outright, but the arithmetic only works if the database is genuinely load-bearing. For one that two people use lightly, it does not, and I will say so.
Time. This is a project measured in weeks, not an afternoon. Your team keeps working in Access throughout and cutover happens on a quiet date you choose, which removes the fortnight without a working system that most people fear. It does not remove the calendar.
Discovery risk. The real danger in a rebuild is the rule that lives in one employee's head and surfaces the week after go-live. Every migration I have seen go badly went badly there rather than in the code, which is why I map the whole application before quoting: a fixed quote is only honest once the unknowns have been counted.
If you want the options priced against each other rather than guessed at, the free 24-hour Migration Blueprint maps your database and comes back with the scope, the timeline and an exact fixed quote. There is no call, and plenty of people have used it to conclude that a cheaper option was the right one.
How to tell which side of the line you are on
How many people write to it at the same time? One is Access territory. Two to five, split and wired, is usually fine. Beyond that you are managing a risk, not running a system.
Does anyone need it from outside the office? If yes, you are already paying for it, in slowness, in licences or in somebody's commute.
How big is the back-end file, and how fast is it growing? Divide the headroom by the monthly growth. That number is your runway in months.
Who would fix it if it broke on Monday? If the answer is a name nobody has spoken to in five years, the technical questions are secondary.
Score three or four against you and the case for staying has gone, whichever option comes next. Score none and Access is doing its job. Neither answer is embarrassing, and I say the same in the FAQ on my homepage.
Where to start
Start with the cheapest move that could work. Split the database, fix the network path, and see what is left. If what is left is an application several people depend on, that somebody needs from home, that is approaching a ceiling, or that nobody can maintain, price the alternatives against each other properly, including rebuilding it as a web application.
Send me a short description of your Microsoft Access database and the Migration Blueprint below comes back within 24 hours with the scope, the timeline and an exact fixed quote. It is free, and there is no call.