Microsoft Access over Remote Desktop, VPN or "the Cloud": Why It Never Feels Right

Microsoft Access is a file-based database, not a client/server one. The database engine runs on each user's own PC and reads and writes the database file over the network. Every remote-access problem people report with Access, from slowness over VPN to corruption on cloud-synced drives to locking conflicts between offices, traces back to that one design decision.

The usual declaration: I rebuild Microsoft Access databases as web applications for a living, so the last option here is the one I sell. One of the four workarounds is genuinely good, and I say so plainly when I reach it.

This problem has a different trigger from the 2GB limit on every Access file, set by your data, or Access 2021's end of support in October 2026, set by Microsoft. It arrives the first afternoon somebody works from home, and never really goes away.

The one design decision that explains everything

Microsoft Access has no server process. SQL Server, MySQL and PostgreSQL each run a program on the server, so the client sends a request and only the answer travels back. Open an Access form and the engine on your own PC pulls the pages it thinks it needs across the network, pages being fixed-size blocks of the file, then filters, sorts and joins locally.

On a wired office network that difference is invisible, because latency is a fraction of a millisecond. Lengthen the link and it becomes the whole story. A query that cannot use an index drags a large share of the table across the connection, and you pay for every one of those thousands of round trips. Bandwidth does not help; the cost is the number of trips, not the size of the load.

Locking works the same way. Microsoft's documentation on Access lock files records that every database opened for shared use gets a .laccdb file in the same folder, which the engine uses "to prevent users from writing data to pages or records that other users have locked". So each remote user is reading and writing two files over the link, all day.

Microsoft is candid about the ceiling. The same page notes that although a file-server arrangement supports up to 255 simultaneous users, where people frequently add and update data it is wise to stay at "no more than 25 to 50 users".

The four things people try, and what each one really costs

VPN: the one that looks cheapest and corrupts databases

Microsoft Access is slow over a VPN because the engine on each PC pulls database pages across the link one round trip at a time. Latency sets the speed, not bandwidth.

People try the VPN first, because it already exists. Somebody maps the office drive from home, opens the front end, and it works. For about a day.

Then the arithmetic above arrives. In databases I have been called into, forms that opened instantly take twenty or forty seconds, and a report that ran while you fetched a coffee now runs while you fetch lunch. Most teams blame the broadband and buy more, which changes nothing.

Worse is what happens to the file. An interrupted write is the classic route to a database that will not open on Monday, and the mechanism has its own section below.

To be fair about the odds: plenty of small teams run Access over a VPN for years without losing a file. The failure is rare per day, catastrophic when it lands, and it lands on the file everybody shares.

Remote Desktop or a terminal server: the one that actually works, and its licence bill

Remote Desktop is the only one of the common workarounds that genuinely works, because it moves the user to the database instead of the database to the user. The cost is a Windows session and the associated licensing for every user, paid monthly, indefinitely.

Access and the database file sit on the same machine, so the engine never reads pages across a slow link. Only pixels and keystrokes cross the internet, and those tolerate latency far better.

The bill is where people are caught out. Microsoft's Remote Desktop Services licensing documentation states that "each user and device that connects to a Remote Desktop Services session host or Azure Virtual Desktop session host running Windows Server needs a Remote Desktop Services (RDS) client access license (CAL)". Those licences sit on top of the server, the hosting and a licensed copy of Access per user. A 120-day grace period runs before a licence server is required, which is why a pilot feels free and the second year does not.

There is a workflow tax too: local printing, scanning, saving to your own desktop, two monitors, each fixable and each taking configuration. And Remote Desktop changes nothing about Access itself, so the 2GB ceiling, the desktop-only interface and the version lifecycle all follow you into the session.

If you are pricing a Remote Desktop deployment, price the alternative at the same time. The free 24-hour Migration Blueprint comes back with the scope, the timeline and an exact fixed quote, the only way to compare a bill that never ends against a one-off number.

OneDrive, Dropbox or Google Drive sync: the one that quietly destroys the file

Storing a shared Microsoft Access database on OneDrive, Dropbox or Google Drive is not a safe way to share it. Those services sync whole files after a change, while Access writes to the file continuously and expects exclusive page-level control. The predictable result is a corrupted database or silently lost edits.

Microsoft's own guidance on ways to share an Access desktop database states: "Although you can save an Access database file to OneDrive or a SharePoint document library, we recommend that you avoid opening an Access database from those locations." Microsoft warns that the file might be downloaded for editing and uploaded again afterwards, and if more than one person opens it that way, "multiple copies of the database might be created and some unexpected behavior might occur". That covers every Access file type, single and split alike.

