Microsoft Access is not being retired; it still ships with Microsoft 365 Apps and runs reliably. The real question is whether a core business process should still depend on a single .accdb file on a shared drive. If the database is 15 years old and business-critical, it deserves a modernisation plan, and there are four practical paths.
Plenty of Australian businesses still run quoting or job tracking on an Access database someone built in 2010. That is not a failure. Access made it possible to build real software without hiring a development team, and many of those databases have quietly paid for themselves many times over. The point of this guide is to separate the databases that should be left alone from the ones that have become a genuine operational risk, and to match each situation to the lightest fix.
Is Microsoft Access being retired?
No. Access is still included in Microsoft 365 plans that come with the desktop apps, and Microsoft has announced no end-of-life date for the product. What does expire is support for individual perpetual versions: Access 2016 and 2019 reached end of support in October 2025, and support for Access 2021 ends on 13 October 2026. A business on a Microsoft 365 subscription simply keeps receiving the current version.
So the anxiety behind the question is misplaced, but the question itself is fair. A database designed for one office and five users in 2011 may now sit underneath scheduling for a 60-person operation. Access has not changed; the weight resting on it has.
What does Access still do well?
An honest assessment cuts both ways, and Access earns its keep in more situations than its critics allow.
- Small-team desktop databases. For a handful of users on one site entering and reporting on structured data, Access remains genuinely hard to beat on speed and cost.
- Prototyping. A working forms-and-reports application can exist within days, which is why so many of these systems were built in the first place.
- Price. Access comes with many Microsoft 365 subscriptions, so there is no extra licence to buy and nothing new to learn for an experienced user.
Where does a 15-year-old Access database start to hurt?
The trouble rarely announces itself. It accumulates as workarounds until someone finally tallies them. These are the pressure points Frontrow sees most often.
- Multi-user strain. An Access file on a network share supports 255 concurrent connections on paper, but stability degrades with far fewer, and a dropped connection mid-write can corrupt the file. The 2 GB file size cap is also absolute.
- No web or mobile access. The database lives on the one PC or file share it was set up on, so field staff phone the office to look things up.
- Key-person risk. The person who built it has often left the business. The rules that run the company sit in queries and VBA that nobody remaining can read.
- Backup gaps. A file that is open all day is often not backed up cleanly, and few businesses have ever tested a restore of it.
- Audit and compliance. Access has no built-in audit trail, and cyber insurance questionnaires and client security reviews increasingly ask questions a shared .accdb file cannot answer well.
What are the modernisation paths?
There are four, ordered from least disruptive to most. The right one depends on what the database actually does, not on how old it is.
Path 1: keep the Access front end, move the data to Azure SQL
Microsoft publishes a free tool, SQL Server Migration Assistant for Access, that moves the tables and data into SQL Server or Azure SQL Database. Forms, reports and VBA are not converted; they stay exactly where they are and reconnect through linked tables, so users see the same screens the next morning. The size cap and the concurrency trouble disappear, and the data lands inside a proper backup regime. Where the front end still does its job, this is the least disruption for the most risk removed.
Path 2: rebuild in Power Apps with Dataverse
This is the mainstream path Microsoft provides for exactly this situation. Power Apps rebuilds the forms and logic as a web and mobile application, with the data held in Dataverse. Dataverse brings role-based security and a real audit trail. It is backed up automatically and works from a phone on site as readily as from a desk.
On licensing: Power Apps Premium is AU$29.90 per user per month paid yearly on Microsoft's Australian pricing page, excluding GST, with an AU$18.00 tier at a 2,000-seat minimum (checked July 2026). A pay-as-you-go option billed per active user per app through Azure suits apps that some staff open only occasionally.
Path 3: move simple registers to Microsoft Lists
If the database is really one or two tables, a plant register or a contract log, it may not need a database platform at all. Microsoft Lists is included in Microsoft 365 business and enterprise plans at no extra cost, sits on SharePoint, and covers custom views and simple reminder rules from any browser. It is the wrong tool for genuinely relational data, but a surprising share of old Access files are just lists wearing a nice form.
Path 4: complex line-of-business systems justify real development
A minority of Access applications have grown into the operational core of the company, with dozens of forms and integrations into accounting or dispatch. Forcing one of those into a low-code rebuild can cost more than building properly. For that tier, a purpose-built application on Azure, designed after the processes have been mapped, is the honest recommendation.
What does a migration actually involve?
The data transfer is rarely the hard part. A 15-year-old Access application encodes years of undocumented business rules in its queries and VBA, and the migration succeeds or fails on how well those rules are understood before anything gets rebuilt.
- 1Process mapping. Sit with the people who use the database and document what it actually does, including the workarounds that never made it into the system.
- 2Data cleanup. Old databases carry duplicates, orphaned records and fields repurposed for something other than their label. Clean before moving, not after.
- 3Staged build and parallel run. Operate the new system alongside the old one on live work for a defined period, and reconcile the outputs before anyone commits.
- 4Training and cutover. Switch over in a quiet week, keep the old file read-only for reference, and retire it formally so it cannot creep back into use.
As a guide, a register moving to Microsoft Lists is days of work. A data move to Azure SQL behind an existing front end typically lands within a few weeks including testing. A Power Apps rebuild of a mid-sized application usually runs two to four months elapsed, and complex multi-module systems should be scoped in stages rather than estimated in one number.
Where does AI fit?
Two places, neither of them magic. Copilot in Power Apps lets a maker describe an application in natural language and generates Dataverse tables and starting screens, which takes real time out of the early build. The larger gain arrives after migration: once the data is out of a desktop file and inside Dataverse, agents can work with it. Frontrow's Applied AI practice builds agents that chase missing paperwork or summarise a job's full history before a site visit, none of which is possible while the data lives in an .accdb on someone's C: drive.
For the MD or operations manager reading this alongside that exact database, Frontrow runs a working session built for the situation: half a day with the people who use it, mapping the processes the Access file really performs, followed by a written recommendation on the lightest workable path off the risk. Sometimes that is a two-day data move rather than a rebuild, and Frontrow will say so.