Deciding which legacy applications move to the cloud comes first, ahead of any design work, any build and any vendor conversation, and a programme that postpones the choice migrates whatever is loudest in the estate while everything else arrives at cutover unplanned.
A distributor learned this the hard way. Its sales processing system was the most important application it ran, so it went first. The cutover itself was clean. On the Monday, the warehouse application had nothing to read, because it depended on a nightly extract from the sales system's database, written years earlier by a contractor and documented nowhere. The migration was technically a success; six weeks of manual reconciliation made it a commercial failure.
Nothing in that story is unusual. The error was in the timing. The eligibility of an application, and its place in the queue, cost almost nothing to decide early and a great deal to decide late. In software that run into trouble, the engineering is rarely the weak point. Choosing cloud migration legacy applications is an ordering exercise first, and this page sets out how to work it.
Which applications belong in the migration queue
This is a portfolio decision before it is a technical one. An application that does not pass any question below becomes a different piece of work with a different lead.
- Does it still need to run at all? If the answer is no, decommissioning costs less than moving.
- Is it permitted to run there? Licence terms and vendor support are gates that decide eligibility.
- Can you prove what it does? Undocumented behaviour is the usual reason a migrated application crashes quietly after go-live.
- Who will still understand it in a few years? Expertise known by one worker is a scheduling constraint, and it sets your dates.
The figures make the case for asking these questions early. Legacy and custom application migrations carry the lowest success rate of any workload category at 61%, and 47% of migration delays are caused by legacy dependencies that the assessment never identified, according to the statistics compiled by Medha Cloud. Both numbers describe the same failure: An application entered the queue before a user had proved what it touched.
These six steps are the way to go
Follow the steps one by one. Each ends with an outcome you can check before the next one starts, and none of them is worth beginning until the check above it has passed.
Deciding the test before reading the estate
Write, on one page, the dimensions every application will be judged against, who must provide the answer to each, and the rule that nothing joins the queue until every dimension has a documented answer. Write it before you look at the estate, so the rule is not quietly shaped around the applications you would rather move. Equal Experts uses an inception phase at the start of an engagement to build shared understanding of the business, technical and user context ahead of delivery, and the same discipline applied internally produces a rule that survives contact with an awkward application. Whether the assessment is then run in-house or with a partner is a separate question, and one worth asking only after the rule exists.
Check: give the rule and one application to two assessors working separately. If the two reach different verdicts, the rule is not yet a rule.
Mapping what the application touches
Step two is to capture the application's connections across a full business cycle, including month end and year end. Read the traffic first, and then follow the runbook. List scheduled tasks, file shares, batch jobs, database links and outbound calls, and assign a manager to each. The guide published by Synextra is direct on this point: undocumented connections to scheduled tasks and file shares are found by examining traffic, since documentation and institutional memory both go stale. NIX United calls the components that remain after poor migration zombie dependencies. Those are hidden links to on-premises tools that are no longer reachable, and they can bring a migrated system down after go-live.
Check: Each entry in the log has a specified user and a test that proves the connection still works.
Settling licences and vendor support
Step three settles the two questions that can end the case outright, and both are cheaper to test now than to discover during a build. Synextra says that some older agreements do not permit the software to run in a cloud environment at all, or require an upgrade whose cost exceeds the value of the application. Vendor support runs the same way. Software the vendor no longer patches can still be migrated, but it has to be wrapped in compensating controls, and the security manager makes that decision. The migration team has no standing to make it.
Check: A dated written statement from the vendor or the procurement manager is attached to the application file before any design work is funded.
Choosing a route for each application
Step four gives every application one route and one written reason. Choose the route for each application separately. Six routes cover almost everything a typical estate contains, and they differ in what they change, what they leave with you, and the condition that makes each of them the sensible answer.
| Route | What changes in the application | What stays yours afterwards | The condition that makes it the right route |
|---|---|---|---|
| Rehost | Nothing in the code; the operating system, database and middleware travel with it | The same patching, tuning and licence obligations, now on rented hardware | A data centre exit or a hardware end-of-life date sets the timetable, and the application has a short life left |
| Replatform | Targeted substitutions, such as a managed database or a supported operating system | The business logic, unchanged | The application has years left in it, and integration is the pain rather than the architecture |
| Refactor | The structure, split into parts with defined interfaces | Considerably less, because each part can be changed on its own | The application is core and long-lived, and the business changes it on a schedule of its own |
| Rebuild | The code, while the behaviour is kept | Whatever you choose to own | The existing code is unsalvageable, or the people who understood it have gone |
| Replace | Nothing, because the application stops | The data, the contracts and the move to the supplier | The capability is not one you should hold in-house |
| Expose through an interface | Nothing in the legacy system; an interface is placed in front of it | Keeping that interface current | The system cannot safely be changed, or the business case for moving it does not yet close |
Intercept sets out the same family of moves and says that the right one depends on resources, size, complexity and the nature of the application. Dotsquares draws the portfolio conclusion from it: a well-run programme looks at each application on its own terms, and it resists pushing one strategy across the estate. OpenLegacy adds the route software most often forgets, in which the data and functions a legacy system contains are exposed to modern services without moving the system itself, either as an alternative to migration or as a way to migrate on a timetable of your own choosing.
Check: No application has migrate as its route, and no single route has been applied to the entire estate without a written reason.
Ordering the queue by reversibility
Step five orders the queue by how easily you could go back. Put the applications you could return from at the front. NIX United warns against the big bang approach and suggests piloting on non-critical workloads to test the tooling and to give the staff who must live with the result a reason to trust it. Intercept adds that running the old and the new systems in parallel until the new one behaves as expected repays the extra cost. Reversibility is also the honest test of how much you know. A team that cannot describe how it would go back does not yet understand what it is moving.
Check: for every application in the first wave, one sentence describing how you would go back, and the day on which that option expires.
Agreeing stop conditions and the exit
Step six fixes, before the work is authorised, the conditions under which the migration ends. Write down what would make you halt, who is entitled to call the halt, and what state the application is left in when the halt is called. Three conditions earn a place in every case: the licence status changes, the dependency log turns out to be incomplete, and the application's behaviour in the cloud diverges from its behaviour on the old platform in a way users can see. None of these is a reason for blame. Each is a reason for a decision that somebody has already been given the authority to take.
Check: The halt conditions sit in the authorisation file with labels and dates, and the exit has been rehearsed once in a test environment.
Running the assessment over an estate of any size
A large estate rarely justifies a full assessment of every application before the first move. Two approaches keep the work proportionate. The first is sampling by type: assess fully the applications that share a platform, a vendor or an architecture, and let the first result stand for its group until an application in that group behaves differently. Another way to group applications is by dependency. Applications that exchange data nightly are part of the same decision, and assessing them apart produces a queue that cannot be worked in the way it is written.
Both approaches carry the same obligation. Things not assessed are marked as not assessed in the log, with the name of the user who accepted the risk of omitting them. An estate where the gaps are known is workable. An estate where the gaps look like answers is not.
The record each application carries
The procedure produces one artefact per application, and the migration is authorised against it. The file contains the four eligibility answers, the dependency map with its controllers, the dated licence and support status, the route with its written reason, the reversibility sentence and its expiry, and the stop conditions. Two things keep the record useful rather than decorative. Each entry shows a user. Every entry carries a date.
Berks Technologies explains the same discipline from the delivery side, listing static code analysis, dependency mapping and reverse engineering as the work that discovers migration problems before a plan is written. The arrangement is important. Analysis that runs after a route has been chosen tends to confirm the route.
What to do when an application does not pass the test
An application that does not meet an eligibility question exits the queue, and the work it needs is not migration work. Procurement manages a licence question that was not answered. A failed knowledge question is the responsibility of the team in charge of the application, and it usually resolves into documentation, a re-platform onto a supported runtime, or a deliberate decision to run the system unchanged under compensating controls. The blame for a decommissioning that goes wrong rests with the staff member who requested the migration.
The temptation is to carry the failing application into the programme anyway, on the grounds that it will be easier to fix once the move is under way. Estates acquire the two systems no one selected in that way. The queue is the place where the choice is made, and the queue is short.
The way you arrange the steps is more important than the tools used.
Tooling decides how fast a chosen migration runs. It has no view on which applications should be in the queue. The distributor at the start of this page had adequate tooling and a clean cutover. What it lacked was an ordered list produced before the first application was selected. Sequencing is the part of the work that costs least to get right at the beginning and cannot be bought back later.
Sources
- Legacy Application Migration to Cloud in 2026 – NIX United
- Migrating Legacy Applications To The Cloud: When To Do It (And When Not To) – Synextra
- Migrating Legacy Applications to the Cloud: 7 steps – Intercept
- Legacy Systems to Cloud Modernisation Guide 2026 – Dotsquares
- Why and How to Migrate a Legacy Application – OpenLegacy
- Rebuild Legacy Software Migration UK – Berks Technologies
- 50 Cloud Migration Statistics for 2026 – Medha Cloud
