Microsoft Access was designed to be a single-user database that could be shared with a small team. That was the 1990s definition of "small team" — two or three people in the same office, rarely writing data at the same time. In 2026, that database is supporting 15 warehouse staff entering orders simultaneously, and it's starting to show.
If you're seeing lock errors, slowdowns, or corrupted records that seemed fine yesterday, your Access database has hit its multi-user ceiling. This guide explains why it happens, what you can do to extend Access's life, and how to recognize when the honest answer is that Access has served its purpose and the data needs a new home.
Access is a file-based database. The entire database — tables, queries, forms, reports, and VBA code — lives in a single .accdb file on a disk. When multiple users open that file over a network share, they're all reading from and writing to the same file simultaneously.
Access manages this through file-level locking using a companion .laccdb file (or .ldb for older .mdb databases). When User A starts editing a record, Access locks that page of the file. User B trying to edit a record on the same page waits. If User B waits too long, they get an error.
This works reasonably well for 2-4 users with light workloads. It starts to degrade around 8-10 concurrent users. Beyond 15-20 concurrent users, you're fighting the architecture.
The most obvious signs:
Less obvious but just as damaging:
This is where multi-user overload becomes dangerous:
If you're running Compact-and-Repair weekly just to keep the database open, that's not maintenance — that's a slow-motion failure.
The most impactful single change for a multi-user Access database is splitting it into front-end and back-end components.
Why this helps: when users open the front-end, they're not loading the entire database file. Only the data they request travels over the network. Lock contention drops significantly because forms operate on local recordsets before committing to the shared back-end.
Limit: Splitting helps but doesn't eliminate the fundamental constraint. You're still writing to a single file on a network share. With 20+ simultaneous writes, you'll still see locking issues.
To split: Database Tools → Access Database (Split Database). Back up first.
Access has three record locking modes under File → Options → Client Settings → Advanced:
If you're on "All records" or "Edited record," switching to optimistic locking with proper conflict handling in your VBA will dramatically reduce lock errors.
Access pulls entire tables across the network before filtering them locally. A query like SELECT * FROM Orders WHERE CustomerID = 5 often retrieves all Orders from the network share, then filters in memory. With large tables and multiple concurrent users, this creates a traffic jam.
Rewrite queries to be more selective. Use WHERE clauses that leverage indexed fields. Avoid opening large recordsets in VBA when you only need a few rows. This won't fix the architecture, but it significantly reduces the strain.
Access is sensitive to network latency in ways that SQL Server isn't. If your Access back-end is on a VM, a NAS device with old firmware, or accessed via VPN, you may be creating artificial performance problems unrelated to the user count.
Access works best on a fast, low-latency LAN with the back-end on a Windows file server (not a NAS). If you're supporting remote users via VPN, Access over VPN is slow by design — this isn't fixable without changing the architecture.
The four fixes above can buy you time. They won't change the fundamental constraint: Access is a file-based database, and file-based databases don't scale beyond a certain point.
Here's the honest scorecard:
| Concurrent Users | Access Viability | Recommended Path |
|---|---|---|
| 1–5 | Solid | Keep it. Maybe split if not already. |
| 5–10 | Workable with tuning | Split, optimize locking, reduce network traffic. |
| 10–20 | Fragile | Upsize tables to SQL Server. Keep Access front-end. |
| 20–50 | Unsustainable | Full modernization: web app or SQL Server with proper app layer. |
| 50+ | Not appropriate | Migrate to a purpose-built multi-user system. |
If you have 10-30 users and want to keep your Access forms and reports, upsizing your tables to SQL Server is the most practical intermediate step. Microsoft provides the SQL Server Migration Assistant (SSMA) for Access, and the process is well-documented.
What changes:
What doesn't change:
Upsizing handles multi-user scaling well. It doesn't solve the other Access pain points: no mobile access, no browser-based access, VBA maintenance burden, Access runtime dependencies on user machines.
Some Access databases have grown beyond what a client-server fix can address. If you're dealing with any of these situations, you're past the point where SQL Server upsizing is the answer:
A browser-based web application running on a proper database (PostgreSQL, SQL Server, MySQL) handles all of these natively. Your data stays on your infrastructure. Users access it from any device with a browser. You get real authentication, real permissions, and a UI that isn't constrained by Access form design.
AccessLeap migrates your Access database to a modern web application — preserving your business logic, your data, and your workflows. No Access required. Works on any device.
Learn About AccessLeapWhether you're upsizing to SQL Server or migrating to a web app, the first step is the same: get a clean, verified copy of your data out of Access.
This means:
Migrations that skip this step import corrupted data, miss relationships, or lose business logic that was buried in event procedures. The cleanup time is always longer than the migration time. For a detailed walkthrough of the full process, see our Complete Guide to Access Migration.
LegacyLeaps scans your .mdb and .accdb files and generates a complete inventory: tables, relationships, queries, VBA modules, and forms. Free to run, no data leaves your machine.
Download Free ScannerAccess multi-user problems aren't a sign that you built something wrong. Access was genuinely the right tool for what you needed when you built it. The database grew, the team grew, and now the tool that got you here can't take you further.
That's not a failure — it's a success that outgrew its container. The question now is which path forward fits your team size, budget, and technical capacity. Splitting and optimizing can extend Access's useful life. SQL Server upsizing can take you to 30-50 users. A proper web app removes the ceiling entirely.
Start with a scan of what you have. The answer to "what should we do?" becomes a lot clearer when you know exactly what you're working with.
Practical fixes for legacy Excel and Access problems. No spam.