Convert an Access database to a web application

Quick Answer: You convert a Microsoft Access database to a web application by rebuilding it, not by lifting it across. The data moves into a proper relational database, the forms, queries and logic are rebuilt as a web application with real user accounts, and the result is reachable from any browser by many people at once. Microsoft retired its own Access-to-web path in 2018, so a custom build is now the durable route.

Most organisations have one. A Microsoft Access database that someone built years ago, often not a developer, that quietly became essential. It runs a real part of the business now: bookings, assets, members, cases, stock. And it is showing its age. Two people cannot work in it at once without it slowing down, nobody can reach it from home or another office, and whoever built it has long since moved on.

Access did its job. It let a non-developer build something genuinely useful, fast, with no budget. The difficulty is the flip side of that strength: it was never meant to be a multi-user, web-facing, business-critical system, and that is exactly what yours has quietly become. We have spent over 15 years building the custom systems organisations move to when a homegrown tool runs out, including the research equipment search engine for Monash University and the Zero Net Carbon modelling tool for Sustainability Victoria. Here is what converting an Access database to a web application involves.

Why a Microsoft Access database hits a wall

Access is desktop software with a file-based database. That design is why a single person can build a working tool in an afternoon, and it is also where every ceiling comes from once the tool succeeds.

Concurrency. Access is built for small workgroups. It supports up to 255 concurrent users on paper, but a shared database file over a network becomes slow and prone to corruption well before that. Most teams feel it at a handful of simultaneous users.
Size. An Access database file is capped at 2 GB. A few years of records, attachments and history reach that ceiling sooner than people expect.
No real web access. Access lives on a desktop or a network share, not a browser. Microsoft stopped creating Access web apps in 2017 and shut the feature down in 2018, pointing people to Power Apps instead, which carries limitations of its own once it scales. There is no longer a native way to put an Access database on the web.
Security and audit. A database file on a shared drive has limited access control and little real audit trail. For anything holding personal or sensitive data, that is a growing exposure.
Support and key-person risk. The skills to maintain an Access and VBA build are increasingly scarce, and the knowledge usually lives in one person’s head. When they leave, the risk has a name and a notice period.

The contrast is the point. The Cleanaview customer portal we built for Cleanaway serves its customers over the web, with the access control and audit trail a shared file cannot offer. That is the category a database moves into once it becomes business-critical.

None of that means Access was the wrong choice at the time. It means the job has outgrown the tool.

What converting an Access database to a web application means

The hope is usually that a tool will read the Access file and produce a finished web app. That is not how a durable conversion works, and the automated route tends to recreate the original problems on a new platform.

Converting an Access database to a web application is a rebuild. The data moves into a proper relational database, such as SQL Server, Azure SQL or PostgreSQL, modelled the way the business works rather than the way a single file happened to grow. The queries, forms, reports and VBA logic are rebuilt as a tested application layer and a web interface. Real user accounts, roles and an audit trail replace the shared-file free-for-all. The data you have accumulated is migrated across and reconciled, because it is an asset, not something to leave behind.

Done this way, the result is not a tidier Access database. It is a system that many people can use at once, from anywhere, with the security, reliability and room to grow that a file on a shared drive can never offer.

The Access to web application migration checklist

This is the working sequence we take into a database rebuild. It is worth keeping as a checklist, because the steps people skip are the ones that come back to bite.

Audit everything the database does. Catalogue the tables, queries, forms, reports and VBA, who uses each part, and how. Access databases accumulate features nobody remembers asking for, and a few that quietly run the business.
Model the data properly. Normalise the structure, define real relationships and validation, and fix the shortcuts Access let you take. This is where most of the long-term value is won or lost.
Choose the stack and hosting. A relational database, a web application framework and cloud hosting sized to the real user count and growth.
Rebuild the logic as tested code. Queries and VBA macros become a proper application layer you can test and change safely, instead of formulas buried in a file.
Rebuild the interface for the web. Design the screens around how the work is really done, not a control-for-control copy of the Access forms.
Add authentication, roles and an audit trail. Decide who can see and do what, and record what happened. This is usually impossible to retrofit onto Access and straightforward to build into a web application.
Migrate and validate the data. Move the records across, then reconcile against the old database so totals and edge cases match before anyone relies on the new one.
Run both in parallel, then cut over. Keep Access available while the new system proves itself, move users across in stages, and retire the file once the web application has earned the load.

