Cloud migration is the process of moving an application, its data, and its infrastructure from on-premises servers to a cloud provider’s environment.
In legacy modernization it usually comes up first, because it promises quick gains in hosting costs and availability.
Its limits often show up a few months later, when changes still take as long to ship as before, now on infrastructure billed by the hour.
Where does cloud migration fit in a modernization roadmap?
Well-planned software modernization services (https://www.merixstudio.com/services/software-modernization) treat the move to the cloud as one track of a broader roadmap, next to refactoring, test automation, and UX work.
This article is most useful for CTOs and IT managers deciding whether lift and shift is the right first step for their legacy system.
In a nutshell:
- Lift and shift changes where an application runs. Its code and its technical debt move along with it.
- It is a good first step when the system is stable and the pressure comes from hardware, data center contracts, or availability.
- When the bottleneck sits in the code, migration has to be paired with refactoring. Otherwise cloud costs can grow without visible benefits.
What does lift and shift change, and what stays the same?
Lift and shift, also called rehosting, moves an application to cloud infrastructure with minimal changes to its code. Servers, storage, and backups move to the provider, and adding capacity becomes a configuration task instead of a hardware purchase.
Everything above the infrastructure layer stays where it was. A release that needed a week of manual regression testing still needs it, and users see the same interface. For this reason, lift and shift should be judged as an infrastructure decision. Its effect on development speed is indirect.
When is lift and shift a good first step?
Lift and shift makes sense when the system works reasonably well and the pressure comes from what runs underneath it. Typical situations include:
- hardware or a data center contract approaching end of life;
- availability and disaster recovery below what the business now expects;
- an architecture the team can’t change yet because of budget or deadlines; and
- plans for deeper modernization that will need managed services and modern continuous integration and delivery (CI/CD) pipelines.
Speed is the main advantage. A lift and shift migration can take as little as two to three months, while refactoring a mid-complexity system typically takes four to eight.
When does moving to the cloud only relocate the problem?
Migration falls short when the reasons for modernizing sit in the code. Common signals include simple changes that take weeks to ship, thin test coverage that turns every release into a manual exercise, and a monolith that can only scale by renting a bigger machine.
Costs are the less obvious risk. An application designed for fixed on-premises servers usually runs at a constant size, and in the cloud idle capacity is still billed.
According to Flexera’s 2026 State of the Cloud Report, organizations estimate that 29% of their spend on infrastructure and platform services, known as IaaS and PaaS, is wasted, which reverses a five-year downward trend.
Lift and shift vs. refactoring for the cloud: how do you decide?
The decision depends on where the bottleneck sits. The comparison below summarizes the trade-offs.
| Lift and shift | Refactoring for the cloud | |
|---|---|---|
| Typical timeline | From 2–3 months | 4–8 months for a mid-complexity system |
| What it improves | Hosting costs, availability, hardware risk | Performance, scalability, release speed |
| What stays unsolved | Technical debt, slow releases, UX issues | Flaws in the core design |
| Best fit | Stable system under infrastructure pressure | System that needs features or scale it can’t deliver today |
The two approaches often run in sequence. Moving first and refactoring later works when the second phase is planned and funded together with the first, so it doesn’t slip to the next budget cycle.
Refactoring for the cloud also doesn’t automatically mean breaking the system into microservices. As Miłosz Kusiciel puts it:
“A mistake organizations often make is assuming microservices are always the next step.” – Miłosz Kusiciel, Head of Technology at Merixstudio
In his view, microservices pay off mainly for large engineering teams, while smaller teams working on complex products are often better served by a well-structured monolith.
How do you migrate to the cloud without stopping the business?
A safe migration runs in stages, with the old and new environments working in parallel for a while. Teams map dependencies first, including integrations, scheduled jobs, and undocumented file shares.
They move non-production environments before production, rehearse the data migration on a copy of real data, and shift traffic gradually while keeping a rollback path.
Baseline metrics from the old environment make it possible to check whether the new one actually performs better.
Six Flags: cloud migration as one track of software modernization
Six Flags, a US amusement park operator that ran 27 properties at the time of the project, offers guests a mobile app for tickets, park maps, event schedules, and food orders. In the 90 days covered by the case study, 2.4 million people used it.
Merixstudio’s 11-person team started with discovery and a UX audit, then shifted the roadmap toward modernization.
The engineers refactored the code following Clean Architecture principles and updated outdated libraries. CI/CD pipelines moved from TeamCity to GitHub, a step that brought measurable stability improvements before any deeper architectural work began.
Appium-based test automation started covering both iOS and Android. The build server also moved to the cloud.
Crashes in the app fell by 97%. According to the client’s review on Clutch, the build server has had zero outages since the move, QA testing time dropped from five days to one, and bugs were addressed 50% faster. The migration was one part of a broader modernization that also covered the code and the testing process.
Summary
Cloud migration changes where software runs. Choosing lift and shift is a question of where the bottleneck sits, and the infrastructure is only one of the candidates.
When releases are slow or the application can’t scale, refactoring needs to be part of the same plan and budget. The move itself should run in stages, with a rollback path ready until the new environment proves stable.
FAQ
Is cloud migration the same as software modernization?
No. Cloud migration changes where an application runs, while software modernization also covers its code, architecture, and user experience. Migration is often one part of a modernization roadmap, and sometimes its first step.
How long does a lift and shift migration take?
A lift and shift migration can take as little as two to three months. The exact timeline depends on the number of integrations, the volume of data, and how well the system’s dependencies are documented.
Can moving to the cloud increase costs?
Yes, especially when an application is moved without changes. Systems designed for fixed servers often run oversized in the cloud and don’t use autoscaling. Flexera’s 2026 report estimates that 29% of IaaS and PaaS spend is wasted.
Can a legacy system be migrated to the cloud without downtime?
In most cases, downtime can be limited to a short, planned cutover window. Running both environments in parallel, rehearsing the data migration, and shifting traffic gradually keep the business operating during the move.
