Legacy platform modernisation: a practical playbook for cloud-native migration

Every established business eventually has one: the platform that's been quietly running things for years, that nobody fully understands anymore, that's too load-bearing to touch and too creaky to leave alone. Modernising it well has almost nothing to do with rewriting code and almost everything to do with sequencing.

Why "just rewrite it" is the wrong first instinct

A full rewrite is the most intuitive response to an ageing platform and, most of the time, the most expensive way to fail. Big-bang rewrites take longer than estimated, freeze feature work on the old system for the duration, and — because nobody fully understands every quirk the legacy system has accumulated over years of real-world use — routinely miss edge cases the old platform quietly handled correctly. The business ends up running two systems, then cutting over under pressure, then firefighting the gaps for months afterward.

Modernisation done well rarely starts with "rewrite." It starts with understanding exactly what the current system does, for whom, and what actually breaks if a given piece goes down.

Assessment before architecture

Before any migration decision, the useful work is mapping: what are the critical operations this platform performs, what data flows through it and where does that data live, which integrations and dependencies does it have, and which parts of it are genuinely load-bearing versus which parts exist because nobody's had time to remove them. This map is what turns "modernise the platform" from a vague, risky mandate into a sequenced plan with a defined order of operations.

The incremental migration pattern

Rather than a single cutover, the pattern that actually holds up in practice is closer to the "strangler fig" approach: new, cloud-native services are built alongside the legacy system and gradually take over specific pieces of functionality, one bounded piece at a time, while the legacy system keeps running everything that hasn't been migrated yet. Traffic for a given capability moves across once its replacement has been running in production, verified against the old system's behaviour — not once it's merely "done" in a test environment.

This costs more calendar time than a rewrite would in the optimistic case. It costs dramatically less in the realistic case, because the business never stops running, and every migrated piece is de-risked before the next one starts.

Infrastructure management as an ongoing discipline

Modernisation isn't a project with an end date so much as a shift to an operating model. Cloud-native infrastructure needs to be actively managed: capacity and cost tuned as load changes, dependencies kept current and patched, deployments controlled through a proper change process, and the whole thing observable enough that a problem is caught by monitoring rather than a customer complaint. A migration that ends with "it's in the cloud now" but no ongoing management just relocates the original problem to a more expensive address.

What cloud-native actually buys you

• Elasticity. Capacity that scales with actual demand instead of a fixed server sized for a worst case that rarely happens.
• Observability. Real visibility into what the system is doing, not just whether it's up.
• Faster iteration. Infrastructure as code and proper CI/CD mean a change ships in hours, not through a change-freeze process measured in weeks.
• Cost visibility. What the platform costs to run becomes a number you can see and manage, rather than a lump sum buried in a hosting contract.

A sequencing checklist

• Have you mapped every critical dependency and data flow the current platform has — not just the ones that are documented?
• Can you name the single highest-risk, most load-bearing piece of the system, and have you deliberately chosen to migrate it early or late?
• Is there a rollback path for every piece you migrate, not just a forward plan?
• Who owns the infrastructure once it's modernised — is there a plan for ongoing management, or does the project end at cutover?

If those questions don't have confident answers yet, that's the actual starting point — not a rewrite, an assessment.