Support ends next year, so why can we not just move the entire application onto a supported cloud platform and fix the architecture afterwards?
Because the support date is a trigger, the target platform is a consequence, and neither of them is the first thing to settle. Examine behaviour first, platform next, and the evidence that the behaviour survived the move third. Everything below depends on that series of steps, so it is worth being exact about what replatforming is before any other decision is taken.
What replatforming changes, and what it must not
Legacy system replatforming changes the ground a system stands on. The operating system, the database engine, the scheduler, the hosting model and the language runtime are all in scope. The business logic is not. The system is expected to keep producing the same answers to the same questions for the same users, while the components that produce those answers are replaced or re-versioned underneath.
That distinction is what separates replatforming from a rebuild, and it is also what makes the route attractive. A system that already encodes years of decisions about pricing, entitlement, settlement or scheduling carries value that a new build would have to rediscover. Replatforming protects that value while removing the component that has fallen out of support. The obligation it creates is parity: the same inputs must produce the same outputs, including the awkward ones that surface at month end and nowhere else.
A software project that manages replatforming as a migration of files and services will meet the awkward cases after cut-over. The only reliable defence is to write down what parity means before the platform is selected.
Why an end-of-support date cannot carry the decision
The NHS AI and Digital Regulations Service guidance on planning for managing legacy systems and decommissioning defines a legacy system as outdated or unsupported technology that is still in use, and it frames migration and decommissioning as a comparison of risks. Retaining an unsupported system brings reliability problems, unknown data holdings and, where the supplier has withdrawn, the loss of the surveillance that used to catch defects and drift. Changing it brings risks of its own: data extraction, secure migration, staffing and cost. The guidance is best practice, written for healthcare, but the reasoning travels. An end-of-support date establishes how long the present arrangement lasts. It says nothing about which capability the system serves or what the organisation still needs from it.
What the behaviour record covers
Timeline Digital's guide to modernisation options puts the selection question in the right place. The right route depends less on the age of the technology than on whether the system still fits how the business works, whether the code can be changed safely, and whether staff can still support the platform it runs on. Each of those needs evidence, and evidence needs somewhere to live.
Call that place the behaviour record. It is a short document with four parts, written by the system operators. The document details the capabilities the system serves, the data for which it is the authoritative source, the interfaces that must still carry traffic after the move, and the behaviours the organisation has agreed to cease supporting. A target platform identified before this entry exists becomes a constraint that the entry is then written to fit, which is how software ends up preserving the wrong behaviour with great precision.
Four decisions that fix the scope
Replatforming collapses at the scoping stage far more often than at the technical one. Four decisions, taken one after another, remove most of that exposure.
- The limit of what the system can do. Name the business capability the replatformed component serves, and name the capabilities it must not disturb while the work is in progress. A limit set for technical ease will move when the business changes.
- The authoritative record. State which system owns each class of data during the transition, and the rule that decides what happens when both can write to the same record. Ambiguity here is what produces reconciliation that never closes.
- The surviving interfaces. List every interface that must carry traffic on the far side of the move, with the contact at the other end. An incident discovers an interface lacking a designated lead.
- The acceptance evidence. Agree what parity looks like and who signs it before the first slice is built. A sign-off defined after delivery is a negotiation.
What replatforming matches against other routes
Replatforming is one option among several, and it is rarely the right answer for an entire estate at once. The useful comparison is not which route is best in the abstract but which route matches the constraint actually in front of you.
| Route | What it changes | What it retains | Principal risk | Typical UK cost band |
|---|---|---|---|---|
| Rehost | Infrastructure only | Code, data model, screens | Carries existing technical debt onto new ground | £20,000 to £60,000 |
| Replatform | Runtime, database, managed services | Business logic and behaviour | Behavioural parity under real load | £40,000 to £150,000 |
| Refactor | Code structure, module by module | External behaviour by design | Scope creep inside a live system | £75,000 to £500,000 or more |
| Rebuild | The system itself | Data and the rules you choose to keep | The target moves while the build runs | £75,000 to £500,000 or more |
| Replace | The product | Data and process adaptation | Fit and adoption, not technology | £75,000 to £500,000 or more |
Cost bands are drawn from Red Eagle's 2026 guide to legacy software modernisation in the UK, which presents the routes as a decision matrix.
Where the risk actually accumulates
Devox Software's replatforming guide makes the point that structural parity is not enough. Data carries relationships, behavioural expectations, state logic and access control that the schema alone does not describe, and those properties can degrade silently once the application is decoupled from its original runtime. The check has to be behavioural, run under production-like conditions, and repeated across the state transitions that matter.
Catapult's guidance on modernisation strategies says data migration is one of the highest-risk parts of the work, and its account of what legacy data usually contains reads as a warning: duplicate records, inconsistent formats, undocumented transformations and dependencies invisible in the application code. The risk-averse response is to run data as its own workstream, with specified people in charge, written mapping rules, trial loads that execute more than once, and reconciliation approved by the business head of each data area before cut-over.
What the first slice must prove
Timeline Digital sets out the strangler fig approach that Martin Fowler named, in which a routing layer decides whether each request goes to the old system or the new one and capabilities move across one at a time. Calls9 explains the same practice from the delivery side: components move to the new platform with minimal change to structure, features and functions, and the result is introduced in phases so that operations continue.
The first slice is not a pilot of the platform. It is a proof of the route. Choose one capability with clear edges and visible value, put one routing rule in front of it, record which system owns the record during the transition, and delete the old path once parity is accepted. A slice that is finished only when the old code ceases receiving traffic is a slice that will not quietly rejoin the estate.
The steps to follow
The question at the top of this page has a defensible answer, and it is not no. Replatform when the platform is the constraint and the behaviour is still wanted. Settle the behaviour record first, take the four scoping decisions, choose the route that matches the constraint, treat data as a workstream in its own right, and prove the route on one slice before committing the estate. The support date starts the clock. It does not set the arrangement.
Sources
- Planning for managing legacy systems and decommissioning - AI and Digital Regulations Service for health and social care
- Legacy Replatforming Guide: When Fixing Is No Longer Enough
- Legacy Software Modernisation UK (2026 Guide: AI & Costs)
- Replatforming: The smart choice for modernising legacy systems
- Legacy System Modernisation: Strategies, Risks & Best Practices
