What is Cloud Migration?

What is cloud migration?

Cloud migration is the process of moving applications, data and workloads from one environment to another, most often from on-premises servers to a public cloud such as AWS, Azure or Google Cloud. It also covers moves between clouds and back to on-premises (repatriation). A migration can be a plain move of a server, or a redesign of the application to use managed cloud services.

The 7 Rs of cloud migration

AWS describes seven migration strategies, usually called the 7 Rs. You pick one per application, not one for the whole estate.

• Rehost (lift and shift). Move the application as is, with no changes.
• Replatform (lift, tinker and shift). Move it and make a few optimizations, such as a self-managed database to a managed one.
• Refactor or re-architect. Redesign it for cloud-native features. Most complex and costly of the seven.
• Relocate. Move servers or instances to the cloud version of the same platform, or to another account, VPC or region, without changing the architecture.
• Repurchase (drop and shop). Replace the application with a SaaS or newer product.
• Retire. Switch off applications nobody needs. AWS suggests candidates such as apps with no inbound connection for 90 days.
• Retain. Leave it where it is, for example because of data residency rules, specialized hardware, a mainframe or a recent hardware purchase.

For large migrations AWS recommends rehosting, relocating or replatforming first and modernizing afterwards, because refactoring during the move is the hardest path to manage.

Phases of a migration

1. Assess and plan

Inventory applications, dependencies, data flows, network needs and licenses. Group applications into waves and choose a strategy for each. Record today's performance, since that is your baseline later.

2. Build the landing zone

Set up accounts, networking, identity, logging and cost controls before anything moves. Defining this in code with infrastructure as code keeps it repeatable. See cloud governance for the rules to set early.

3. Pilot wave

Move a few low-risk applications first to prove the landing zone, the cutover steps and the rollback plan.

4. Migration waves

Each wave has a data sync method, a DNS cutover plan, a rollback plan and monitoring. Test before the cutover, not after.

5. Optimize and operate

Right-size instances, remove idle resources, review data transfer costs and modernize what you rehosted. Track the result with cloud monitoring.

Example

A company runs a web shop on two on-premises servers with a self-managed MySQL database. It chooses to replatform: the app moves to virtual machines in the cloud and the database moves to a managed MySQL service. Before the cutover it runs a load test at the expected peak against the new stack and compares response times and error rate with the numbers recorded on the old servers. It switches DNS only when the new environment matches or beats them, and keeps the old servers for a defined window as the rollback path.

Common cloud migration mistakes

• Rehosting everything and stopping. The move is quick, but without right-sizing and cleanup you pay for oversized machines.
• Skipping the baseline. Without on-premises measurements you cannot tell whether the cloud version is slower.
• Not testing under load. Network paths, storage throughput, managed service limits and identity calls behave differently from the old data center.
• Ignoring data transfer costs. Traffic between zones, regions and out to the internet is billed, so data placement matters.
• Leaving identity for last. Directory and single sign-on dependencies often block a cutover.
• No cost guardrails. Budgets, tags and alerts should exist before the first workload lands.
• Decommissioning the old environment too early. Keep it until the rollback plan has not been needed for an agreed period.
• Forcing a refactor into the move. Splitting a monolith into microservices during migration adds risk. Migrate first, modernize after.

Validating a migration with testing and monitoring

The step teams skip most is proving the migrated application performs. Run a load test against the new environment at expected peak traffic and compare it with your baseline. The LoadFocus load testing platform runs JMeter and k6 tests from 25 cloud regions, so you can generate traffic from where your users are. After cutover, API monitoring checks status codes, response bodies and response time on a schedule and alerts you on failures. For the testing side of the decision, read cloud vs on-premise load testing.

FAQ: Cloud migration

How long does a cloud migration take?

It depends on the number of applications, their dependencies and the strategy chosen. A rehost of a few simple servers can take weeks, while a large portfolio is planned in waves over months or years. Treat any single number as a guess until the assessment is done.

What is the difference between rehost and replatform?

Rehost moves the application without changes. Replatform moves it and makes a few optimizations, such as switching to a managed database, without redesigning the application.

Should every application move to the cloud?

No. Some applications are retired and some are retained because of compliance, specialized hardware or a recent investment. The 7 Rs include both options for that reason.

What is cloud repatriation?

Moving workloads from the cloud back to on-premises or a colocation facility. Teams do it for cost, compliance or predictable workloads that do not benefit from elastic capacity.

How do I test a migration before cutover?

Record baseline response times and error rates on the old environment, run a load test at expected peak against the new one, compare the results, and rehearse the rollback. Switch traffic only when the numbers match.