Expert guide
Access with SharePoint Lists: Limits, Performance and Alternatives
A tempting way to put Access data in the cloud, and where it stops working
Call us at +1 (385) 386-3860
Short answer: linking Access to SharePoint lists puts data in Microsoft 365 so remote users can work without a VPN. It works for small, simple datasets (a few thousand rows per list, few joins, a handful of users). Beyond that, the 5,000-item view threshold, slow multi-list queries, weak relational integrity and lookup-column quirks make it painful. For growing or relational systems, use SQL Server or Azure SQL, remote desktop, or a web application.
When a team that relies on an Access database goes partly remote, someone notices that the company already pays for SharePoint, and Access can link to SharePoint lists. Moving the tables there seems free and simple. For small trackers it can be. For a real operational database, it often turns a fast application into a slow one that is harder to maintain than before.
What Works Well
Small reference or tracking lists (a few hundred to a few thousand items).
Simple structures: one main list with a few lookups.
Light concurrent use and mostly reading.
Organisations that already manage permissions in SharePoint and want data there.
Where It Breaks Down
| Limit | Effect on an Access application |
|---|---|
| List view threshold (5,000 items) | Large lists slow down; unindexed filters and some operations can fail |
| Not a relational engine | Joins across lists are done by Access after downloading data; slow |
| Referential integrity | Only via lookup column options, not full relationships |
| Lookup columns | Behave differently from foreign keys; complicate queries and migration |
| Data types | Some Access types and features map imperfectly |
| Bulk updates | Action queries over many items are slow and can be throttled |
| Latency | Every operation goes over the internet |
A Quick Suitability Test
Will any list exceed a few thousand rows within two years?
Do your main forms show data from three or more tables at once?
Do you run action queries that update hundreds of rows?
Will more than five or six people use it at the same time?
Do reports aggregate across large tables?
If you answered yes to two or more, SharePoint lists are likely to disappoint as the back end.
Better Options for Remote Teams
| Option | How it works | Fits when |
|---|---|---|
| SQL Server / Azure SQL back end | Tables move to a server; Access front ends link via ODBC | Most growing databases; keeps forms and VBA |
| Remote desktop (RDS / Azure Virtual Desktop) | Users run Access on a server near the data | Fastest change; no redesign; per-user hosting cost |
| Web application | Browser front end over SQL | Mobile and external users, long-term platform |
| Power Apps + Dataverse | Low-code apps on Microsoft's platform | Microsoft 365-centric teams; licensing per user |
| SharePoint lists | Linked lists in Microsoft 365 | Small, simple data |
A SQL back end is the most common path because it keeps your existing forms; see Access to SQL Server migration. For browser access, see MS Access to web application; for the low-code route, Access vs Power Apps and Access vs Dataverse vs SQL Server.
If You Already Use SharePoint Lists
Index the columns you filter on in SharePoint list settings.
Keep lists under the threshold by archiving old items to another list.
Open forms filtered to small subsets, not whole lists.
Avoid joins across large lists; pre-aggregate in SharePoint views or move reporting elsewhere.
Plan the move to SQL before growth makes it urgent.
About Access Web Apps
Access web apps, which ran Access-designed apps in SharePoint, were retired by Microsoft. Linking desktop Access to SharePoint lists is a different and still-supported scenario, but there is no current way to run an Access front end in a browser. If browser access is the goal, plan a web front end; our migrate and upgrade service compares the options in writing.
FAQ
Access and SharePoint lists FAQ
Limits, performance and alternatives