Access database modernisation: what changes between 2007 and now

A Microsoft Access database is not a mistake. It was the right tool for one person on one screen in a small team in the mid-2000s. The Australian wealth and accounting firms still on Access in 2026 ask us what changes when the team grows past five concurrent users, when audit pressure steps up, and when the laptop the .mdb file lives on becomes the single point of failure. Modernisation is rarely a full rewrite.

Why Access was the right answer in 2007

In 2007, a small firm wanting a real database had three options. SQL Server with a custom front-end (expensive, slow to build, needed a developer on staff). A SaaS product (most of the categories did not yet exist for Australian professional services). Or Microsoft Access, which shipped with Office, ran on the laptop the bookkeeper already had, and let one person model the business properly without writing a deployment script.

Most of the Access databases we are now asked to modernise were built by a person who is no longer at the firm. A practice manager, an operations partner, sometimes the founder. They knew the business cold. They had Office on their machine. They built tables, queries, forms, and a handful of macros, and the system did its job for the next decade.

The criticism of Access in 2026 is mostly retrospective. At the time, the alternative for a 10-person wealth practice or a 20-person accounting firm was a manilla folder and a spreadsheet. Access was a step up from that. We rebuild these systems now because the firm outgrew the assumptions the original choice was built on. The original choice was reasonable. The firm changed shape underneath it.

The data model in most of these databases is also better than people expect. The original author was working close to the business. The tables tend to map to real things (clients, accounts, matters, advisers, products) and the queries encode rules that the firm still runs on. We have rebuilt enough of these to know that the asset is in the schema, not the forms.

The four limits that finally bite

The pressure to modernise an Access database arrives as four limits, usually in this order, sometimes layered on top of each other.

Concurrency past five users. Access can technically support more, and Microsoft’s documentation will tell you so. In practice, the wheels start coming off around five concurrent users on the same .mdb or .accdb file. Record locks fire at the wrong time. Two users editing the same form save half the changes each. Someone hits the file at the moment a query is rebuilding an index and the database goes read-only until everyone closes out. The firm’s response is usually to write rules (“only Sarah edits client records before 10am”) which work for a year and then stop working when Sarah hires an assistant.

Audit and reporting requirements step up. This one creeps. The firm passed its first ASIC audit, or its first AFSL surveillance visit, or its first proper compliance review, with the Access database. The auditors asked for reports the database could produce. The next audit asks who changed a client’s risk profile last March, and the database has no audit table because the original author did not build one. The firm patches around this with shadow spreadsheets and printed records. The patch holds for one cycle, sometimes two. The third audit asks for something the patch cannot answer.

The laptop the database lives on is the single point of failure. A surprising number of Access databases we inherit are still running on one specific laptop or workstation. The shared-drive version exists, but the “real” one is on Janet’s machine because that is where the linked tables resolve and the macros run. Janet takes leave. Janet retires. Janet’s laptop fails on a Tuesday morning. The firm has a backup of the .mdb file. They do not have a backup of the ODBC configuration, the linked-table paths, or the local print queue the macros call.

.mdb file corruption. This is the one that ends the conversation. The file gets to a couple of hundred megabytes, someone runs a query that touches half the tables, the network blips during the write, and the .mdb is corrupted. Sometimes the Access compact-and-repair tool brings it back. Sometimes it does not. We have seen firms lose three days of data this way. We have also seen firms operate for years without it happening. It is the limit that arrives without warning.

When two of these four limits are firing on the same database, the modernisation conversation has usually already started inside the firm. By the time three are firing, the firm has stopped trusting the system and is running on shadow spreadsheets to cover the gaps.

The two modernisation paths

There are two real paths, and the right one depends on how much of the original Access app the firm still wants to use.

Path one: lift-and-shift to Postgres or SQL Server, keep the Access front-end. The tables move out of the .mdb file and into a proper database server. The Access application stays where it is, but the linked tables now point at the server instead of the local file. The forms and reports the team uses every day do not change. The macros still fire. The user experience is identical, except that concurrency is no longer a problem, the data is backed up automatically, and the audit table can be added at the database layer without touching the front-end.

This path is cheaper, faster, and lower risk. We have done it for firms where the Access UI was genuinely good enough and the whole problem was the .mdb file. The trade-off is that the firm is still running Access, which means the firm is still subject to whatever Microsoft does next with Office. The 32-bit ODBC dependency does not go away. The macros that depend on a specific Office version still depend on that version. The single point of failure has moved from the .mdb file to the Office runtime.

This path makes sense when the front-end is fine and the team is too lean to absorb a UI change in the next two years.

