Legacy Application Migration: How to Move Legacy Apps to the Cloud

Most guides to legacy application migration stop at naming strategies. They tell you to assess, pick an approach from a framework, then migrate. That advice is not wrong, but it skips the three things that actually decide whether the project lands: how you find the dependencies nobody wrote down, how you design a cutover you can reverse, and what the work costs.

This guide covers those three. It assumes you already know your aging system is a problem and want to know what the work involves before you commit budget to it.

Key Takeaways

• The hardest part is not choosing a strategy. It is discovering what the application talks to, because undocumented integration points set the schedule.
• The easiest workload makes the worst pilot. Pick one that carries your real integration risk, or the pilot teaches you nothing.
• A cutover without written go/no-go thresholds and a named decision owner is not a plan. It is a hope.
• Some applications should not move. Deciding that early is cheaper than discovering it during a failed migration.
• Cloud adoption is not the differentiator it once was. 74% of IT decision-makers say their organization has accelerated its cloud migration over the past 12 months (Foundry, 2026 Cloud Computing Study).

When an Application Is Worth Migrating, and When It Is Not

An application earns a move when its constraints are costing you more than the migration will, and when the cloud actually relieves those constraints. Both conditions matter. Hardware you cannot buy replacements for, scaling limitations during predictable peaks, and compliance requirements the current stack cannot meet are all good reasons to move a workload, because in each case the constraint is the infrastructure itself and renting better infrastructure removes it. Low user counts and stable, unchanging workloads usually are not.

The distinction worth drawing early is between moving an application and changing it. Relocating a workload to rented infrastructure gets you elasticity, managed backups, and disaster recovery you do not have to build. It does not fix a design that assumes a single server, and it will not reduce your technical debt by itself. Those are separate projects with separate budgets, and conflating them is how migrations acquire scope they cannot finish.

Run each application against the signals below before it enters a migration plan at all.

Two of those outcomes involve no migration. That is the point. Every application you retire or retain is one you do not pay to move, test, and operate twice.

What Legacy Application Migration Actually Involves

Legacy application migration is the process of moving an application built for older infrastructure onto modern infrastructure, usually a public cloud, along with its data, integrations, and operational tooling. The scope covers the application itself, everything it connects to, and the runbooks that keep it alive. A legacy system migration is the same exercise across a group of applications that share dependencies.

One distinction saves a lot of confusion, and it is not academic, because the two are measured against completely different acceptance criteria and staffed by different people. Legacy data migration moves records between stores and is measured in completeness and accuracy. Application migration moves running behavior, and is measured in whether the same inputs still produce the same outputs under real load. Most application migrations contain a data migration, but the reverse is not true.

In practice the work breaks into six pieces:

1. Inventory of applications, with dependencies and owners recorded
2. Discovery of integration points, including the undocumented ones
3. Target platform and service model selection
4. An approach chosen per application, not per portfolio
5. A pilot, then waves, then cutover with a tested rollback
6. Operations, cost governance, and decommissioning of the old estate

Mapping Dependencies When the System Is Undocumented

Application dependency mapping is the highest-risk activity in the project, and it is the one most plans underestimate. The goal is a written record of every system the application reads from, writes to, authenticates against, or is called by. On a system with current documentation this takes days. On a twenty-year-old system whose authors have left, it is the work.

Tool-assisted discovery gets you part of the way: automated code dependency and architectural analysis will find compile-time references, and platform inventory services will find the network neighbors an application talks to on a normal weekday. Neither finds a report someone runs once a quarter from a spreadsheet macro against a replica. That gap is where migrations fail.

Six methods that find what the tools miss:

1. Capture traffic at the boundary for a full business cycle, not a week. Month-end, quarter-end, and annual jobs are invisible in a seven-day sample, and they are usually the ones that break.
2. Read the database access logs, then reconcile the accounts that appear against the accounts you can explain. Every unexplained service account is an integration you did not know about.
3. Inventory scheduled jobs on every host that can reach the database, including workstations. Batch work migrates badly because nobody owns it.
4. Sweep the codebase for hard-coded endpoints and credentials. Literal IP addresses, file shares, and connection strings mark couplings that no dependency graph shows.
5. Interview the operators, not the architects. The people who run month-end know which manual steps hold the process together. That knowledge is rarely written down anywhere.
6. Break things deliberately in an isolated copy. Disable an interface and see what complains. This is the only reliable way to find consumers you cannot see from inside the application.

