Mainframe and AS/400 Modernisation for Australian Enterprises

Australian organisations modernising mainframe and AS/400 (IBM i) systems generally choose between two pathways: incremental decoupling, which extracts and modernises functionality piece by piece while the legacy core keeps running, and full replatforming, which migrates the entire system to a new platform through a single, larger-scope programme. The right choice depends on how tightly the legacy system is coupled to regulated processes, how much operational risk the organisation can absorb at once, and how urgently new capability is needed.

Many of Australia's largest insurers, manufacturers and logistics operators still run core policy administration, inventory, warehouse management or claims processing on mainframe or AS/400 systems. These platforms were built to last, and in many cases they still do the job reliably. The problem is not reliability — it's everything built around the platform: the shrinking pool of COBOL and RPG specialists, the difficulty integrating with modern APIs and cloud data platforms, and the growing gap between what the business wants to build and what the core system can support.

This guide sets out the practical pathways available, and the trade-offs between incremental decoupling and full replatforming, for technical leaders weighing up where to start.

What is mainframe and AS/400 modernisation?

Mainframe and AS/400 modernisation is the process of reducing an organisation's dependency on legacy core systems — whether by extracting functionality piece by piece, migrating to new platforms, or rebuilding capability entirely — so that the business can integrate with modern cloud, data and AI tooling. It is not a single project with a fixed endpoint; it's a multi-year programme that most organisations approach in stages rather than one cutover event. For a broader look at how this fits into a wider modernisation programme, see our guide to application modernisation.

Why are legacy core systems still in production at large Australian organisations?

Core mainframe and AS/400 systems persist because they are stable, auditable, and deeply embedded in regulated business processes — particularly in insurance claims and policy administration, manufacturing MRP, and logistics warehouse and freight systems. Replacing them carries real operational risk, which is why many organisations have deferred modernisation for years. The trigger is usually external: a platform end-of-life notice, a compliance or security audit finding, a leadership transition, or a competitor shipping features the legacy stack simply cannot support. None of these triggers mean the whole system needs to be torn out at once — they mean it's time to have an honest conversation about pathway and sequencing.

What are the main modernisation pathways?

There is no single correct pathway — the right approach depends on how tightly coupled the legacy system is to surrounding processes, how much regulatory and audit risk the organisation can absorb at once, and how urgently new capability is needed. Broadly, organisations choose between incremental decoupling (extracting and modernising functionality piece by piece while the legacy core keeps running) and full replatforming (migrating the entire system to a new platform in a planned, larger-scope programme).

Consideration	Incremental decoupling	Full replatforming
Risk profile	Lower per-change risk, spread over time	Higher concentrated risk, especially at cutover
Time to first value	Faster — individual capabilities modernised early	Slower — value typically realised at or near completion
Disruption to business-as-usual	Lower, legacy system continues operating	Higher, requires parallel-run and migration planning
Suitability	Organisations with complex, deeply embedded legacy processes	Organisations with a clear end-of-life deadline or stable, well-documented scope
Governance overhead	Ongoing, iterative sign-off per module	Concentrated around a smaller number of major milestones
Long-term technical debt	Can leave residual legacy components if not sequenced carefully	Fully retires legacy platform if scope is delivered completely

How does incremental decoupling work in practice?

Incremental decoupling typically uses a pattern where new functionality is built around the legacy core and traffic is gradually redirected to the new components until the legacy system can be retired piece by piece. This is often described using the strangler fig pattern, which we cover in more detail in our piece on application modernisation and the strangler fig pattern. For insurers and logistics operators with core systems tightly coupled to regulated processes, this approach lets the business keep operating while new capability — APIs, data pipelines, customer-facing features — is delivered in parallel, without betting the whole programme on a single cutover.

When does full replatforming make more sense?

Full replatforming tends to be the better option when the legacy platform has a hard end-of-life date, when licensing or vendor support costs have become unsustainable, or when the scope of the legacy system is well understood and bounded enough to plan a complete migration with confidence. It carries more concentrated risk than incremental decoupling, so it requires strong architecture planning, a realistic cutover and parallel-run strategy, and clear ownership of data integrity throughout the migration. Manufacturers replacing an ageing AS/400 MRP system ahead of a broader ERP consolidation, for example, may find replatforming more tractable than trying to decouple modules that are too interdependent to extract safely.

How do you choose between a consultancy-led and a tooling-led approach?

The right delivery model depends on how mature your existing cloud and modernisation capability already is. Organisations early in their cloud and modernisation journey often benefit from a consultancy-led approach — pairing architecture expertise with hands-on delivery, so the organisation ends up owning and understanding the resulting system rather than depending indefinitely on an external tool vendor. Organisations with more mature internal platform teams may lean more heavily on tooling-led, automated migration, using outside expertise mainly for architecture review and governance rather than full delivery. In practice, most engagements blend both: a consultancy-led assessment to establish pathway and sequencing, supported by appropriate tooling where it genuinely speeds up low-risk, repeatable migration work.

At Horizon Labs, we typically start this conversation with a technical architecture review before moving into application modernisation delivery — whether that's incremental decoupling using the strangler fig pattern or a planned replatforming programme. Where the end goal includes AI-powered features — claims automation, predictive maintenance, demand forecasting — the modernisation pathway needs to be sequenced with ai product strategy and ai engineering in mind from the outset, rather than bolted on afterwards. A legacy core system with no API layer and no structured data access makes AI adoption far harder, regardless of how capable the underlying models are. We're honest about this: modernisation has to come first in most cases, and there's no shortcut that avoids the underlying architecture work.

For related reading on legacy migration and modernisation approaches, browse more insights from our team.

If you're weighing up where to start with a legacy mainframe or AS/400 system, get in touch — we can talk through the pathway that fits your risk tolerance, regulatory constraints, and timeline.