--- type: Leaf title: Legacy Application Modernisation description: A staged approach to legacy application modernisation that keeps systems running while old code is replaced. See how it works. resource: https://nationaldigital.com.au/platform-engineering/real-time-systems/legacy-application-modernisation/ tags: - platform-engineering - Platform Engineering - Legacy System Modernisation - System Integration - legacy application modernisation - application modernisation - api development - cloud engineering - strangler pattern migration timestamp: '2026-10-13T08:29:29.742Z' language: en-AU publisher: National Digital author: Cameron Young authorRole: CEO readingTimeMinutes: 8 wordCount: 1570 datePublished: '2026-09-01' dateModified: '2026-10-13' pillar: platform_engineering canonical: https://nationaldigital.com.au/platform-engineering/real-time-systems/legacy-application-modernisation/ --- _Home — Platform Engineering — Real-time systems — Legacy Application Modernisation_ # Legacy Application Modernisation A staged approach to legacy application modernisation that keeps systems running while old code is replaced. See how it works. **Quick answer:** Legacy application modernisation wraps ageing business-critical software in APIs and migrates capabilities in stages, so operations keep running while each piece is proven. ## About this page - Written by Cameron Young, CEO - 8 min read - Updated 13 October 2026 _Platform Engineering — Legacy System Modernisation — System Integration_ ## What does legacy application modernisation actually involve? It wraps an ageing, business-critical application in modern APIs and migrates one capability at a time, integrating with tools like Xero or Shopify, so operations keep running throughout the project. **Additional Context** The term covers everything from re-platforming a single module to a full staged replacement, but the common thread is sequencing: nothing stops working while the underlying system changes. _High confidence · Verified 13 Oct 2026_ *Application Modernisation* ## What legacy application modernisation covers Most Australian businesses running a legacy application aren't dealing with one ageing system so much as a decade of integrations built around it. A warehouse management tool from the early 2010s, a quoting spreadsheet nobody can fully explain any more, and a direct database link into a retail [POS system integration](/platform-engineering/real-time-systems/pos-system-integration) that breaks every time someone renames a field. Legacy application modernisation addresses that whole surface, not just the oldest piece of code. The discipline sits at the intersection of system integration, cloud engineering and [API development best practices](/platform-engineering/real-time-systems/api-development-best-practices): wrapping ageing business logic in modern interfaces, moving the parts that genuinely benefit from managed infrastructure, and rebuilding only what can't be salvaged. Done well, it looks more like platform engineering than a rewrite project, building the scaffolding that lets the business keep trading while the pieces underneath change. ## Why staged modernisation beats a big-bang rewrite A full rewrite looks tempting on a whiteboard - clean slate, modern stack, no legacy debt - but it freezes every other change for the length of the project, and most growing teams don't have a spare year of frozen requirements. The staged alternative, often called the strangler pattern, wraps the legacy application in new interfaces and migrates one capability at a time, so finance keeps invoicing and the warehouse keeps shipping while the platform changes underneath. Getting the sequencing wrong is one of the more common [platform engineering anti-patterns](/platform-engineering/real-time-systems/platform-engineering-anti-patterns): teams migrate the easy modules first and leave the one everything else depends on until last, by which point the project has lost its budget and its champion. *Application Modernisation* ## Modernising a legacy application without stopping the business **Problem:** A business-critical application built a decade ago is now held together by workarounds: brittle point-to-point integrations, an approaching vendor support end-date, and staff quietly re-keying data between systems that were never meant to talk to each other. **Common Pain Points** - **Point-to-point integrations breaking silently** — Each new connection to Xero, Shopify or a courier API adds another brittle link that fails without warning when one side changes. - **Vendor support windows closing** — Unsupported platforms stop receiving security patches, leaving the business exposed while nobody owns the migration decision. - **Manual workarounds absorbing staff time** — Spreadsheets and re-keying fill the gaps the legacy system can't bridge, quietly becoming part of the daily routine. **Business Impact** - Time Wasted: Recurring manual reconciliation between disconnected systems each week - Cost Implication: Ongoing cost of duplicate licensing, workaround labour and delayed vendor patches - Opportunity Cost: New integrations, reporting and sales channels stay blocked while the legacy core can't support them **Solution:** A staged modernisation that wraps the legacy core in modern APIs, migrates one capability at a time, and keeps the current system live until each migrated piece is proven in production. **Our Approach** 1. **Map the integration surface** _(typically 2-4 weeks)_: Document every system, data flow and manual workaround touching the legacy application before changing anything, including the undocumented exports staff rely on. 2. **Wrap and strangle the core** _(typically 2-6 months depending on scope)_: Build modern APIs around the legacy system's functions, then migrate one capability at a time behind those APIs while the original system keeps running. **Expected Outcome:** A platform that integrates cleanly with current tools and takes on new requirements without the risk of a single big-bang cutover. *Key Takeaways* ## Modernise in stages, not in one risky cutover Legacy modernisation succeeds when it's sequenced around what the business can't stop doing, not around what's technically easiest to replace first. - **Staged modernisation keeps operations running throughout the project** Wrapping the legacy system in APIs and migrating one capability at a time means finance, warehouse and sales teams keep working normally while the platform changes underneath them. _Critical_ - **Map real integration traffic before planning the rebuild** Documented specifications rarely match what the legacy system actually does day to day, so instrumenting live traffic for a few weeks prevents building the new layer against the wrong assumptions. _Important_ - **Vendor support end-dates force the modernisation timeline** Once a platform stops receiving security patches, every month of delay adds exposure, which is why the decision to modernise is rarely optional once that date is fixed. _Important_ - **The hardest cost is reconciliation, not new code** Running the old and new systems in parallel during cutover, and keeping their data consistent, typically consumes more effort than writing the replacement functionality itself. _Important_ ## Why legacy modernisation can't wait indefinitely Ageing, disconnected applications carry risk that compounds the longer they stay in place, reflected in Australian government and regulator reporting on cyber exposure and data handling. - **Exploited vulnerability exposure: Known flaw exploitation** _Significance: high_ — ACSC reporting identifies exploitation of known, unpatched vulnerabilities in internet-facing systems as a leading way attackers gain initial access, a profile common in unsupported legacy applications still exposed to the internet. _(Source: Australian Cyber Security Centre, Annual Cyber Threat Report (cyber.gov.au))_ - **Breach contributing causes: System faults & human error** _Significance: high_ — OAIC's Notifiable Data Breaches reporting consistently lists human error and system faults among the leading causes of reportable breaches, categories that include misconfigured or poorly maintained legacy platforms. _(Source: Office of the Australian Information Commissioner, Notifiable Data Breaches Report (oaic.gov.au))_ - **Business digital reliance: Core functions online** _Significance: medium_ — ABS business characteristics data shows the large majority of Australian businesses now run core functions through digital systems, raising the operational cost of leaving any one of them on an unsupported platform. _(Source: Australian Bureau of Statistics, Business Characteristics Survey (abs.gov.au))_ **Methodology:** Figures drawn from published Australian Government and regulator reporting on cyber risk, data breach causes and business technology adoption, applied qualitatively to common legacy system patterns. *Implementation Reality* ## Mapping the integration surface before writing code Teams replatforming a legacy order management system usually discover the data model they're modernising around never actually matched the documented business rules. The schema was written once, then quietly diverged as staff built workarounds for edge cases nobody wrote down. The fix isn't more documentation before the project starts; it's instrumenting the legacy system's real traffic for a few weeks and building the new integration layer against what the business actually does, not what the original specification claims it does. Where the legacy application needs to stay synchronised with other systems during the transition - inventory counts feeding a website, orders arriving from several sales channels - [message queuing across time zones](/platform-engineering/real-time-systems/message-queuing) generally outperforms direct database polling, because it decouples the pace of the old system from the pace everything else needs to run at. A legacy system polled every five minutes looks fine in a demo, then drops orders the day a courier API has an outage and the queue backs up behind it. ## Sequencing the cutover so operations never stop Cutover sequencing is where most modernisation budgets actually get spent, and it's rarely the new code that costs the most. It's reconciling two systems that are both live and both being trusted by different parts of the business at the same time. The safest pattern runs the legacy application and the new capability in parallel, compares their outputs on real transactions, and only retires the old path once the comparison holds for long enough to trust it. For [real-time systems](/platform-engineering/real-time-systems) operating across multiple states, that parallel run also has to account for daylight saving shifts and interstate timestamp handling, which is exactly the kind of detail that gets missed when a cutover is treated as a single weekend event rather than a staged process. ## Plan a staged path off your legacy application National Digital maps the integration surface, sequences the migration, and keeps the current system running until each piece is proven. Talk to the team about where to start. - [Book a consultation](https://calendly.com/cameron-at-national-digital/discovery) - [Email the team](mailto:enquiries@nationaldigital.com.au) - Email: enquiries@nationaldigital.com.au - Phone: 1300 800 855 ## Legacy application modernisation, answered ### What does legacy application modernisation actually involve? It means wrapping an ageing but still business-critical application in modern interfaces, then migrating individual capabilities - reporting, inventory, invoicing - onto better infrastructure one at a time, rather than replacing the whole system in a single release. The legacy platform keeps running until each migrated piece is proven, which is what keeps day-to-day operations unaffected during the project. ### How is platform engineering different from DevOps on a modernisation project? DevOps focuses on the practices and culture that get code released safely and often. Platform engineering goes a layer further, building the self-service infrastructure, APIs and tooling that let application teams work independently of a central ops team. On a modernisation project, platform engineering is what makes the staged migration possible, creating the internal path that each newly modernised capability plugs into. ### Should the legacy system be rebuilt from scratch or integrated around? A full rewrite is rarely justified for Australian businesses still trading on the system they'd be replacing. It freezes other priorities for the length of the project and concentrates risk into one cutover. Integrating around the legacy core through APIs, then migrating one capability at a time, keeps the business operating and lets each stage be judged on its own evidence before the next one starts. ### How long does legacy system modernisation typically take? Timelines vary with how many integrations the legacy system touches and how much of its logic is undocumented. Treat any fixed date with caution until the integration surface has actually been mapped, and expect the project to run as a sequence of smaller releases rather than one large go-live, since that sequencing is what protects day-to-day operations. ### What's the difference between modernisation and a straight cloud migration? A cloud migration generally moves an existing application onto cloud infrastructure with its architecture largely intact, a lift and shift. Legacy application modernisation goes further, changing how the application is structured, integrated and exposed through APIs so it can actually use what the cloud offers, instead of running the same ageing code on someone else's servers. ### Where do APIs fit into a modernisation project? APIs are usually the first thing built, not the last. Wrapping the legacy application's core functions in a defined API gives every other system - Xero, Shopify, a reporting tool, a new front end - a stable way to talk to it while the internals are still being rebuilt underneath. That's what allows the migration to happen in stages instead of one risky cutover. ## Related reading - [Server-sent events for live updates](/platform-engineering/real-time-systems/server-sent-events/) - [Message queuing across Australian time zones](/platform-engineering/real-time-systems/message-queuing/) - [Real-time dashboards and timezone sync](/platform-engineering/real-time-systems/real-time-dashboards/) - [Platform Engineering Anti Patterns](/platform-engineering/real-time-systems/platform-engineering-anti-patterns/) - [Golden Path Platform Engineering](/platform-engineering/real-time-systems/golden-path-platform-engineering/) - [Pos System Integration](/platform-engineering/real-time-systems/pos-system-integration/) ## Related **Parent:** - [Real-time systems](/okf/platform-engineering/real-time-systems.md) **Related:** - [Server-sent events for live updates](/okf/platform-engineering/real-time-systems/server-sent-events.md) - [Message queuing across Australian time zones](/okf/platform-engineering/real-time-systems/message-queuing.md) - [Real-time dashboards and timezone sync](/okf/platform-engineering/real-time-systems/real-time-dashboards.md) - [Platform Engineering Anti Patterns](/okf/platform-engineering/real-time-systems/platform-engineering-anti-patterns.md) - [Golden Path Platform Engineering](/okf/platform-engineering/real-time-systems/golden-path-platform-engineering.md) - [Pos System Integration](/okf/platform-engineering/real-time-systems/pos-system-integration.md) - [Api Development Best Practices](/okf/platform-engineering/real-time-systems/api-development-best-practices.md) # Citations - [Annual Cyber Threat Report](https://www.cyber.gov.au/about-us/view-all-content/reports-and-statistics/annual-cyber-threat-report) — Unpatched, internet-facing vulnerabilities remain a leading initial access vector for Australian organisations. - [Notifiable Data Breaches Report](https://www.oaic.gov.au/privacy/notifiable-data-breaches/notifiable-data-breaches-statistics) — System faults and human error remain among the most common causes of reportable data breaches in Australia.