Access has a reputation problem. Half the industry treats it as a toy, and the other half is quietly running a business on one.
Both are wrong. It’s a proper tool with a specific job, and the question worth asking isn’t whether Access is good — it’s whether it fits what you’re doing.
Here’s the honest version, from people who’ve supported Access systems since 1999.
Where Access makes sense
You already own it. Access comes with several Microsoft 365 business plans and it’s probably already on your PCs. No server to buy, no per-core licensing, no separate database administrator.
You need something working in weeks. A working Access system can be built and in use in the time it takes to specify a larger one. For plenty of businesses that gap is the whole decision.
A manageable number of people use it. Typically a handful at once, in one building, on a wired network.
Development costs less. Genuinely — often substantially — than the equivalent on SQL Server or MySQL. Just don’t let that be the only consideration.
It talks to the rest of Office. Exporting to Excel, producing Word documents, pulling in data from other Office files — it all works without building anything. If your team lives in Excel, that matters more than it sounds.
It’s flexible. Well-designed Access systems take change easily, and business requirements always change. That’s one of its best attributes and one of the reasons so many of them are still running twenty years later.
Where it doesn’t
We’d rather say this plainly than sell you something that’ll cause you grief.
Lots of concurrent users. Access is a file-based database. Several people writing to the same file at once is where corruption, locking and slowness come from.
Anything security-critical. The security model is minimal. If confidentiality is paramount — personal data at scale, financial records, anything regulated — Access shouldn’t be carrying it on its own.
Remote access as standard. Access over wifi, a VPN or a home connection is painful. It wants a stable wired network.
Anything public-facing. Access web apps and Access Services in SharePoint were retired by Microsoft years ago. If someone offers you that as a route, it doesn’t exist.
Very large volumes. The back end has a 2GB limit, which arrives faster than people expect once documents and images go in.
The option most people miss
It isn’t Access or SQL Server. For a lot of businesses the right answer is both.
Keep the Access front end your people already know, and move the data to SQL Server or Azure SQL behind it. Users open the same forms they opened yesterday. What changes is that the concurrency, corruption, size and security problems go away — because they were never really Access problems, they were file-sharing problems.
It’s usually the cheapest significant improvement available to an Access system, and it’s what we recommend most often.
Not everyone needs Access installed
A point that catches people out on cost.
Access is a desktop application, so in principle everyone using the system needs it installed. Buying twenty copies changes the maths considerably.
They don’t all need it. We build Access systems as runtime applications, which run on the free Microsoft Access Runtime — no licence per user. You get the system; they don’t need to own Access.
That’s usually the difference between Access being the cheap option and the expensive one.
It’s easy to move on when you need to
If the system outgrows Access — more users, more data, remote access, tighter security — you don’t start again.
Moving to SQL Server has its pitfalls, but it’s usually straightforward if the Access database was designed carefully in the first place. That conditional is doing a lot of work: a well-structured Access system upsizes in days, a badly structured one turns into a rebuild.
Which is the argument for having it designed properly at the start, even when it’s “just an Access database”.
So should you use it?
Probably yes if it’s a single site, a handful of users, Office is already paid for, and you want something working soon.
Probably not on its own if you need many concurrent users, access from anywhere, or you’re holding data that would be a problem to lose or leak.
Probably both — Access in front, SQL Server behind — if you’re somewhere in the middle, which most businesses are.
And if you already have one that’s creaking, that’s not a reason to throw it away. It usually means it’s outgrown its back end, and that’s fixable → Access support
Case Studies
Commercial Catering Service & Maintenance (field service)
Aire Valley Catering
Field service apps that work with no signal
Aire Valley Catering’s engineers work in commercial kitchens across the UK, often with no usable signal, and every job still has to be recorded. We built four production…
View case study
Transport and logistics
ACC Worldwide
A faster SQL Server system, noticed on day one
ACC Worldwide’s staff used one business system all day, every day, and it was slow. We worked on the SQL Server environment behind it. The speed-up was immediate,…
View case study
Travel and leisure (adventure travel and expeditions)
Jagged Globe
Keeping bookings, customer records and the website in step
Jagged Globe runs on an internal database and a booking website that have to agree every day, and sometimes they didn’t. We traced and fixed the transfers between…
View case study
Not sure which way to go?
Tell us what the system needs to do, roughly how many people will use it and where from. We’ll tell you whether Access fits — including when it doesn’t.