Legacy system modernisation is the work of deciding which old business systems to replace, which to rebuild in part and which to leave running. Most guidance assumes the answer is replace. For a system that still gets security updates, it usually is not. Even the Australian Signals Directorate’s advice is to replace legacy technology or put mitigations in place, and for supported systems the cheapest good outcome is usually a partial change.
Table of Contents
What is legacy system modernisation?
Legacy system modernisation means changing an old business system so it stops costing more than it should. That can be a full replacement, but it can equally be moving the data to a supported platform, rebuilding only the interface, wrapping the system in an API or keeping it running behind tighter controls.
The word legacy gets applied to anything that looks dated. A twelve-year-old Access database that runs a quoting process without complaint gets the label. So does a server that stopped receiving security updates years ago. One of those needs nothing. The other needs attention before anything else on the list.
Four tests sort one from the other, and age is not one of them.
- Supported: is the vendor still issuing security updates for it?
- Understood: can at least two people safely change it?
- Blocking: is it slowing daily work, or stopping a change the business has already decided to make?
- Exposed: can it be reached from outside your network?
Which legacy systems should you leave alone?
Leave a system alone when it passes all four tests: supported, understood, not blocking and not exposed. A system like that does not improve by being replaced. You would be buying a project and a migration risk to end up with the process you already have.
The Australian Signals Directorate lists “Replace legacy technology or put appropriate mitigations in place” as one of four key actions in its Annual Cyber Threat Report 2024-25 fact sheet for businesses, and nowhere in it tells a business to replace a system because it is old. We read the “or” as permission to spend the money where it does the most good.
Support status is the easiest test to settle: the vendor publishes it. For Access, start by opening File then Account, which shows the version you are actually running.
| If you are on | Support position | What to do |
|---|---|---|
| Access via a Microsoft 365 subscription | No fixed end date | Stays supported while the subscription and Windows stay current |
| Access 2016 or Access 2019 | Support ended 14 October 2025 | Upgrade the install |
| Access 2021, perpetual or LTSC | Support ends 13 October 2026 | Upgrade the install |
| Access 2024 or Office LTSC 2024 | Support ends 9 October 2029 | No lifecycle action before 2029 |
Microsoft publishes each of those end dates on its end-of-support lists for 2025, 2026 and 2029, and the 2026 list covers Access 2021 in both its perpetual and LTSC forms. The 2025 list also carries Windows 10, which usually touches far more of a business’s desktops than any Access version.
An out-of-support Access version is an install problem, not an application problem, and fixing it is not a modernisation project. The one trap is bitness. Microsoft’s 64-bit VBA overview notes that Office 2016 installed 32-bit by default while Office 2019 and Microsoft 365 default to 64-bit. A compiled Access front end built in 32-bit will not open in 64-bit Access. If yours is compiled, install the same bitness you run today, or find the source file and recompile, before anyone touches a desktop. About Access, on that same Account screen, shows which one you have.
How do you tell an old system from a risky one?
Two combinations decide on their own. A system that is unsupported and can be reached from outside your network gets replaced or isolated, whatever else is true. A system that passes all four tests (supported, understood, not blocking and not exposed) gets left alone. Everything between those two is a judgement call about which layer to change.
Isolating means cutting a system off from the internet and from the rest of the network so it keeps running where only the people who need it can reach it. For an old machine that runs one job well and cannot be upgraded, it is a legitimate answer.
Here is how we would call the system types we are asked about most. The verdicts are judgement applied to the four tests, not the output of a formula.
| System | Supported? | Main risk | Verdict |
|---|---|---|---|
| Access 2024 front end, SQL back end, documented | Support ends 9 October 2029 | Low, several people can edit it | Leave alone and review before 2029 |
| Access 2016 or 2019 perpetual install | No, ended 14 October 2025 | Unpatched desktop software | Not a modernisation decision. Upgrade the install and mind the bitness trap |
| Compiled Access front end, original developer gone | Depends on the Access version | Nobody can change it | Rebuild in part, but hunt for the source file first |
| Access database slowing or corrupting | Yes | Slowing daily work | Rebuild in part. Check the network path before moving the data layer |
| Excel workbook with macros one person maintains | On paper, yes | One person, no access control, no audit trail | Rebuild in part once it holds up work. Until then, document it and restrict who can open it |
| Unsupported server reachable from outside | No | Whatever an attacker decides | Replace or isolate. Not optional |
Two of those rows are where the expensive mistakes happen. A compiled Access front end was built from a source file, and that source often still sits in an old server folder, a backup set or the original handover. An afternoon of searching can turn a rebuild into a routine edit. A slow Access database is usually a size problem, but a corrupting one is usually a network problem, caused by connections dropping mid-write over Wi-Fi, a VPN or a laptop that goes to sleep. Before anyone prices a data migration to fix corruption, get someone to look at the network path.
What does it cost to leave a legacy system running?
For an old desktop database or spreadsheet that fails a test, the running cost is rarely the licence. It is the manual handling around the system, the one person who can fix it and the security exposure once patches stop. You can measure the first two inside your own business. For the third, national figures give a sense of scale.
Manual handling is the cost businesses underestimate most, because it has been absorbed into how people work. Someone re-keys the same order into two systems. A report gets rebuilt by hand every Monday. A quote takes forty minutes because the pricing sits in a spreadsheet the system cannot see. To put a number on it, count the minutes one person spends on the workaround, multiply by how often it happens in a month, then by a loaded hourly rate and put that figure in the business case.
Key-person exposure turns into a crisis without warning. A system only one person understands is fine until that person resigns. Then the business finds out that the thing running its quoting, invoicing or scheduling cannot be changed by anyone, and a modernisation project starts in a hurry instead of on a plan.
Security exposure is harder to size for a single business, so treat the national figures as an order of magnitude. In the 2024-25 financial year the ASD’s ACSC received over 84,700 cybercrime reports, and the average self-reported cost per report was $56,600 for a small business and $97,200 for a medium business, per the same ACSC fact sheet. Those averages cover all cybercrime, not only incidents involving legacy software.
Replace, isolate, rebuild or leave alone: how do you decide?
Decide in one scored pass over the whole estate, not system by system as complaints come in. Scoring everything at once gives you a queue ordered by risk instead of by whoever complained loudest, and it surfaces the systems nobody thought to mention.
Take a backup before any of this touches a live system, and do the assessment on a copy.
- List every system anyone depends on. Anything that would stop a process if it vanished on Monday counts, including the spreadsheets. Ask each team leader directly. The spreadsheets are where key-person exposure is usually worst, and a central list tends to miss them.
- Check support status. Use the vendor’s lifecycle page where there is one. If the vendor has gone or publishes nothing, treat the system as unsupported. A macro workbook passes this test on paper forever. Score it instead on whether it has access control and an audit trail. Most do not.
- Count the people who can safely change each system. Zero and one are both failing scores. The difference between one and two is the difference between a plan and an emergency.
- Ask what each system is holding up. Is it slowing daily work, or blocking a change the business has already decided to make? Either one counts.
- Check exposure in plain terms. Can it be reached from the internet, or only from inside the office? Is there a remote desktop or VPN door into it? If it also holds customer, staff or financial information, the stakes go up.
- Work out whether the data problem and the interface problem are the same problem. They usually show up together, and a slow screen is often a data-layer fault underneath, but the two layers can be replaced independently. This step establishes what is wrong. Splitting or moving a data layer is its own project with its own plan.
- Pick a verdict for each system: replace, isolate, rebuild in part or leave alone. Write the reason beside it. A verdict with no reason gets argued about again three months later.
A business system is a data layer with an interface sitting on top, and treating the two as one object is what turns a two-week job into a two-quarter project. Our Access to SQL Server migration guide covers the mechanics of moving the data layer while the front end stays where it is.
What does partial modernisation actually look like?
Partial modernisation replaces one layer and keeps the other. Either you keep the interface and move the data to a supported platform, or you keep the data and rebuild the interface on top of it. Keeping the interface means a data migration and its reconciliation. Keeping the data avoids migration entirely.
A professional services firm in Victoria ran jobs, quotes and work orders through a shared Access database. Screens were slowing as the file grew, backups made everyone nervous and corruption scares had already cost recovery time. We moved the data to Azure SQL and kept the forms and reports staff already knew. Nothing changed on the screens they used every day.
A promotional products supplier in regional New South Wales had the opposite problem. Every quote, order, freight calculation and factory instruction ran through an Access front end that still worked but could not be changed, because it had only ever been handed over compiled and the original developer was no longer contactable. The data was already in SharePoint and performing. So we rebuilt the front end as a Power Apps canvas app on the live lists, without migrating a single record. It carries over 100,000 quote, line item and pricing rows across fourteen SharePoint lists.
The size of those lists was the part we had to design around. SharePoint enforces a list view threshold of 5,000 items, and the pricing list holds more than 75,000 rows, so a view over it that was not indexed would fail with an error. That one is easy to spot. The dangerous one is quieter. When Power Apps cannot hand a query to the data source to run, it retrieves only the first 500 records, raisable to 2,000, and works on those. Microsoft’s own documentation warns that “a user might think a partial answer is the complete answer”. On a pricing list that means a quote that looks right and is wrong. That is why the queries that touch pricing had to be written for SharePoint to run itself.
What goes wrong when Australian businesses modernise?
Most modernisation failures are failures of scoping and judgement, not engineering. Three are worth planning against: rebuilding the old system feature for feature, letting the scope drift once work starts and replacing the system while keeping the process that made it slow.
Rebuilding feature for feature is the most expensive of the three. An old system accumulates behaviour that made sense once and has not been questioned since, and copying all of it forward means paying to rebuild decisions nobody would make today. The promotional products app works out order status from the dates already on each line. Nobody has to maintain a status field. That only works because status there really is a function of dates. Where a person sets it, on hold or cancelled or disputed, the field earns its place and should come across.
Scope drift usually arrives as a sentence that starts “while we are in here”. A job scoped as moving a data layer picks up a new report, then a new screen, then a change to how quotes get approved, and months later it is a rebuild nobody costed. Hold every addition against the verdict you wrote down when you scored the system.
The third failure is the quietest. Businesses replace a system and keep the process, then wonder why the new one feels like the old one in a different colour. If quoting took forty minutes because the pricing sat somewhere the system could not reach, a new quoting screen over the same pricing changes very little. Where a full rebuild is the right call, our guide to what Power Apps can do for a business covers what the platform handles well and where it runs out, and the three paths out of a spreadsheet process covers the same decision for Excel, where data and interface live in one file and cannot be pulled apart the way an Access front end and back end can.
Frequently asked questions
What is an example of legacy modernisation?
A promotional products supplier in regional New South Wales had a compiled Access front end nobody could change, sitting on SharePoint data that was performing well. The front end was rebuilt as a Power Apps canvas app on the live lists, carrying over 100,000 records across fourteen lists without migrating any data. The old interface went and the data stayed where it was.
How many companies still use legacy systems?
There is no reliable Australian figure. The numbers quoted online usually trace back to vendor research, not to a survey you can check. A more useful question is how many of your own systems pass all four tests: supported, understood, not blocking and not exposed. A scored pass over the estate answers that in a day or two.
Is replacing a legacy system worth it?
When a system is both unsupported and reachable from outside your network, replacing or isolating it is worth it on its own, and that decision does not wait for anything else. A supported system that two people can change, that is not holding up work and that cannot be reached from outside is not worth replacing, whatever its age. Everything in between is a judgement about which layer to change, and sometimes the answer is only an upgraded install.
How do you maintain a legacy system you have decided to keep?
Two jobs, and they are different. Mitigation means restricting who and what can reach the system and keeping backups somewhere the system itself cannot corrupt. Maintenance means documenting it so a second person can change it and putting the vendor’s end-of-support date in a calendar. Do both. A documented system that anyone on the internet can reach is still a problem.
Can you modernise without migrating the data?
Often, yes. Where the data already sits on a supported platform and performs, the interface can be rebuilt on top of it while the records stay put. That removes the slowest and riskiest part of most projects. It depends on the data layer holding up at its current size, which comes down to row counts, indexing and whether queries can be handed to the data source to run.
Where to start
Start with one scored pass over every system anyone depends on, against the four tests: supported, understood, not blocking and not exposed. On a normal estate that takes a day or two, and longer for anything nobody can open or explain.
Expect to come out of it with a short list that needs work now, a longer list that needs documenting and a few systems that clear all four tests. If you want a second opinion on which is which, our legacy system modernisation service starts with that assessment, and the wider custom apps and portals practice covers what happens once a verdict is written. Book an intial consultation and bring the list, spreadsheets included.
