Introduction
Data management products have evolved rapidly over the last decade. From data warehouses to big data, from on-prem to cloud-based, from data lakes to delta lakes - there have never been so many options. So why on earth in 2026 would I be writing an article about Microsoft Access?
Go to any tech conference in 2026 and everyone will be talking about Databricks, Snowflake, BigQuery and Microsoft Fabric. Nobody's queuing up to hear a talk on Microsoft Access and I guarantee it won't have its own booth or even a keynote. And yet, all around the world, it still sits quietly on millions of enterprise machines, doing the exact job it was designed to do.
Scenario
Let me set the scene. Let's say you're tasked with helping a 10-person finance team that needs a database application for managing the apportionment of project labour costs across the company's projects every month - perhaps around 1,000 transactions. Your solution needs to be able to do the following:
- 1. Pull in data from the project management system and the payroll system.
- 2. Allow the team to manually enter additional data.
- 3. Allow the team to perform specific data processing actions.
- 4. Allow the team to extract data for upload into their finance system.
Considerations
So how would you build it?
For the database, maybe you'd consider something like SQL Server on-premises, or Azure SQL in the cloud.
How about the front end? You could build a fancy web front end using ASP or PHP. Or you could consider a low-code/no-code solution using Microsoft's Power Platform.
There are, of course, multiple options - many more than I've named here - and they'll all work from an engineering perspective. But when you build solutions in the real world, there are some very practical headaches that never appear in the IT textbooks or keynote speeches.
- 1. Server access. Anyone who has ever worked in a big corporate environment knows that getting IT to give you server access is seldom straightforward.
- 2. Getting solutions approved. You very quickly find yourself having uncomfortable conversations with solution architecture, internal audit, data governance, security, and testing teams.
- 3. License costs, cloud costs, etc. Again, in a corporate environment you'll now find yourself needing permissions and approvals from finance.
- 4. Ongoing maintenance. People want to know who is going to maintain your server-based solution. Do the skills to fix and improve your application exist in-house?
- 5. Time to build. Realistically, how long is it going to take you to build and deploy your "enterprise" solution? Weeks? Months, even?
- 6. Complexity. You're potentially building two separate solutions - a database and a front end - possibly living in different environments and requiring integration between the two.
After 20 years building enterprise software, my first question is this: are we selecting the technology that's most appropriate for the size of the problem, that's the least hassle to maintain and improve, and that will take the least time to build and deploy? Or are we at risk of using a sledgehammer to crack a walnut?
Benefits
So, back to Microsoft Access. It might be considered "legacy” by the self-appointed "data police" out there but, 30 years on since its original launch, it's still part of Microsoft Office today, when many other database products have long since disappeared.
Let's consider some of Microsoft Access's benefits:
- 1. If the team already has Access through their Office licensing, there's nothing new to install.
- 2. No server deployment headaches - it's stored in your file system.
- 3. It's designed for small-scale operations with a small number of users.
- 4. You can build your own internal database tables, views, etc.
- 5. You can build tables that pull in data from external databases.
- 6. You can write and store SQL operations.
- 7. You can write procedural code in VBA that runs your SQL operations.
- 8. You can build a front end that allows your users to run operations.
- 9. You can build front-end forms that allow your users to enter and edit data.
- 10. It's quick and straightforward to build and deploy a self-contained solution.
Deployment
The important thing now is to scroll back up, remind yourself of the project requirements, and ask yourself: what's the most appropriate architecture for this specific challenge? What's going to be simplest to deploy? Quickest to build? Easiest to maintain? What's the "least hassle" solution?
So, you decide you want to build it with Azure SQL or SQL Server? Fine. They're both superb products, but I wish you the best of luck getting it approved, provisioned, secured, licensed, connected, tested, deployed, and maintained. I cannot tell you how many times I've sat in meetings where a small Finance requirement has turned into weeks of discussions about infrastructure, security, architecture, licensing, support and ownership. The end result is that a simple problem quickly becomes a six-month complex project.
Let's be clear, Access isn't a silver bullet. File-based databases come with concurrency limits, file size caps, and local backup considerations. But when managing a 1,000-transaction monthly process for a 10-person team, those constraints are minor compared to a 6-month IT queue.
Sometimes the most appropriate technology isn't the one that produces the most elegant architecture diagram, it's the one you can actually get deployed.
Conclusion
At the end of the day, Microsoft Access was designed to do a completely different job from the "enterprise" data management players out there. There are countless situations where using Microsoft Access would be a terrible, even disastrous, choice. But my point is simply this: let's not get too distracted by the latest tools being pushed at us by vendors. Let's just pick the right tool for the job - the one that gives you the path of least resistance to building and deploying a solution that solves the problem for the team.
I say this as someone who spent the last 20 years specializing in data architecture, both cloud and on-prem. I genuinely love enterprise data architecture - but I sometimes feel that I must have spent ten of those years sitting in meetings waiting for server permissions, service accounts, and licensing approvals for vastly overcomplicated solution designs.
Is Microsoft Access more powerful than Azure SQL or SQL Server? Of course it isn't. No one ever said it was. But that's like criticizing a caddy van for not being a haulage lorry - that is, until you've got to do the engine maintenance, pay for the fuel, change the tyres and back it onto your driveway tonight when you get home.