Two programmes travel under one label in most board papers, and they carry different risks, different owners and different finish lines. Digital transformation is a change to how an organisation delivers value to the people it serves: the services they receive, the decisions that shape those services, the data behind the decisions, and the operating model that holds the three together. Legacy system modernisation is narrower and harder. It is the work of moving an estate that runs today onto foundations that will still be supported tomorrow, with that estate serving its users throughout.
The first can be re-scoped when priorities move, and the cost of that is usually reputational. The second stops the service if it is paused, and the cost of that is usually operational. Treat the two as one programme and the modernisation timetable inherits the transformation's appetite, which is normally more optimistic than the estate can carry. Separating them is the first act of risk management on work of this kind: name what is changing about the business, name what is changing about the technology, then decide which release serves which. The comparison below runs between three specific commitments, each a particular piece of work: rehosting, replatforming and re-architecting.
Three commitments worth comparing
Rehosting moves an application and its workloads to new hosting with the code, structure and behaviour left in place. The estate is the same estate, standing somewhere else. The introduction to legacy system modernisation from Vega IT describes this as the route that moves systems quickly with minimal change, and makes a point that matters later: understanding the code structure is still required, because the next move depends on it.
Replatforming moves an application onto a different platform or a managed service, with code edited only where the new environment demands it. The application keeps its structure and its features, and it gains the operational characteristics of whatever now runs underneath it.
Re-architecting redesigns the application's architecture against modern standards, usually in phases, so that components and the boundaries between them change. It is the only one of the three that changes what the system is made of.
Each is a legitimate commitment on the right estate. Each is also a different promise about code, data, continuity, skills and debt, and those five promises are where the choice is actually made.
Where the code ends up afterwards
The question that settles most arguments about code is how much source is edited after the move, and who is competent to edit it.
Under rehosting, source is untouched. It may be recompiled or repackaged for the new environment, and its runtime relationships are rebuilt around it. The people who understood the application before still understand it afterwards, which keeps knowledge risk flat.
Under replatforming, edits cluster at the edges, where the application talks to storage, messaging, identity and scheduling. Internal logic stays as it was, which keeps the change reviewable and the test surface small.
Under re-architecting, source is rewritten against new component boundaries. Shared logic is separated, duplicated state is removed, and interfaces are specified instead of inherited. The result is easier to change over time and much harder to review, because the review burden falls across a codebase wider than any single team holds in view.
How data moves and in what order
Data sets the length of the project more often than code does, and each commitment answers the data question at a different moment.
Rehosting copies the datastore largely as it stands and can defer schema questions until after cutover. That deferral is a genuine advantage where nobody can currently describe the full schema.
Replatforming migrates schema and storage to the managed service and reshapes them where the platform requires it. Deferred questions come due here, and they arrive with a deadline attached to them.
Re-architecting redesigns the data model, assigns ownership to components, and turns sequencing into a design decision: which data moves first, which consumers change first, and what the system does while both copies are live.
The managing legacy technology guidance from GOV.UK places a complete and accurate register of data assets ahead of the move, on the grounds that the information in the system carries much of the system's value, and asks for that register to be checked regularly so that it stays current. Whichever commitment is chosen, this register is the document to test the choice against, because it is the artefact that tells you what a failure would cost in lost records and in lost trust.
Continuity risk at cutover
The control that matters most on the worst day is the reversibility of the cutover, and reversibility differs sharply between the three commitments.
Rehosting gives a single switchover with a short window. Rollback stays cheap for as long as the previous host keeps running and holds a valid copy of the data. The risk concentrates into one event, which is easy to rehearse, easy to schedule and easy to watch.
Replatforming gives a staged cutover, component by component. Rollback works per component, which limits the blast radius, and it depends on those components being cut over in a sensible order and on the interfaces between them being tested beforehand.
Re-architecting gives a long parallel run. Traffic moves gradually onto new components, which builds confidence, and once enough traffic has moved the old path cannot be restored without rebuilding it. The assessment from techUK makes the coexistence case: older and newer components can sit alongside one another, and integrating incrementally cuts cost and investment while leaving the option to integrate further as need and budget allow.
Skills and supplier dependence
Every one of these commitments relocates a scarce skill, and the scarce skill sets the real schedule.
Rehosting keeps legacy skills in demand. Nothing retires, so the people who know the old application remain critical to it, and the organisation stays exposed if they leave.
Replatforming adds platform and managed-service skills and keeps a narrower band of legacy knowledge, mostly around interfaces and data shapes. Exposure shifts from one individual to a small group, which is an improvement while remaining a live risk.
Re-architecting reduces legacy knowledge as components retire and raises demand for modern engineering skills. Supplier dependence tends to deepen, because work of this scope is rarely staffed entirely in house. The Cabinet Office Digital Handbook points at the commercial lever that keeps any of this from reversing: contract terms requiring regular updates and maintenance, negotiated at the start, are how a modernised system avoids drifting back into the legacy category within a few years.
Alithya's review of modernisation pros and cons adds the human risk underneath all three. It lists user acceptance among the cons, observes that a modern solution is useless if nobody uses it, and notes that upgrades usually begin as a management initiative. That argues for introducing users to the change well before they are asked to depend on it.
Debt and options left at the end
Judge each commitment by what it leaves behind, because the next programme inherits exactly that.
Rehosting repays hosting debt and leaves application debt untouched. The bill for old code arrives later, at its original size with interest added.
Replatforming repays debt at the platform boundary and defers the remainder. It produces a system that is cheaper to run without being fundamentally different, which is often the correct outcome.
Re-architecting restructures debt into new components. It also creates new debt, because new components need governance from the day they go live. Alithya lists time and cost among the cons and notes that returns can take years, and it advises estimating core operations first and concentrating effort there. Vega IT makes the related point that refactoring exists to reduce technical debt and names cloud-native foundations as a common destination for that work.
The comparison at a glance
| Attribute | Rehosting | Replatforming | Re-architecting |
|---|---|---|---|
| Code changes | None beyond repackaging | Confined to platform boundaries | Rewritten against new boundaries |
| Data handling | Copied as it stands | Migrated with targeted reshaping | Redesigned and reassigned to components |
| Cutover | Single switch, short window | Staged per component | Long parallel run, component by component |
| Rollback | Cheap while the old host remains | Available per component | Expensive once traffic has moved |
| Skills after the move | Legacy skills unchanged | Platform skills added, legacy interface knowledge retained | Modern engineering skills, legacy knowledge retired |
| Debt after the move | Unchanged | Partly repaid | Restructured, with new debt to govern |
The figures below come from Vega IT's review of legacy system modernisation, which collects them from a SnapLogic survey and published research.
| Measure | Figure |
|---|---|
| Businesses spending over this amount each year maintaining and upgrading legacy systems, at nearly two-thirds of those surveyed | $2 million |
| IT decision-makers with data trapped in systems they do not know how to move | 22% |
| IT decision-makers with undocumented data pipelines they are wary of updating | 79% |
| CIOs reporting that more than a fifth of the budget set aside for new products goes on technical debt | around 30% |
Choosing with the risk register open
Choose the commitment whose failure mode the organisation can survive, then manage everything else. Four questions, answered in writing before any commitment is made:
- Which components would stop the service if they failed mid-cutover, and how many of them this commitment touches.
- How long the previous environment stays available, and whether that is long enough to reverse the move.
- Who holds the knowledge needed to run the estate afterwards, and what retains them.
- What the register records about data location, security and handling, confirmed in the week before anything moves.
The GOV.UK guidance already sets out the triggers that justify starting: maintaining old technology costs more than replacing it, reduced efficiency blocks necessary service changes, supplier support ends, a contract expires, or the risk of carrying on becomes too great. Impact's review of legacy systems in digital transformation supplies the counterweight, noting that many transformation plans are judged to have failed because too many systems went in too quickly with no plan to embed them, and recommending that work begins with what is easy to update and produces a visible return. A modest first commitment, chosen against the register, keeps the second one possible.
Sources
- Managing legacy technology - GOV.UK
- Legacy Systems - Cabinet Office Digital Handbook
- Digital transformation – The introduction to legacy system modernisation | Vega IT
- Legacy systems modernization: pros and cons of a digital transformation | Alithya
- Legacy Systems in Digital Transformation: Risks & Challenges | Impact
- Digital Transformation: To Overhaul or Not to Overhaul Legacy Systems? | techUK