Rehosting can put a legacy application onto cloud infrastructure in a few weeks and leave it running at a higher monthly cost than the server it came from. The projects that keep their savings are often the ones that moved latest, and only after each workload had been valued on its own terms. Both facts can be true of the same application portfolio at the same time, which is why an evaluation of legacy system migration to cloud comes before the choice of approach rather than after it.
The evaluation is not a report, and it is not a business case. It is a decision taken once per workload by the team responsible for it, before anything moves, and revisited when the first cloud invoice arrives. Everything below rests on that premise, so the labels for each approach are worth reading after this paragraph rather than before it.
Four lines every workload needs before it moves
An evaluation that ends in a slide deck has given the delivery team nothing it can be held to. The output is an entry for each workload, and the entry needs four lines before that workload joins a migration phase.
- The team responsible for the workload in business terms, and the team responsible in technical terms, attached to the workload itself rather than to a project plan, because project plans get closed and running systems do not.
- The approach chosen, together with a plain account of the cloud value that approach gives up, so the trade is visible before delivery rather than after it.
- The cutover requirements and a tested rollback, including the maximum number of hours the workload may run in two environments at once.
- A run-cost baseline taken before the move, and a deadline by which that baseline will be weighed against the bill that arrives afterwards.
Those four lines are the evaluation in miniature. The sections below lay out what has to be understood before each line can be put down honestly.
Legacy is a support status before it is an age
Age is the least useful thing to argue about. The Synextra guide to migrating legacy applications says that the clearest indicator of legacy status is vendor support status: once the vendor ceases shipping updates, security patches or technical support, the organisation is on its own when the system breaks down. An application built fifteen years ago and still under maintenance can stand outside that definition. An application built three years ago on a framework no one maintains can fall within it.
Synextra identifies the other markers that belong in the same first pass: deprecated frameworks and design habits, a knowledge base that left with the original builders, dependencies on hardware that is no longer manufactured, and integration that survives only through manual data transfers. Any one of those is enough to put a workload in front of an evaluation. None of them appears on a licence renewal notice, which is why the first pass is an interview and a code read rather than a spreadsheet export.
The order matters. A supported system with a current architecture can be replatformed alongside others with modest effort. An unsupported system with an undocumented codebase has to be treated as a risk to be contained, whichever approach is eventually chosen for it. The evaluation settles which of those two situations it is looking at before it prices anything.
Why discovery output is not a workload map
Discovery tooling reports what talks to what across the network on the days it runs. It does not report the monthly rate load that reaches a file share by UNC path, the scheduled task that calls a service no one documented, or the outbound SFTP drop that a broker expects at six in the morning. NIX United labels these zombie dependencies and reports them as a frequent cause of failure after a migration has already been approved: links back to on-premises systems that were never reachable from the new environment.
The map is therefore an artefact drawn once with a team's name against it, not a diagram made by a console. One workload in the map looks like this.
workload: claims-settlement
business_lead: Head of Claims Operations
technical_lead: Platform Lead, Core Insurance
vendor_support: ended 2021-09
runtime: Windows Server 2008 R2
dependencies:
- mssql-01.internal # connected by label, not by service discovery
- \\fs01\shared\rates # monthly rate load, unreferenced in documentation
- sftp://broker-gw/outbound # 06:00 batch, the broker expects the file
data_class: personal data, special category
rto_minutes: 240
approach: replatform
value_given_up: scheduled batch design left unchanged
cutover_max_hours: 6
rollback_tested: 2026-02-11
run_cost_baseline_gbp_per_month: 4180
review_deadline: 2026-08-31
The comment lines are the point of the exercise. Each one puts down something the tooling did not find on its own, and each one can be argued with, corrected and handed to a supplier. A dependency graph cannot. The Intercept guide to application migration makes the same case from the other direction: run a pilot on a non-critical application first, keep both systems running in parallel until the migrated version behaves as expected, and take a full backup before anything is switched over.
Each migration approach and the value it gives up
Five approaches come up in almost every evaluation. The labels matter less than the trade each one makes, and the trade has to be put down in the entry.
Rehost moves the application onto cloud infrastructure with no code change. The awsquality migration guide puts rehost at two to four weeks per application, which is why it is the approach that empties a data centre fastest. It preserves current behaviour exactly, and it brings forward every defect, every unsupported component and every licensing term that governed the original system. Its savings come from hardware the organisation ceases buying, not from software it keeps running.
Replatform moves the application and changes one or two components, usually the database or the runtime, to a managed cloud service. Synextra places this between rehosting and refactoring: the application keeps its shape while patching, backup and scaling move to the provider. What the choice gives up is the chance to correct the parts of the design that made the system expensive to change.
Refactor rewrites parts of the application against cloud-native services. This is the approach that delivers elasticity and shorter release cycles, and it is also the one with the longest tail and the heaviest demand on skills. It belongs where the application has a long commercial life and where the current release cycle is measurably limiting the business.
Repurchase retires the application and replaces it with a software-as-a-service product. Synextra explains replacing as the recognition that the capability should not have been built in house at all. What the choice gives up is fit: the product imposes its own process, and the cost of that process change belongs in the evaluation rather than in a change budget raised later.
Retain leaves the workload where it is, with a review deadline attached. This is a legitimate entry rather than a gap, and the last section below gives the cases where it is the right one.
Failure rates that should shape the thresholds
A contingency with no figure behind it is an apology waiting to be put down. The awsquality cloud migration guide reports that 38 in every 100 migrations exceed their original budget and 31 in every 100 miss their planned timeline, attributing both almost entirely to planning rather than to platform. On the saving side, the same guide puts the average IT cost reduction after migration at 20 to 30 in every 100 in the first year.
Published experience on total cost of ownership runs in a similar band. NIX United reports that clients moving to a consumption model saved an average of 20 to 30 in every 100 on total cost of ownership across three years. That band is wide enough to be honest and narrow enough to be tested. A business case promising more than the top of it is promising something the published record does not support, and the entry for each workload should carry that caution rather than a rounder number invented for a steering group.
When leaving a workload where it is beats moving it
Synextra gives the cases directly. An application approaching end of life is a poor candidate, because the cost and disruption of a move will not pay back before the system is shut down. Licensing terms that forbid cloud hosting, or that require a costly upgrade to permit it, can make a move impractical. Highly customised applications bound to specific hardware or on-premises infrastructure can cost more to move than they are worth.
The evaluation should treat a retain decision with the same rigour as any other line. Set a review deadline, put the reasons beside it, and keep the workload in the portfolio view rather than dropping it out of sight.
What the evaluation hands to the pages beneath it
This page has set out the shape of the decision and the evidence each line of the entry needs. It has not priced a migration, chosen a platform, or written a cutover runbook. Those belong to the work that follows, and each of them depends on the four lines above being honest first.