Silence is what makes this nastier than a crash. Two people work all morning, a sync client reconciles their copies, and one person's orders are simply not there on Tuesday. The one safe case, a single person on a single machine closing the file before a sync, is a backup arrangement, not sharing.

SharePoint lists and Access Web Apps: the Microsoft-native route that was retired

Microsoft did once offer a native answer, then withdrew it. Its own Access Services in SharePoint roadmap records that it "stopped creation of new Access-based web apps and Access web databases in Microsoft 365 and SharePoint Online in June, 2017 and shut down any remaining web apps and web databases by April, 2018". Desktop .accdb databases were not affected, and customers wanting a web application were pointed to Power Apps.

Linking Access tables to SharePoint lists is a different feature, still available, but it is not a back end. Lists carry their own thresholds, joins and relationships are weak next to any database engine, and your forms, VBA and reports stay on the desktop. It suits a small, flat reference table, not a working process.

Verified against Microsoft's documentation on August 16, 2026.

Why VPN specifically causes corruption

Access does not send "update this record" to a server that takes responsibility for it. It writes bytes into the file itself, at particular offsets, maintaining the .laccdb lock file as it goes, so one save that looks atomic can be several dependent operations across the link.

The corruption scenario is that sequence interrupted part-way. A VPN tunnel renegotiating, a laptop switching to a hotspot, a lid closing: any can land between operations meant to complete together, leaving the file half-updated. Cruelly, Access often opens it fine afterwards and reports damage days later, when something reads the pages that were never finished.

A nightly copy inherits whatever state the live file was in, and because damage surfaces late, the last good backup is often older than people assume. Keep a dated copy somebody has actually opened, not a scheduled one nobody has ever restored.

"Can I just put Access in Azure or the cloud?"

Microsoft Access cannot be hosted in Azure or AWS as a service. It has no server product, no service to deploy and no browser version to sign in to. The wish behind the question is reasonable, a database somewhere central staff can reach from anywhere, but there is nothing to put there: using Microsoft Access online, in any real sense, still means running the desktop application on a Windows machine somewhere.

So "Access in Azure" means a Windows virtual machine with Access installed and staff connecting to it: the Remote Desktop option above with a monthly cloud bill for compute, storage and backup, plus the same client access licensing, which Microsoft applies to Azure Virtual Desktop session hosts running Windows Server as well as on-premises ones. AWS is no different, because what you rent is a Windows machine, not an Access service. Legitimate, and worth calling by its real name.

Another reading, putting the file on cloud storage and mapping it as a drive, is the VPN scenario with more latency, plus the OneDrive scenario if that storage syncs instead of serving a share. A third does work: move the tables to a real database server such as SQL Server or Azure SQL, keeping the Access front end on each desktop. That one gets its own paragraph below.

What working remotely on this data actually requires

Strip the workarounds away and the requirement is two things. A database engine that runs where the data lives, so only results cross the network. A client that runs on whatever machine the user has, with no desktop software to install or license. Those two sentences define a web application, which is why converting your Access database to a web app ends this problem instead of managing it.

Two of my own recent conversions were exactly this problem. A manufacturer's 19-year-old job costing system on a shared drive became a web app with live dashboards "used by 14 staff across two sites", and quoting dropped from two days to twenty minutes. A professional services firm near the 2GB limit and crashing weekly moved client billing to the cloud with an audit trail, "used from three offices", and month-end now runs in one afternoon. Neither team needs a VPN, a terminal server or a sync folder.

An honest middle option deserves equal billing. A split database with a SQL Server back end, keeping the Access front end on each machine, performs far better over a VPN, because the server does the work. It is cheaper than a rebuild, keeps forms and reports you already trust, and where the application is sound but the network is not, it is often the right call. What stays is the desktop tier: Access on every machine, Windows only, a front-end file to redistribute on every change, nothing for phones or tablets.

What stops most people choosing a rebuild is not cost but the fortnight they imagine without a working system. That is not how I run it: your team keeps working in Access for the entire build, and cutover happens on a quiet date you pick, with the old database still there. Discovery, a fixed quote, then the build, set out under how it works.

If your team is already working around this

You can tell without measuring anything. Somebody drives to the office to run month-end. A message goes round asking everyone out of the database. One person keeps a spreadsheet because the database is unusable from their site. Each is a person paying, in time, for a design decision made when everybody worked in one office.

None of it is urgent the way a deadline is urgent, which is why it persists for years. If you want these options priced against each other for your own database, send me a short description. The Migration Blueprint below comes back within 24 hours, free, and there is no call.