A lot of businesses are running on a Microsoft Access database that was never supposed to last this long. Someone built it 15 or 20 years ago to solve a specific problem. It worked. The business grew around it. More fields got added. More tables. More queries. The file got bigger and more complex, and now it sits at the center of how the business operates, a fragile, single-machine database holding years of critical business data that nobody fully understands anymore.
Access was designed as a desktop tool for small workloads. It was not built for multiple concurrent users, web access, or integration with modern software. Every limitation that was acceptable when the database was small becomes a real operational problem when the business has grown past what Access was designed to support.
Converting that database to a web application is the right move for most businesses in this situation. But the way it gets done matters. A simple migration that moves the data and rebuilds the interface without addressing the underlying business logic will produce a web version of the same problems.
What are the limits of Microsoft Access for a growing business?
Access can technically handle more than its reputation suggests. The platform supports up to 255 concurrent connections. When it is deployed correctly, with the back-end data file on a shared network drive and a copy of the front-end (the forms, queries, and VBA code) installed on each user’s local machine, Access will run a real multi-user workload. That is Microsoft’s recommended architecture, and some IT teams quietly run it well today.
In practice, most deployments are not architected that way. The database started as a single file on someone’s machine, got moved to a network share when other people needed access, and grew over years with everyone opening the same monolithic file directly. That deployment is where the locking, corruption, and “close it and reopen it” workflows come from. Those are not strictly Access’s fault. They are what happens when a tool meant for one model gets used in another.
Even when the architecture is right, the platform has hard ceilings worth knowing.
Access database files cap at 2 GB. After 15 to 20 years of records, transaction history, and accumulated tables, businesses routinely hit that ceiling. The standard responses are to archive older data, split the back-end further, or move the data to SQL Server with linked tables. Each one buys time, not a permanent answer.
Access uses page-level locking, not row-level. Two users editing different records can still block each other if those records happen to sit near each other in the file. Performance degrades as the user count climbs, well before the 255-connection limit.
There is no native web access. Access databases run on Windows machines connected to the file. Remote workers need a VPN, and even then performance over WAN is rough. Microsoft retired Access Web Apps in 2018, so there is no first-party path to a browser-based version.
The file gets fragile under load. Heavy use, abrupt disconnections, and network share hiccups all degrade Access files over time. The compact-and-repair operation that took seconds on a small file takes minutes on a mature one, and gets run more often as the file ages.
Integration with modern tools is limited, not impossible. Access has ODBC, linked tables, and DAO, which a developer can use to connect it to other systems. What it does not have is a modern REST API, which is what almost every cloud-era tool expects. Connecting Access to a customer portal, a shipping carrier, or a cloud accounting platform means building and maintaining a custom integration layer for each one. Most businesses end up doing it manually instead.
Why the business logic matters more than the data
When most people think about converting an Access database to a web application, they focus on the data. How do we get the records out of Access and into a new system?
The data is actually the easier part. The harder part is the business logic.
Over years of use, an Access database accumulates queries, forms, and VBA code that encode how the business actually works. A query that calculates a specific pricing formula. A form that enforces a particular data entry workflow. A report that produces numbers in a format that matches how the ownership team reads the business.
That logic is not always documented. Often it lives in the database itself, understood only by the person who built it, who may not still be with the company, or by the people who use it every day without being able to articulate exactly what it does.
If that logic does not get correctly replicated in the new system, the conversion produces a web application that holds the data but does not work the way the business works. Decisions that used to happen automatically now require manual intervention. Reports that used to be accurate are now wrong in ways nobody immediately notices.
The first step of any Access conversion is documenting what the database actually does. Not just what tables and fields exist, but what the queries calculate, what the forms enforce, and what business decisions the database is making automatically. That documentation becomes the specification for the web application.
What does converting Access to a web application actually involve?
The conversion process has four phases, and all four matter.
The first is discovery and documentation. A developer reads the Access database: the tables, queries, forms, reports, and VBA code. The developer documents the business logic. This is done in collaboration with the people who use the database every day, because some of the logic lives in how people use it rather than in the database itself. This phase takes longer than people expect, and skipping it produces a bad outcome.
The second is database migration. The data gets extracted from Access and loaded into a modern database, typically PostgreSQL, MySQL, or SQL Server. This includes cleaning up inconsistencies that have accumulated over years: duplicate records, formatting variations, fields that were repurposed for something other than their original use.
The third is application development. The web application gets built around the documented business logic. This is where the decisions made in the discovery phase pay off. A well-documented specification produces a web application that works the way the business works, not a generic interface over the migrated data.
The fourth is parallel operation and testing. The web application runs alongside the Access database while the team tests it against real workflows. The Access database stays live as a fallback until the team is confident the new system handles everything correctly. No forced cutover date.
These same four phases apply to converting other legacy desktop databases like Visual FoxPro, where the underlying challenge is the same: extract the embedded business logic without losing what made the original system work.
What does the new system gain that Access never had?
The most immediate gain is multi-user access without conflicts. A web application handles concurrent users correctly. Multiple people can work in the same records at the same time without locking issues or corruption.
Web access means the system works from anywhere. Remote employees, field staff, and people working from home all use the same system the same way as people in the office.
A modern database is built for scale. It handles larger datasets, more users, and more complex queries without the fragility that comes with an aging Access file.
And the API changes everything. Once the business logic lives in a web application with a proper API, it can connect to accounting software, customer portals, shipping carriers, and any other modern tool automatically. Data that previously moved by hand starts moving on its own.
Most software problems are really workflow problems. An Access conversion done right is not just a technical migration. It is a chance to look at every workflow the database supports and ask whether it could work better.
Common questions
Can we keep using Access during the conversion?
Yes. The conversion runs in parallel with the existing Access database. Your team keeps using Access while the web application is built and tested. You switch over when the new system is ready, not on an arbitrary deadline.
What happens to our historical data?
It migrates to the new system as part of the project. How much historical data needs to be fully accessible in the new system versus archived somewhere searchable is a decision worth making early because it affects the database design.
How long does an Access conversion take?
For a moderately complex Access database with custom business logic, 4 to 6 months is a realistic timeline. Simpler databases can move faster. Databases with extensive VBA logic or unusual data structures take longer. The discovery and documentation phase is where most underestimates happen.
Can we add features the Access database never had?
Yes, and it is worth planning for this from the start. The conversion is the right time to address workflows that always required manual workarounds in Access. Adding those improvements during the initial build costs less than adding them afterward.
Do we need a developer who knows Access specifically?
A developer needs to be able to read Access databases: the tables, queries, and VBA code. That knowledge is needed to extract and document the business logic. Beyond that, the new system is built in modern web technologies that have nothing to do with Access. The Access knowledge is needed for the discovery phase, not the development phase.
What if the person who built the Access database is gone?
This is the most common situation. The business logic lives in the database itself, and a developer can read it directly from the tables, queries, and code. It takes more time than when the original developer is available to explain it, but it is entirely workable. The discovery phase takes longer in this situation, which is why it should not be rushed.
Converting an Access database to a web application is one of the most common modernization projects we take on. If you want to understand what that process looks like for your specific database, our Legacy System Modernization service covers this type of work in detail. Or book a free 30-minute diagnostic call and we will work through what the conversion involves for your situation. You keep the assessment regardless of what you decide.
