Legacy system decommissioning sits at the top of the "too hard" pile for most Australian government IT leaders. Agencies know the systems need to go. The costs are visible, the risks are documented, and the replacement platforms are often already live. Yet the old infrastructure keeps running, sometimes for a decade past its intended end date, consuming budget, staff time, and risk appetite that newer programs desperately need.
Federal agencies carry some of the most aged technology stacks in the country. The Australian Taxation Office spent years migrating off COBOL-based systems before its modern platforms could fully absorb the load. Services Australia still operates processes that touch mainframe-era infrastructure, even as its digital transformation program accelerates. The challenge isn't unique to Australia, but the local procurement environment and risk culture make it particularly acute here.
Why decommissioning stalls
The most common reason a legacy system outlives its replacement date is dependency mapping that was never properly done. Teams discover, late in a migration project, that 14 downstream systems rely on a batch file the old platform produces at 2am every Tuesday. That batch file was never documented. Nobody owns it. Three agencies depend on it. The decommissioning date slips six months, then twelve.
Data migration is the second most common blocker. Government systems accumulate decades of records in formats that don't cleanly translate to modern schemas. Tax records, welfare payment histories, licensing data: these can't simply be cut over. They require cleansing, validation, reconciliation, and sometimes legal sign-off before they move. A poorly scoped data migration can double the cost of an otherwise straightforward decommissioning project.
Budget cycles compound both problems. An agency might receive capital funding to build the replacement system, only to find that the operational budget to run the decommissioning project in parallel isn't approved. The old system becomes a cost centre that nobody officially owns but everyone unofficially maintains.
The technical debt dimension
Legacy decommissioning is inseparable from technical debt. Every year a system stays on past its end-of-life date, the debt compounds. Vendor support lapses. Security patches stop arriving. The staff who understand the system retire or move on. Documentation that was sparse becomes useless. By the time an agency finally commits resources to shutting the system down, they're decommissioning something that fewer than three people in the organisation fully understand.
This pattern shows up in state government IT projects just as often as at the federal level. A number of state health departments, for instance, operate patient administration systems built in the 1990s alongside modern electronic medical record platforms, because the cutover risks to live clinical services are judged too high to accept in a single migration window.
The ACSC has flagged unsupported software as one of the most persistent sources of vulnerability in government environments. An agency running a 2009-era case management system on an unpatched OS isn't just carrying technical debt. It's carrying active cyber risk, and that risk doesn't appear neatly on a project Gantt chart.
What the procurement rules add to the complexity
Decommissioning a government system isn't a purely technical exercise. It requires navigating procurement obligations that can themselves create delays. Contracts with incumbent vendors often include termination clauses that are expensive to trigger early. Data retention obligations under the National Archives of Australia Act require agencies to maintain records for specified periods, which means "turning off" a system rarely means destroying its data. The data must be migrated to an approved archive or kept accessible via a read-only interface, which still requires the underlying infrastructure to run.
Panel arrangements, discussed in detail in coverage of how agencies handle vendor lock-in in cloud contracts, can also complicate exits. If the replacement platform is on a different panel to the incumbent, transition costs fall in a gap between contracts that no single procurement instrument was designed to cover.
The governance gap at decommissioning time
Most government IT governance frameworks are built for building things. Approval processes, business cases, project management methodologies: all of these are oriented toward delivery. Decommissioning doesn't produce a deliverable in the traditional sense. It produces an absence, a system that no longer exists, a risk that no longer runs. That's genuinely hard to make compelling in a budget submission.
Agencies that decommission successfully tend to treat the shutdown as a project in its own right, with a dedicated sponsor, a named project manager, a defined scope, and explicit success criteria. They don't treat it as the final phase of the replacement project, because by the time the replacement is live, the original project team has usually disbanded and moved on. Decommissioning left as an afterthought rarely happens.
The Digital Transformation Agency has pushed agencies toward a lifecycle view of systems in recent strategy cycles, but the practical enforcement mechanisms are limited. The DTA can advise and publish standards; it can't compel an agency to shut down a system that the agency's leadership judges too risky to touch.
What agencies that do this well have in common
Successful decommissioning programs share three characteristics. First, they invest in dependency mapping before writing a line of replacement code. Knowing what connects to the old system is cheaper to discover at the start than at cutover. Second, they run the old and new systems in parallel for a defined, non-negotiable period with explicit exit criteria. "We'll turn off the old system when 95% of transaction volume has moved and three billing cycles have completed cleanly" is a condition you can actually meet. "We'll turn it off when we feel confident" is not. Third, they maintain a small, dedicated team whose only job is the decommission. Not the replacement. The decommission.
The cost of decommissioning done badly is paid in years, not months. A system that runs three years past its planned shutdown date doesn't just cost the direct operating expense. It costs the opportunity to redeploy that infrastructure budget, the risk premium of running unsupported software, and the cultural drag of telling staff that the new platform is the future while the old one still handles production load every night.
Australian agencies have the policy frameworks and the talent to do this better. The gap is almost always in governance and resourcing, not capability.