“The code is never the problem. What sets the schedule is the integration nobody documented, a nightly job writing to a table you did not know existed. We budget discovery separately now, because guessing at it is what breaks cutover dates.” – Quy Truong, Software Architect at Saigon Technology

Treat the output as a deliverable with a named owner, not a diagram that ages in a wiki. Every dependency you find becomes a test case at cutover.

Choosing a Target Platform and Service Model

The service model matters more than the vendor. Pick that first. Infrastructure services give you the most control and the least benefit, because you still patch, size, and monitor everything yourself, which means you have moved the hardware problem to someone else’s data center without shedding any of the operational work that came with it. Platform services take that operational load away but constrain what your application may assume about its runtime. Software services remove the application entirely and turn the project into data migration and process change.

Legacy characteristics push you toward one of them fairly predictably. An application with kernel-level dependencies, unusual licensing, or a runtime the platform providers do not support belongs on infrastructure services, at least initially. A conventional web application with a supported language version is a platform services candidate and will cost less to run. If a commercial product covers the same function and your customization is thin, buying it beats moving it.

Deployment choice usually follows one hard requirement rather than a preference. Data residency, an on-site system that cannot tolerate added latency, or a procurement rule about concentration risk will each decide it for you. Where none applies, a single public cloud is simpler and cheaper to run, and the portability a multi-cloud design buys is often portability you never use. Selecting and sizing the target is where a cloud migration services partner earns its fee, because the decision is hard to reverse once data has landed.

Matching Each Application to a Migration Approach

Once you know what an application depends on and where it is going, you choose how much to change it in transit. The options run from lifting it unchanged through to rebuilding it, and the naming convention most teams use traces to a specific source: Stephen Orban published “6 Strategies for Migrating Applications to the Cloud” at AWS on 1 November 2016, building on five strategies Gartner had outlined in 2011 (AWS).

The choice is per application, never per portfolio. A single estate will normally use three or four approaches at once, because the constraint that decides it is the individual application’s coupling and business value, not a program-level preference.

We have covered the selection logic in depth elsewhere. For the trade-offs, costs, and failure modes of each option, see the seven modernization approaches, compared.

Designing a Pilot That Tells You Something

A pilot exists to be wrong cheaply. That only works if the workload you pick carries the risk you are worried about, which is why choosing the easiest application is the most common mistake in migration planning. A simple, low-integration service will migrate cleanly and teach you nothing about the estate you actually have to move, and it will do so while generating a green status report that makes the next wave look safer than it is. Optimism is not evidence.

Pick a representative workload instead: moderate complexity, real users, at least two live integrations, and a data volume large enough that transfer time is measurable. Then fix the success criteria before you start, in writing.

1. Define acceptable response times under production-equivalent load, not idle load.
2. Set a maximum acceptable downtime for the switchover and treat it as a limit.
3. Decide what data reconciliation has to show before you call the migration complete.
4. Name the integrations that must pass a test migration, and who signs off on each.
5. Agree what monitoring must be live on day one, before the workload carries traffic.
6. Write down the cost you expect to run it, so you can compare against the bill.

What you learn should change the plan, and each outcome licenses a different next step.

Cloud migration testing during a pilot is worth more than the same testing later, because at pilot scale you can still change the approach without renegotiating a program.

Cutover, Parallel Run, and Rollback

A cutover plan is a written sequence with thresholds, owners, and a reversal path. Most migration guides mention rollback in a single line and never say what triggers it. That omission is why cutovers overrun: when something looks wrong at two in the morning, nobody has authority to stop, so the team pushes forward into a state it cannot undo.

Write these down before the window opens:

1. Go/no-go criteria with numbers, evaluated at a fixed checkpoint before you switch traffic. Not “data looks correct” but a reconciliation count and an acceptable variance.
2. A parallel run period where both systems process the same inputs and you compare outputs daily. Long enough to include one full business cycle, so month-end runs at least once.
3. A reconciliation method that names which fields must match exactly and which may drift, agreed with the business owner rather than assumed by the delivery team.
4. Fallback triggers stated as conditions, so nobody has to interpret them under pressure. Data variance beyond the agreed threshold, an integration failing, or the window overrunning by a set margin.
5. A named decision owner with the authority to call the rollback, available for the whole window and not also running the migration.
6. A rollback that has been executed at least once in a rehearsal, against production-like data, with the same people who will be on the call during the real window. An untested rollback plan is documentation, not a capability.

