Access is rarely the problem. The problem is the file that started fifteen years ago as a stopgap for order entry and today calculates quotes, prints delivery notes, works out commissions and sends an Excel list to management every Monday. Nobody planned it that way. It happened because Access was built for exactly this: getting something working quickly, without an IT project.
Support for Access 2021 ended on 13 October 2026, and in many companies the topic is back on the table as a result. The date is only the trigger, though. The deadline that really counts is a different one: the day the colleague who wrote the VBA modules retires or leaves the company.
How to tell your Access solution is hitting its limits
Access is a desktop database. Data and application live in files (.accdb or .mdb) on a network drive, and every client reads and locks directly in that file. Almost every limit you run into in daily work follows from this one architectural decision.
The version question is the most harmless. According to the Microsoft lifecycle, support for Access 2016 and 2019 ended on 14 October 2025, and for Access 2021 on 13 October 2026. Access itself has not been discontinued, however. It continues to be maintained in Microsoft 365, and Office LTSC Professional Plus 2024 has mainstream support until October 2029. Switching versions solves the security problem and nothing else.
The roadmap the Access team presented in October 2026 covers maintenance, security and convenience features. Web access, multi-tenancy or a finer-grained permission model are not on it, so the architecture will foreseeably stay as it is.
Size is more serious. The Access specifications set 2 GB as the maximum for a database file, minus system objects. Anyone storing attachments, images or log data in Access reaches that sooner than expected. Splitting the data across several back-end files or archiving old records buys time, but the limit then applies to each individual file.
Then there is concurrency. Officially, 255 concurrent users are possible, a theoretical figure. Because locking runs through the file system, things get sluggish much earlier in practice as soon as several people write at the same time. Anyone who works with it knows the symptom: the database hangs until somebody somewhere closes a form.
It becomes genuinely dangerous on the network. In its own guide to deploying Access applications, Microsoft advises against running a split Access database over a WAN or Azure file shares, because performance drops and the file can become corrupted. A VPN connection to the office falls into exactly this category. Microsoft names Remote Desktop or a server back end as supported alternatives.
So if your field staff work directly in the Access file over VPN, you are running the solution outside what it was built for.
And finally there is knowledge. The actual business logic sits in queries, macros and VBA modules, mostly undocumented. If exactly one person knows why the discount in the frmAuftrag form is calculated differently from the report, you have a concentration risk that appears on no balance sheet.
Keep, stabilise or replace: the risk traffic light
Not every Access database has to go. An inventory list maintained by three people in the warehouse can happily run for another ten years. Two axes decide: how business-critical is the application, and how well does its usage still fit the file architecture?
| Light | Typical situation | Action |
|---|---|---|
| Green | Few users on the same network, file well below 1 GB, a day of downtime is bearable, the logic is documented | Keep: split front end and back end, check backups, move to a supported Access version |
| Amber | More than a handful of concurrent users, file above 1 GB, occasional corruption, a core process depends on it, only one developer knows the code | Stabilise: move the data to a database server, keep Access as the front end for now, document the logic |
| Red | Access via VPN or from several sites, customers or partners need access, personal data without a permission model, file close to 2 GB, developer no longer available or about to leave | Replace: start the inventory and plan a web application |
The amber level is often underestimated. With the SQL Server Migration Assistant for Access (SSMA), Microsoft offers a free tool for an Access migration to SQL Server or Azure SQL.
It transfers the tables and most select queries (as views) and, if you wish, then links the Access front end to the server tables. Forms, reports, macros, VBA modules and action queries stay in Access and keep working. If your target is PostgreSQL, you need other tools and link via ODBC yourself. Either way, the data then lives in a real server database with transactions, backups and user permissions.
The step has its limits, too. Queries that Access processes locally can become slower over linked tables, and the VBA logic stays where it is. Even so, it is almost always the right move, even if you plan to replace Access in the long run, because it lays the foundation for parallel operation.
At red, stabilising only helps as a bridge. Once external parties need access or the system has to run at three sites, you need an application built for the network.
Inventory in five steps
The trickiest part of replacing Access is knowing what the old solution actually does. That is why the inventory is the most important work package in the project, and also the one people most like to skip.
1. Find all the files. Search the network drives for .accdb, .mdb, .accde and .mde. Next to the "official" database there is usually a handful of copies and satellites: the analysis file from controlling, the export file for the tax adviser, the front end someone adapted locally. Record which file is linked to which and who opens it.
2. Check the data model and data quality. Which tables exist, which relationships are defined, where is referential integrity missing? In databases that grew over time you typically find duplicate customers, free-text fields containing numbers, and tables called tblAuftrag_alt2. That is the starting point that determines the migration effort.
3. Dig out the logic. Under Database Tools, Access includes the Database Documenter, which lists tables, queries, forms, reports, macros and modules. That is the starting point. The real work begins afterwards, because business rules like to hide in form event procedures. A simplified, typical example:
' Form frmAuftrag: discount is calculated after every change to the quantity
Private Sub txtMenge_AfterUpdate()
If Me.txtKundengruppe = "B" And Me.txtMenge >= 50 Then
Me.txtRabatt = 0.08 ' volume discount only for customer group B
ElseIf Month(Date) = 12 Then
Me.txtRabatt = 0.05 ' December promotion, introduced "temporarily" at some point
Else
Me.txtRabatt = 0
End If
End SubThe rule only applies when someone uses the form, not when data is imported from Excel, and the report may calculate something different with its own query. You need to find exactly these places, write them down and clarify them with the business: is this intended, or is it a fossil?
4. Capture the interfaces. Access solutions are rarely islands. Typical examples are Excel imports via macro, mail merges through Word, emails via Outlook automation, ODBC connections to the ERP, or a CSV file that another program picks up at night. Each of these connections needs a counterpart in the target system or is deliberately dropped.
5. Clarify users and actual usage. Talk to the people who work with it every day. Which forms do they really use, which reports does anyone still print, where are there workarounds that bypass the system? It often turns out that some reports have not been opened by anyone for years. What does not need migrating is the cheapest line in the budget.
The result is a document covering the data model, business rules, interfaces and user roles. At its core this is a requirements specification, and without one every quote for replacing Access is guesswork. Our guide to requirements and functional specifications shows how to structure it.
Target picture: web app and parallel operation
For most Access solutions at red, the target is a web application with three layers: a relational server database (PostgreSQL or SQL Server), a back end with an API in which the business rules live, and a user interface in the browser.
On top of that comes what Access never really managed: roles and permissions down to record level, a change log, sign-in with the company account (SSO) and access from anywhere without a VPN. The discount rule from frmAuftrag then sits in exactly one place in the back end and applies equally to the form, the import and the report.
Before you have Access replaced, take a quick look at the alternatives. If your process is standard, such as time tracking, CRM or warehouse management, off-the-shelf software probably covers it; the trade-offs are in our decision matrix SaaS vs. customised software.
Microsoft's cloud option, Dataverse as a back end with Access as the front end, moves the data but leaves the front end as it is, and in the full version comes with per-user Power Apps licences. For simple form applications that is an option; it does not solve the core problem of grown VBA logic.
If, on the other hand, the Access solution captures exactly what sets your company apart, such as its own pricing logic or a special manufacturing process, custom software is the better choice.
The riskiest mistake in implementation is the big bang: switch off Access on Friday, launch the new application on Monday. With systems that daily business depends on, special cases turn up that were in no requirement, and then there is no way back. Parallel operation in three phases is the safer route.
Phase 1: Move the data. The tables move to the database server, and Access remains the front end via linked tables. For users, almost nothing changes. For you, a lot changes, because the data now sits where the new application can read it too.
Phase 2: Replace module by module. The web app takes over one clearly delimited area after another, for example quoting first, then order entry, and reporting last. Both systems work on the same database, so you need a strict rule on which system may write which tables.
The discount rule from step 3 shows where this gets tricky. Suppose the business dropped the December promotion during the inventory, and the new back end no longer knows it.
If someone changes the quantity of an order in the old Access form in December, txtMenge_AfterUpdate still sets a 5 % discount and saves it in the shared database. The web app, where quotes are already created, calculates without the promotion, and quote and order show two different prices for the same transaction.
So during the transition, run both calculations against each other and reconcile any differences before the old module is switched off.
The pattern behind this is known in software architecture as the strangler fig, named after the fig that grows around a tree until it has replaced it. The classic variant puts a facade in front of the legacy system; with Access, the shared database is the more practical lever. We explain the facade variant and the rule "one writing system per table" in our article on refactor, strangler and rebuild.
Phase 3: Switch off Access. Once the last module has moved, Access is set to read-only, archived after an agreed period and then removed. Keeping the archive is worthwhile in case someone asks about old calculations during an audit.
In short: free the data first, then replace the interface, and switch off the old system last. Your business keeps running throughout, and every phase delivers value on its own.
Checklist and Access check: should you replace your Access database?
Before you request a budget or ask for quotes, answer these questions for your Access solution:
- Which processes come to a halt if the database is unavailable for a day?
- How many people work in it at the same time, and how many of them via VPN or from other sites?
- How large is the back-end file, and how fast did it grow last year?
- Who can change the VBA code, and is there a stand-in?
- Which Access version is running, and does it still receive security updates?
- Which other systems read or write data from the database?
- Does the database store personal data, and who may see what?
- When was the last corruption, and how long did the repair take?
If more than two answers make you uneasy, a structured assessment is worthwhile. Our free Legacy Check asks six questions about technology, maintenance, operations and documentation and gives you a risk score plus the matching modernisation path in two minutes. Access and VBA solutions are explicitly listed there as a typical legacy system. How we replace legacy systems while keeping day-to-day operations safe is something we are happy to discuss for your specific case.
The most important first step costs no budget, though. It is a meeting with the person who wrote the VBA code, while they are still with the company. What should come out of it is a list of all the rules that so far only they know.