Most South Australian agencies, councils and established SMEs run at least one system that nobody wants to touch: a line-of-business application built a decade or more ago, on a framework or database version that is out of support, understood by one or two people, and wired into everything else. Legacy application modernisation is the work of moving that capability onto a supportable, secure platform without breaking the services that depend on it. This guide explains the options in plain English — retain, retire, rehost, replatform, repurchase and rebuild — when each fits, why incremental replacement usually beats a big-bang cutover, and what buyers should put in an RFQ or RFT so the project is scoped honestly. It is practical guidance, not procurement or legal advice.
Why legacy systems become a business problem
An old system is not a problem because it is old. It becomes one when it creates risk or cost the organisation can no longer carry. The common triggers are:
- Security patching stops. Unsupported operating systems, runtimes and databases cannot be patched, which works directly against the Essential Eight strategies for patching applications and operating systems. See our Essential Eight guide for SA SMEs.
- Skills disappear. The developer who understood the code moves on, and the vendor has been acquired or no longer exists.
- Integration is impossible. No APIs, so every new digital service needs manual re-keying, overnight file drops or screen scraping.
- Accessibility and user experience fall behind. Citizen-facing screens that cannot meet WCAG 2.2 AA become a compliance risk, not just a design complaint.
- Hosting is fragile. A single on-premises server, a lapsed hardware warranty or an untested backup turns a routine failure into an outage.
Write down which of these actually applies. The trigger decides the option: a patching problem may be solved by replatforming, while an integration problem may only need an API layer in front of the old system.
The modernisation options in plain English
Cloud providers describe these as the “R” strategies. The labels matter less than the decision each one represents.
| Option | What it means | When it fits | Main trade-off |
|---|---|---|---|
| Retain | Keep it, harden it and wrap it with monitoring and backups | Low change, still supported, replacement planned later | Defers cost but not the problem |
| Retire | Switch it off and archive the records | Little remaining use, or the function now lives elsewhere | Needs a records and archive plan before shutdown |
| Rehost | Move the same application onto cloud infrastructure in an Australian region | Hardware or data centre exit is the urgent driver | Fast, but keeps the old code and its limits |
| Replatform | Move to supported runtimes and managed services, such as a managed database, with small code changes | The code is sound but the platform is out of support | Moderate effort; needs regression testing |
| Repurchase | Replace it with a SaaS or commercial product | The process is standard and a mature product exists | Process change and data migration; less control over the roadmap |
| Rebuild or refactor | Redesign the capability as new, supportable software | The process is distinctive and the system is core to service delivery | Highest effort and risk unless delivered incrementally |
One estate usually needs several of these at once. A council might retire an old reporting tool, repurchase payroll, rehost a GIS server and rebuild a customer request workflow. Treat the portfolio as a set of decisions, not one project.
Big bang or incremental replacement
A big-bang cutover replaces the whole system on one weekend. It looks simpler on a Gantt chart, but it concentrates every risk — data migration, training, integrations and performance — into a single event that is hard to reverse. For systems that support citizen or staff services, we usually recommend incremental replacement, often called the strangler fig pattern:
- Put a routing layer, such as an API gateway or reverse proxy, in front of the legacy system so callers no longer talk to it directly.
- Rebuild one capability at a time, such as lodging a request or checking a status, and route that traffic to the new service.
- Keep the data in step with change data capture or scheduled synchronisation while both systems are live.
- Retire each legacy function once the new one has run cleanly for an agreed period, and finally decommission the old system.
Each step is small, testable and reversible by switching the route back. Our reference architecture for legacy system modernisation with the strangler fig pattern shows the routing facade, anti-corruption layer and data synchronisation in detail, including failure modes and recovery.
The trade-off is honest: incremental delivery means running two systems for a period, which carries hosting, licence and support overlap. Budget for that dual-running window explicitly rather than discovering it halfway through.
Data migration is the real project
Most modernisation overruns come from data, not code. Legacy databases hold years of inconsistent records, free-text fields used for things they were never designed for, and business rules buried in stored procedures. Plan for:
- Profiling early. Measure data quality in discovery so cleansing effort is estimated, not guessed.
- Mapping with business owners. Someone who knows the process must sign off how each field moves, merges or is dropped.
- Reconciliation. Agree counts and totals that must match between old and new before each cutover.
- Rehearsals. Run the migration end to end at least twice in a non-production environment, timed, before the real one.
- Records obligations. Public sector records in South Australia are governed by the State Records Act 1997 (SA) and approved disposal schedules. Archive or migrate records in line with them, and confirm requirements with your records team before anything is deleted.
Bridging the gap with APIs and automation
You rarely need to replace a system before you can integrate with it. An API or integration layer in front of the legacy application lets new digital services, portals and reporting connect once, cleanly, while the back end is modernised behind it. Our API-led integration hub architecture shows how that layer is governed.
Where a legacy system has no API at all, robotic process automation (RPA) can drive its screens as a temporary bridge. Treat RPA as scaffolding with a removal date, not a permanent integration. Our guide to RPA versus AI for government process automation explains where each fits.
Security and data residency during the transition
The transition period is when security is weakest: data is copied, temporary accounts exist and integrations are new. Build controls into the plan, not after it:
- Host the new platform and all migration copies in Australian regions, and say so in the design. See Australian data residency for SA Government ICT.
- Use named, time-limited accounts for migration tooling and remove them at the end.
- Mask or minimise personal information in non-production environments.
- Keep backups of both systems until the legacy system is formally retired, and test restores. Our backup and disaster recovery guide covers what to require.
- Map controls to the expectations in the tender, such as the SA ISMF. See SA ISMF for ICT suppliers.
What buyers should put in the RFQ or RFT
Modernisation tenders go wrong when they ask suppliers to price a full rebuild of a system nobody has documented. Better outcomes usually come from structuring the work in stages:
- A fixed-price discovery phase. Current-state inventory, integrations, data profiling, option assessment and a costed roadmap. This de-risks the larger spend.
- Clear decision criteria. Say whether the priority is cost, speed, risk reduction, user experience or supportability, so suppliers can recommend the right option rather than the biggest one.
- Cutover and rollback requirements. Parallel-run criteria, reconciliation sign-off and a tested way back for each release (see our guide to software testing and UAT for SA Government and council projects).
- Decommissioning in scope. Shutting down the old system, archiving records and cancelling licences should be a deliverable, not an afterthought.
- Knowledge transfer and documentation. Architecture diagrams, runbooks and source code ownership, so you are not creating the next legacy system.
Suppliers should answer with evidence: a sample discovery report outline, a migration and reconciliation approach, a cutover runbook template and a named delivery team. Our guide to winning SA Government ICT tenders covers how evaluators read those responses.
Common failure modes
- Rebuilding everything the old system did, including features nobody uses. Validate usage before replicating it.
- Underestimating hidden integrations: overnight exports, spreadsheets and reports that quietly depend on the legacy database.
- Cutting over without a rehearsed rollback.
- Letting the legacy system keep running indefinitely after go-live, so the organisation pays for both.
- Treating modernisation as a technology project without the business owners who know the process.
A practical checklist
- Name the trigger: security, skills, integration, accessibility or hosting
- Choose an option per system, not one approach for the whole estate
- Prefer incremental replacement for anything citizen or staff facing
- Profile data and agree reconciliation rules in discovery
- Keep the new platform and migration copies in Australian regions
- Budget for dual running and for decommissioning
- Require documentation, runbooks and code ownership at handover
This article reflects common practice as at late 2026. Cloud services, vendor support dates and agency policies change, so confirm current requirements and the tender documents before committing to an approach.
Talk to an Adelaide team
If you are planning to replace or modernise a legacy system, or scoping a discovery phase for an SA agency, council or business, discuss your project with our team or call 0402 401 584. We reply within one business day. You can also read about our application development and DevOps and cloud services.