Written as a checkpoint table, the criteria stop being a judgment call at three in the morning.

Keep the old environment able to resume until the parallel run is clean. Moving legacy applications to cloud infrastructure stays reversible until you decommission the source, and that should be a deliberate decision rather than one that arrives by neglect. For most estates a phased rollout beats a single cutover: group applications into waves by shared dependency rather than by business unit, migrate a wave, then let what you learned adjust the next.

What a Legacy Application Migration Costs

Cost is driven by discovery and coupling far more than by application size. A small application with six undocumented integrations costs more to move safely than a large one with two clean interfaces, because effort follows the number of things that must be found, tested, and reconciled.

Our published rate for senior-led implementation work is $22 to $46 per hour, which is the input most cost models are missing when they estimate migrations. Use it against hours, not against a total. Any firm quoting a fixed project figure before discovery has finished is quoting a guess, because the dependency count that drives most of the effort is precisely what discovery exists to establish.

The number that matters is cost per outcome rather than cost per hour. A migration that finishes on schedule with a tested rollback and no data loss is cheaper at a higher rate than one that overruns, because the expensive failures here are rework, extended parallel runs, and unplanned downtime rather than the rate itself. Where the work extends past relocation into restructuring the application, it becomes a legacy application modernization engagement with a different shape and a different budget.

Budget for cloud consumption separately, and expect the first months to run high while sizing settles.

Operating the Application After Cutover

Migration ends at handover, and handover is where the savings are usually lost. Name the team that owns the application in its new environment before cutover, with a documented escalation path and a named individual rather than a distribution list, because shared ownership of an unfamiliar system reliably resolves to nobody. An application nobody owns accumulates cost and risk quietly for months. Sometimes years.

Three things need to be in place from day one. Monitoring and alerting on the metrics you set during the pilot, so degradation is visible rather than reported by users. Cost governance with an owner and a review cadence, because cloud spend grows through accumulated small decisions and nobody notices without a monthly look. And a decommissioning schedule with dates for the source environment.

That last one deserves emphasis, because “we will turn it off later” reliably becomes never. Every month the old estate stays powered on, you pay twice and keep an unpatched system on the network. Set the shutdown date during planning and make it conditional on the parallel run being clean rather than on someone finding time. Then hold it.

Automation is what keeps the new environment from becoming the next legacy system, because infrastructure defined as code, deployments through a pipeline, and patching on a schedule are the difference between an application you can still change in three years and one your successors inherit as a mystery. Build that practice during the migration, not after. Teams without it already in place will find the curve shorter with help, which is what DevOps services are for.

Frequently Asked Questions

1. Can every legacy application be migrated to the cloud?

No, and treating universal migration as the goal creates avoidable work. Applications with hard dependencies on specialized on-site hardware, licensing that forbids virtualization, or latency requirements tied to physical equipment may be cheaper to retain. Applications with near-zero usage should be retired, with their data preserved. Decide per application against a written rule.

2. How do you migrate an application when nobody who built it still works here?

You reconstruct the dependency map from observed behavior rather than from documentation. Capture traffic at the boundary across a full business cycle, audit database access logs for unexplained accounts, inventory scheduled jobs on every host that can reach the data, and disable interfaces in an isolated copy to see what breaks. Interview the operators who run the process, because their manual steps rarely appear in any diagram.

3. What is the difference between legacy application migration and legacy data migration?

Data migration moves records between stores and is judged on completeness and accuracy. Legacy application migration moves running behavior and is judged on whether the same inputs still produce the same outputs under real load. Most application migrations include a data migration as one workstream. A data modernization project can also stand alone, with no application move at all.

4. Do you have to move the database at the same time as the application?

Usually yes, if the application is sensitive to latency between the two. Splitting them across a network boundary adds round-trip time to every query, and applications written for a local database often assume that cost is negligible. Where you must split them temporarily, measure the added latency against your performance criteria before committing to the sequence.

5. How do you know the migration actually succeeded?

Against criteria written before you started: response times under production-equivalent load, a data reconciliation within an agreed variance, every named integration passing its test, and running cost within the range you modelled during the pilot. Absence of complaints is not evidence. Users route around problems silently for weeks before anyone reports them.

6. What happens to the on-premises environment after cutover?

It stays available until the parallel run is clean, then it is decommissioned on a scheduled date. Keeping it running indefinitely means paying for two environments and maintaining an unpatched system with network access. Set the shutdown date during planning and make it conditional on reconciliation results rather than on team availability.