MS Access to Web App: An Australian Migration Playbook (2026)

If you're reading this, you almost certainly have an MS Access database that runs more of your business than anyone is comfortable admitting. Probably built years ago by someone clever, probably hosted on a shared drive, probably has at least one report that breaks if the wrong field gets edited.

This post is a practical, Australian-context playbook for migrating off MS Access to a modern web application — what it actually costs, how long it takes, what the strangler-fig approach means in practice, and how to avoid the common traps.

Why Access stops working at scale

Microsoft Access was a brilliant tool for its era and it still works. The problems that bring SMBs to a migration project are usually the same handful:

• Concurrency. Access starts breaking around 5–10 simultaneous users. Lost records, file locking, "the database is in an inconsistent state" errors that get worse as the team grows.
• Remote access. Working from home, the Gold Coast office, or a job site? Access on a network share over a VPN is painful or impossible.
• Backups and disaster recovery. A single .accdb on a shared drive is one accidental delete from a very bad week.
• Mobile. Access is desktop-only. Field staff with phones can't use it.
• Integration. Connecting Access to Xero, MYOB, Stripe, or a modern CRM is non-trivial. Modern web apps integrate via API in days; Access integrates over months and brittle macros.
• The author left. The original developer is gone. Nobody alive understands the macros. Adding a field is a multi-week project of archaeology.
• Compliance. ACSC Essential 8 alignment, encryption-at-rest requirements, audit trails — these are awkward-to-impossible in Access.

The honest cost of an Australian Access migration

Calibrated against our own scoped projects from 2024–2026:

• Small Access database (5–15 tables, 1–3 reports, 2–5 users): AU$25,000–$50,000.
• Medium Access database (15–40 tables, 5–10 reports, 5–15 users, some macros): AU$50,000–$100,000.
• Large Access system (40+ tables, complex macros, 15+ users, integrations): AU$80,000–$200,000.

Timelines: 8 weeks to 24 weeks depending on scope. The expensive scope drivers are usually: (a) heavy macro logic that needs reverse-engineering, (b) reports with hand-written SQL that rely on Access-specific quirks, (c) integrations the Access version was doing via macros that need re-implementing properly.

The strangler-fig approach (and why big-bang fails)

Big-bang migration — where you rebuild the system, then switch over on launch day — fails roughly half the time. We've seen the autopsies. The failure mode is always the same: the new system goes live, edge cases appear that weren't in the old system's docs (because nothing was), the team can't do their jobs, panic ensues, the old system gets resurrected, the project is declared a failure.

The strangler-fig pattern (named after the strangler fig tree, which gradually surrounds and replaces its host) does this differently:

1. Stand up a new web app alongside the existing Access database. Both run.
2. Migrate one feature at a time. Pick the highest-pain feature first — typically the one with concurrency issues. Build it in the new web app, with data syncing back to Access for the moment.
3. Switch users for that one feature. Reports on customer table, say, now run from the new web app. Access still handles everything else.
4. Repeat for the next feature. Bookings, then invoicing, then the master customer list, etc.
5. At some point, the new app holds enough features that Access becomes optional. Switch off Access entirely. Done.

This means: you see real value from week 6, not week 60. Risk is contained per feature. Rollback is easy (just route the feature back to Access). And critically — your team learns the new app gradually, instead of being thrown in at the deep end on go-live day.

The data migration plumbing

Three layers, in order, every time:

1. Automated migration scripts

Scripts run against a copy of your Access database into a test PostgreSQL or SQL Server instance. We rerun them dozens of times during development, refining each time until counts and checksums match perfectly. Source-system IDs are preserved as foreign keys in the new database — every record can be traced back to its Access origin.

2. Parallel-run period

For 2–4 weeks before final cutover, both systems are live. Staff use the new system for the migrated features. We reconcile daily — comparing record counts, checksums, and a sample of full records between Access and the new database. Any drift gets investigated and fixed.

3. Cutover with rollback

The actual cutover is anti-climactic by design. Routing changes; new system is now authoritative. Rollback procedure is documented and tested. We've never lost client data on a migration done this way — the parallel-run period is where everything that could go wrong gets caught.

What you're replacing Access with

For most SMB Access migrations, the modern stack is some combination of:

• PostgreSQL or SQL Server as the database. PostgreSQL is the open-source default; SQL Server is the natural choice if you're a Microsoft shop. Both have Australian-region hosting on Azure and AWS.
• A web app built in Next.js (React) or Blazor (.NET). For most SMBs, the web app replaces both the Access UI and the "reports" that previously had to be exported and reformatted.
• Reports as in-app dashboards for live data, plus scheduled PDF/email reports for the things people actually like in their inbox.
• Authentication that works from anywhere — including 2FA, which Access never supported.
• Backups and audit trails that meet modern compliance expectations (ACSC Essential 8, Australian Privacy Principles).

When NOT to migrate

We'll honestly tell prospects to leave Access alone if:

• The system is genuinely stable, used by 1–3 people, and isn't blocking anything.
• Nobody's asking for changes (the "dead but reliable" case).
• The business itself is winding down or being sold; the migration cost won't pay back.
• You've got a clear path to retiring the system entirely (e.g., switching to SaaS) — in which case migrate to the SaaS, not to a new custom web app.

For everything else — particularly cases where Access is hurting growth, blocking remote work, or creating audit risk — modernisation is one of the highest-ROI projects an Australian SMB can undertake.

Get a free Access audit

We offer a free 60-minute Access audit for Australian businesses. We'll review your database over screen share, identify the realistic modernisation paths, and give you a written summary with cost ranges and timelines. You own the summary regardless of whether you proceed with us.

Book your free Access audit. Brisbane-based, Australia-wide remote, same-timezone delivery.