Cloud modernisation without breaking the business

Legacy systems are rarely legacy because they are bad. They are legacy because they work — they encode years of business rules, edge cases and institutional knowledge. That is exactly why “big bang” rewrites so often fail: the new system has to match a decade of behaviour on day one, and nobody fully knows what that behaviour is.

Successful cloud modernisation treats continuity as a first-class requirement. The business must keep invoicing, shipping and serving customers throughout the programme. The question is not “how do we move everything to the cloud?” but “how do we move value to the cloud without ever stopping the business?”

Every programme we run begins with a discovery phase that produces three artefacts: an application inventory, a dependency map and a risk register. The inventory lists every system, its owner, its users and its business criticality. The dependency map shows which systems talk to which — including the undocumented nightly CSV exports that everyone forgot about.

From this, each workload is classified using the familiar options: retire, retain, rehost, replatform, refactor or replace. In our experience, 10–20% of applications can simply be retired, which is the cheapest migration there is.

For core systems, we favour the strangler-fig pattern. A routing layer — often an API gateway — is placed in front of the legacy application. New capabilities are built as cloud-native services behind that gateway, and existing functions are migrated one by one. Over time, the old system handles less and less traffic until it can be switched off.

• Every step is small, reversible and independently testable.
• Users see continuous improvement instead of a risky cut-over weekend.
• The team learns the domain gradually rather than all at once.

“Modernisation should feel like a series of quiet improvements, not a single loud event.”

Before migrating the first production workload, invest in a landing zone: account structure, identity and access management, network design, logging, backup policies and cost tagging. Define everything as code using tools such as Terraform, and build CI/CD pipelines so every environment can be recreated on demand.

This upfront work feels slow, but it is what allows the tenth migration to take days instead of months. It is also where most security and compliance requirements are satisfied once, rather than re-litigated for every application.

Applications can be rebuilt; data must be preserved. Plan data migration with the same rigour as code: schema mapping, transformation rules, validation reports and rehearsals. For critical databases, change-data-capture replication lets the old and new systems run in parallel until reconciliation reports match exactly.

Always rehearse the cut-over at least twice in a production-like environment, with a written rollback plan and clear go/no-go criteria.

Moving a server to the cloud unchanged rarely saves money. Savings come from right-sizing, autoscaling, managed services, reserved capacity and switching off what is not used. Tag every resource by workload and owner from the start, review the bill monthly and make cost a visible engineering metric alongside performance and reliability.

A typical mid-sized modernisation runs in phases: discovery (3–6 weeks), foundations (4–8 weeks), a pilot migration of a low-risk workload, then waves of migrations prioritised by value and risk. Each wave ends with measurable outcomes — uptime, release frequency, cost per transaction.

Done this way, cloud modernisation becomes a steady programme of improvement that the business barely notices — except in the results.