By Greg Nowak. Last updated 2026-06-20.
Microsoft Access is often treated as either a quick fix or an embarrassing legacy system. In practice, many Access databases sit somewhere more useful: they run quotes, bookings, stock lists, internal reporting, case handling, or client admin that still matters every week.
This resource guide is for business owners, operations leads, and agency teams who have inherited an Access database and need clear next steps. The goal is not to make Access sound modern at all costs. It is to help you decide whether to maintain it, clean it up, split it properly, connect it to stronger data storage, or replace it with a web app or workflow system.
Start With What The Database Actually Does
Before touching tables or rewriting forms, map the business job. Which team uses it? What decision or process depends on it? What happens when it is unavailable? Many Access projects fail because the technical work starts before anyone has named the operational risk.
A small Access file used by one person for a weekly export may only need documentation and a backup routine. A shared database used by several people throughout the day needs a different conversation: data integrity, version control, user permissions, support cover, and whether the current file structure can handle the load.
Access Is Still Useful In The Right Shape
Access remains a practical tool for small internal systems, especially when the users are already in Microsoft 365 and the process needs forms, reports, imports, and quick iteration. It is strongest when the scope is clear and the number of simultaneous users is modest.
Its limits are also real. Microsoft documents file size, object, table, query, and user limits, and those limits matter when a database has grown for years without housekeeping. Access is not a public web application platform, and it is not a replacement for a managed backend when multiple teams need reliable access from different locations.
The healthiest Access systems tend to have three things: a split front end and back end, regular compact-and-repair maintenance, and a clear owner who understands both the workflow and the data.
| Situation | Best Next Step | Why It Matters |
|---|---|---|
| One person uses the file occasionally | Document tables, queries, forms, and backup location | Low-cost stability is usually enough |
| Several people share one file | Split the database into front-end and back-end files | Reduces corruption risk and makes updates easier |
| The file is slow or frequently repaired | Review table design, indexes, linked tables, and compact schedule | Performance problems often signal structural debt |
| Access drives a business-critical process | Create a support plan and modernization roadmap | The risk is operational, not just technical |
| Remote users or external clients need access | Consider SQL Server, Azure SQL, or a custom web app | Desktop Access files are not built for public or distributed web use |
Resources Worth Keeping Handy
For day-to-day work, Microsoft’s own Access documentation is the first place to check. The Access specifications page is useful when you need to confirm practical limits such as file size, number of objects, field limits, or query constraints. These limits are not theoretical if your database has years of imported data, attachments, duplicated tables, or archived reports.
The Microsoft guidance on splitting a database is also important. A split setup keeps shared tables in a back-end file while each user gets their own local front-end file containing forms, reports, queries, and code. For many small teams, this is the single most useful improvement before any larger rebuild.
Compact and repair guidance is worth reviewing as well. Access files can grow as objects are edited and deleted, and corruption risk increases when users disconnect badly or share one file over unreliable storage. Compacting is not a strategy by itself, but it is a basic part of maintenance.
The original Fontstuff Access tutorial linked from the old version of this article may still help with query concepts and examples. Use older community tutorials as supplementary reading, though, not as the authority for design or migration decisions. For modernization, Microsoft’s SQL Server Migration Assistant documentation is a better starting point because it reflects current supported targets such as SQL Server and Azure SQL.
What To Check Before You Hire Help
If you are asking a consultant to look at an Access database, prepare a short operational brief. You do not need a technical specification. You need the truth of how the database is used.
Include the file location, approximate number of users, the main forms and reports, any imports or exports, and the pain points: slow opening, duplicate data, broken queries, missing reports, crashes, manual re-entry, or confusion about which file is the latest version.
Also identify the business deadline. A database that supports month-end reporting needs a different plan from a database that supports live order processing. Good Access work is partly technical repair and partly risk management.
A Sensible Improvement Path
Most Access engagements should start with discovery, not a rebuild. First, make a safe copy and confirm backups. Then document the tables, relationships, linked data sources, queries, forms, reports, macros, and VBA modules. After that, review the highest-risk areas: shared file setup, missing relationships, repeated manual imports, hard-coded paths, and undocumented business rules hidden in queries or code.
From there, the path is usually one of three options. The first is stabilisation: fix the worst errors, split the database, improve backups, and leave the system largely in place. The second is enhancement: add reports, improve forms, reduce duplicate entry, or connect to better data sources. The third is migration: move the data and workflow into SQL Server, Azure SQL, or a custom application when Access has become the bottleneck.
The best choice is not always the most ambitious one. A focused Access cleanup can buy a team another year of reliable operation. A rushed rebuild can lose business rules that users depend on. The right decision comes from understanding the workflow first.
When Greg Can Help
If your Access database is useful but fragile, it is worth getting an experienced outside view before it breaks at the worst possible moment. Greg can help audit the file, explain the risks in plain English, clean up the practical issues, and map a realistic path from maintenance to modernization.
That might mean keeping Access and making it safer. It might mean using Access as a front end with a stronger back end. Or it might mean planning a replacement that fits how your team actually works. The useful starting point is a conversation about the job the database does today and the cost of getting it wrong tomorrow.
Related on GrN.dk
- AI Shopping Surfaces Make Product Data Integrity a Technical Ops Job
- Fixing Website Email Deliverability in 2026: What Business Websites Need to Get Right
- OpenAI's Guardrails and Run State Make Internal Agent Rollouts a Paid Approval-and-Audit Job
Need help with this kind of work?
Discuss an Access database review Get in touch with Greg.