Path two: full rebuild on a modern web stack, retire Access entirely. The tables move to Postgres or SQL Server. The Access front-end is replaced with a web application that runs in a browser, on any device, with role-based access and a real audit trail. The macros are rewritten as background jobs. The reports are rebuilt against the same data model.

This path is more expensive and takes longer. The benefit is that the firm exits the Office runtime, the 32-bit ODBC chain, and the laptop-the-database-lives-on problem permanently. The team can use the system from anywhere, on any device, without Office on the machine. New starters do not need an Access licence.

We default to path two when the firm is growing, when the original Access UI is showing its age, or when the firm has staff working from home or from client sites and the desktop-only constraint has started costing real money. We default to path one when the firm is stable, the UI is fine, and the budget for the modernisation is genuinely tight.

A common middle path: lift-and-shift the database now (path one), then schedule the front-end rebuild as a separate project six to twelve months later (path two). This breaks the spend across two budget cycles and decouples the data risk from the UI work.

What we keep from the original

The data shape is almost always worth preserving. We have rebuilt around a dozen Access systems for Australian firms across wealth, accounting, legal, and a handful of trades businesses. In every one of them, the original tables were better than the original UI suggested.

What we typically keep:

• The table structure, with adjustments for normalisation where the original author flattened a relationship that should have been split.
• The keys and the foreign-key relationships, which usually encode rules the firm still runs on.
• The named queries, translated into views or stored procedures on the new database.
• The reports, in shape if not in form. The columns the partners look at are usually the columns they should still be looking at.

What we typically replace:

• The forms, because the web app gives us a chance to fix UX choices that were limited by Access in 2007.
• The macros, because the modern equivalent is a background job that is testable, loggable, and not tied to a specific user’s session.
• The print queue and the email integration, because both have changed enough since 2007 that nothing useful comes across.

The case study we published on a wealth management Access rebuild walks through this in detail. A 10-to-15 adviser firm where the Access database had become the firm’s CRM, built years earlier by a former employee, and where the institutional knowledge in the queries was the whole asset. We reverse-engineered the schema, modelled it properly in PostgreSQL, replaced 80 per cent of the manual data entry, and the advisers got hours back per week. The Access UI did not survive the project. The data shape mostly did.

If the Access app is doing what a custom CRM should do (clients, contacts, opportunities, activities, notes), the modernisation conversation is really a CRM conversation. We rename the project so the budget matches the scope. The same is true if the Access app is doing what an Excel-to-web-app rebuild would handle (a calculation engine with a thin UI). Naming the project for what it is matters because it changes who in the firm needs to be in the room when decisions are made.

The sequence that keeps the firm running

The way to lose money on an Access modernisation is to send the team home for two months while a new system is built. The way to do it cheaply is to keep Access running until the new system has been used for one full reporting cycle in parallel.

The sequence we run on these projects:

The first two weeks are the schema audit. We open the .mdb file, document every table, every query, every form event, and every macro. We name the owner of each layer. We test what each query actually returns against what the firm thinks it returns, because in roughly half of the rebuilds we do, the firm has been running on at least one query that has been quietly wrong for years.

Weeks three through six are the database build. The schema gets translated into Postgres or SQL Server. The queries become views or stored procedures. We build a thin internal tool to load test data and confirm every numerical output matches the Access output to the cent.

Weeks four through ten are the application build (overlapping with the database). If the project is path one (lift-and-shift), this is short, mostly relinking the Access tables to the new server and fixing the handful of forms that break. If the project is path two (full rebuild), this is the bulk of the work. Web app, role-based access, audit trail, mobile-friendly interface.

Weeks ten through fourteen are parallel running. The team uses the new system for new transactions. The Access database is still updated for the same transactions. Discrepancies get investigated, and almost always the Access database was the one that was wrong. We have caught audit-grade errors in the original database during this phase on projects where the firm was confident the Access numbers were clean.

After the parallel-run period, the Access database becomes the historical archive. The .mdb file goes into read-only storage. The new system is the source of truth.

This sequence costs more in elapsed time than a hard cutover. It costs less in disruption, retraining, and recovered errors. We have not seen a hard cutover work cleanly on an Access database that the firm was actually using day to day. The four limits we listed at the top become real risks during a hard cutover, because the team is leaning on a system that is already failing while a new one is being stood up.

If you are running on Access in 2026 and one of the four limits is firing, the conversation worth having is which path fits the firm. The diagnostic call we run before any rebuild surfaces this in about a week. We will tell you if the answer is lift-and-shift, full rebuild, or “the front-end is fine, hold for another year and revisit.” The honest answer is the cheapest answer that holds.