Choosing the stack for the rebuild

The technology matters less than the order you make the decisions in. A database rebuild is a design problem before it is an engineering one: the value comes from understanding the workflow, then choosing tools that fit it.

For the data layer, a real relational database (SQL Server, Azure SQL or PostgreSQL) replaces the Access file and removes the size and concurrency ceilings outright. For the application, a modern web framework hosted in the cloud makes it reachable, secure and maintainable. We build on Azure, and we choose the specific stack to match what the system has to do and what the organisation already runs. This is also the moment to decide what custom database development should add that Access never could: integrations with other systems, reporting that updates live, and a structure that supports the next five years of the business, not just the last five.

When to keep Access, and when to rebuild

Moving off Access is not always the right call. If the database is genuinely used by one person, holds a modest amount of data, stays comfortably under the size limit and is not business-critical, Access is doing a job it is good at, and a rebuild is cost without enough return.

A rebuild earns its place when several of these are true: multiple people need to use it at once; it needs to be reachable from a browser or across locations; it is business-critical and cannot afford corruption or downtime; it holds personal or sensitive data with real security and audit obligations; it is approaching the size limit; or its future depends on one person who understands it. The more of those that apply, the clearer the case, and the more expensive it is to keep waiting.

Replacing the database your business outgrew

Conduct has spent over 15 years, since 2008, building the custom web applications and databases that organisations move to when a spreadsheet, an Access database or a homegrown tool stops keeping up. We are an in-house Australian team of senior engineers and designers, a 7-time Good Design Award winner, and we build for government, health, enterprise and not-for-profit organisations where the system has to perform for real users at scale. If an Access database is starting to hold the business back, talk to us about custom software development, and for a sense of budget our software development cost guide sets out what a custom build costs in Australia.

Access is a good place for an idea to start. It is rarely the place for a business-critical system to stay. The skill is knowing when the database that runs your organisation has earned a real one.

Frequently asked questions

Can you convert a Microsoft Access database to a web application?

Yes. The reliable way is a rebuild rather than an automated conversion: the data is migrated into a proper relational database, the forms, queries and VBA logic are rebuilt as a tested web application, and real user accounts and an audit trail are added. The accumulated data is carried across and reconciled. The result is multi-user, browser-based and built to grow, which an Access file cannot be.

How do you migrate a Microsoft Access database?

Audit what the database does, model the data properly in a relational database, rebuild the queries and VBA as tested application code, rebuild the interface for the web, add authentication and an audit trail, then migrate and reconcile the data. Run the old and new systems in parallel before cutting over. Skipping the data-modelling step is the most common and most expensive mistake.

What can I replace Microsoft Access with?

For a genuinely small, single-user database, a newer version of Access may be fine. For a multi-user, web-facing or business-critical system, the durable replacement is a custom web application on a real relational database. Microsoft itself retired Access web apps and pointed users to Power Apps, though Power Apps has its own scaling limits, so for anything substantial a custom build is the sounder option.

Is Microsoft Access being discontinued?

No. Access desktop is still part of Microsoft 365 and supported. What Microsoft retired was Access web apps and web databases in SharePoint: it stopped new ones in 2017 and shut down the rest in 2018. So Access still works on the desktop, but there is no native way to publish an Access database to the web, which is why a web application rebuild is the route for browser-based access.

What is the maximum size of an Access database?

A Microsoft Access database file is limited to 2 GB, minus the space needed for system objects, per Microsoft’s specifications. In practice you want to plan a move well before reaching it, because performance and the risk of corruption increase as the file grows and as more people use it at once. Attachments and history consume the budget faster than most teams expect.

How long does it take to convert an Access database to a web application?

It depends on what the database does, not how big the file is. A handful of tables and forms is a short project; dozens of interlinked forms, complex queries and years of VBA take longer because each has to be understood and rebuilt. The audit step gives you the real estimate. A staged approach lets people keep working in Access while the new system is built.

Should I move my Access database to SQL Server or rebuild it as a web app?

Moving the data to SQL Server fixes the storage and concurrency limits, but it leaves the Access front-end, so the application still is not web-based or easy to maintain. Rebuilding it as a web application addresses the whole problem: the database, the interface, web access, security and growth. For a system people depend on, the full rebuild is usually the better investment.