A practical guide to moving legacy applications to the cloud — what each migration path costs, how long it takes, and how to choose between them.
Disclosure. legacymodernizationhub.com is operated by Chudovo OÜ. Cost and timeline figures in this guide are the ranges Chudovo publishes from its own delivered projects. They are offered as one vendor’s reference points, not as industry averages. Where the guide cites frameworks, those come from AWS, Microsoft and the practitioners named inline.
The decision is not whether to migrate, but which path to take
Most legacy applications can be moved to the cloud in more than one way, and the paths differ by an order of magnitude in cost, duration and risk. A mid-sized system can be rehosted in six weeks or rearchitected over nine months, and both can be the correct answer depending on why you are moving.
This guide covers the six paths, what each one realistically costs, and the criteria that decide between them.
Understanding what you are moving
Legacy systems were typically built for dedicated physical servers in a company’s own data center. Three characteristics make them hard to move:
Tight coupling to the host. The application assumes a specific OS version, a local file path, a hardware dongle, a scheduled task on that machine. These assumptions are usually undocumented and surface only during the first migration attempt.
Stateful design. Sessions in memory, files written to local disk, locks held in a single process. Cloud platforms assume instances are disposable, and stateful applications break when they are.
Manual operations. Deployment is a runbook, not a pipeline. Monitoring is a person checking a log. Moving the application without moving the operating model reproduces the same constraints at higher cost.
An assessment that catalogues these three things is the cheapest part of the project and the one most often skipped.
The six migration paths
The widely used taxonomy comes from AWS, which documents it as the “7 Rs” in its prescriptive guidance on migration strategies. Microsoft covers equivalent ground in the Cloud Adoption Framework for Azure. The six that matter for legacy work:
Rehost (lift and shift)
Move the application as it is onto cloud VMs. No code changes.
- When it fits: a data center lease is expiring, hardware is failing, or you need to exit on-premise before a deadline
- What it does not do: nothing about scalability, cost efficiency or deployment speed. You are renting someone else’s servers
- Typical duration: 4–8 weeks for a small system
- Typical cost: around $30,000 for a mid-sized application
Rehosting is often criticised as a non-decision. It is a reasonable one when the deadline is real and the modernization budget is not yet approved — provided it is understood as a first step, not the destination.
Replatform
Move with targeted changes that use managed services: swap a self-hosted database for a managed one, move file storage to object storage, containerize the application without redesigning it.
- When it fits: the architecture is sound but the operational burden is high
- Typical duration: 2–4 months for a mid-sized system
- Replatforming captures a large share of the operational benefit for a fraction of the rearchitecting cost. For most legacy business applications it is the default answer.
Refactor
Change the code for maintainability and scalability — modularize components, introduce APIs, fix the queries that will not survive a shared environment — without redesigning the architecture.
- When it fits: the application will stay in service for years and the team still works in it daily
- Typical duration: 3–6 months for a mid-sized system
Rearchitect
Redesign for cloud-native patterns, usually microservices or serverless.
- When it fits: independent scaling of components is a genuine requirement, or multiple teams need to deploy independently
- Typical duration: 3–9 months for a monolith-to-microservices rebuild; a full decomposition of a large monolith runs 12–24 months
- Typical cost: around $100,000 for a mid-sized rebuild
The standard approach is incremental rather than big-bang. Martin Fowler’s Strangler Fig pattern describes routing traffic gradually from the old system to new services until the original can be retired — AWS documents the same approach in its guidance on decomposing monoliths.
Replace
Retire the application and adopt a SaaS product.
- When it fits: the system implements a commodity process — payroll, CRM, ticketing — with no real differentiation
- The hidden cost: data migration and process change, which routinely exceed the licence cost
Retain
Leave it where it is. A system with two years of remaining life and no scaling pressure does not justify a migration budget. Retaining deliberately, with a documented review date, is a decision; retaining by default is not.
Choosing between the paths
| Driver | Likely path |
|---|---|
| Data center exit with a fixed deadline | Rehost |
| Operational cost and maintenance burden | Replatform |
| Development velocity has collapsed | Refactor |
| Components need independent scaling or release cycles | Rearchitect |
| Process is commodity, no differentiation | Replace |
| Short remaining lifespan | Retain |
Two tests settle most arguments:
Does the business logic in this system differentiate you from competitors? If not, replace it. If yes, it is worth investing in.
Would independent deployment of components solve a problem you actually have today? If not, microservices will add distributed-systems complexity in exchange for benefits you will not use.
What the whole project costs
Published ranges from Chudovo, which delivers legacy to cloud migration projects on the .NET and Java stacks:
| Scope | Duration | Cost |
|---|---|---|
| Small system | 4–8 weeks | from $15,000 |
| Mid-sized application | 3–6 months | $50,000–$200,000 |
| Large enterprise system | 6–18+ months | $200,000+ |
| Mid-sized lift and shift | — | ~$30,000 |
| Monolith to microservices rebuild | 3–9 months | ~$100,000 |
Database migration is costed separately and often underestimated:
| Database scope | Duration | Cost |
|---|---|---|
| Small | 1–3 weeks | $5,000–$20,000 |
| Mid-sized | 1–3 months | $20,000–$80,000 |
| Large | 3–6+ months | $80,000+ |
Few vendors publish figures at all, so treat these as one reference point rather than a market rate. What they are useful for is sanity-checking a quote: a proposal that prices a mid-sized rearchitecture at $25,000 is describing a different scope than the one you asked for.
The planning sequence
1. Discovery. Inventory applications, infrastructure and dependencies. The output is a dependency map, and the surprises in it determine the schedule.
2. Assessment per application. Business criticality, technical complexity, remaining lifespan. Each application gets one of the six paths, not a blanket strategy for the portfolio.
3. Target architecture. VMs, containers, serverless, managed databases — decided per application against the chosen path.
4. Phased execution. Start with a system that matters enough to be realistic and not enough to be catastrophic. The first migration is where you discover what your assessment missed.
5. Optimization. Cloud costs rise after migration unless someone owns them. Right-sizing, reserved capacity and storage tiering typically recover a meaningful share of the initial bill.
Where migrations actually go wrong
The assessment was a formality. Undocumented dependencies are found during cutover rather than before it. This is the single most common cause of overrun.
Data was treated as a subtask. Volume, consistency, and the cutover window are a project in their own right. The table above shows why.
Lift and shift was sold as modernization. The system runs in the cloud and nothing improved, because nothing was supposed to. The problem is the expectation, not the strategy.
The operating model stayed behind. Manual deployments and manual monitoring in a cloud environment produce the old constraints plus a new bill.
Microservices were chosen for the architecture diagram. Decomposition without a concrete need for independent scaling or deployment buys distributed-systems problems and no corresponding benefit. Fowler’s own writing on the pattern is notably cautious on this point.
Security and compliance
Three items that change the plan rather than being added at the end:
- Data residency. Regulated workloads in the EU need region selection decided before the architecture, not after
- Identity. Legacy applications often rely on domain authentication that does not translate. Plan the identity path as its own workstream
- Encryption and key management. In transit and at rest, with key ownership decided explicitly — this is a frequent audit finding
FAQ
How long does a legacy cloud migration take? 4–8 weeks for a small system, 3–6 months for a mid-sized application, 6–18 months or more for a large enterprise system. A monolith-to-microservices rebuild falls in the 3–9 month range, and full decomposition of a large monolith can take 12–24 months.
What does it cost? Published ranges start around $15,000 for small systems, $50,000–$200,000 for mid-sized applications, and $200,000+ for enterprise scope. A mid-sized lift and shift is around $30,000; a mid-sized rearchitecture around $100,000.
Is lift and shift ever the right answer? Yes — when a deadline is driving the move and modernization budget is not yet available. It is the wrong answer when it is presented as modernization.
Can migration happen without downtime? For most applications, yes, using parallel running and phased traffic cutover. The constraint is usually the database, not the application tier.
Do we have to move everything? No. Retain is one of the six paths and the correct one for systems with short remaining lifespans.
Sources and further reading
Cost and timeline figures: Chudovo — legacy to cloud migration
AWS Prescriptive Guidance — Migration strategies (the 7 Rs)
AWS Prescriptive Guidance — Strangler fig pattern for decomposing monoliths
Martin Fowler — Strangler Fig Application