A cloud migration is one of six strategies: rehost, replatform, repurchase, refactor, retire, or retain. The mistake most teams make is treating all of their workloads the same way. The right answer depends on the workload - some workloads should be rehosted, some should be refactored, and some should be retired.
Table of contents
The six strategies
The six strategies, with the most common use case for each:
- Rehost (lift and shift). Move the workload as-is to the cloud. The cheapest and fastest; the most expensive to operate long-term.
- Replatform. Move the workload to the cloud with minor changes. The middle ground; the most common.
- Repurchase. Replace the workload with a SaaS equivalent. The most expensive upfront; the cheapest to operate long-term.
- Refactor. Rewrite the workload to be cloud-native. The most expensive; the most benefit.
- Retire. Decommission the workload. The cheapest; the most underused.
- Retain. Keep the workload on-premises. The right answer for some workloads.
How to pick
The decision rule: pick the strategy that matches the workload’s value to the business, the cost of the migration, and the cost of the long-term operation. Most teams undervalue retire and retain.
A useful exercise: list every workload the team owns, score each on business value and migration cost, and pick the strategy for each. The result is usually 60% rehost, 20% replatform, 10% refactor, 5% repurchase, 5% retire, 0% retain - the 5% retire is the surprise.
Rehost (lift and shift)
Rehost is the right answer for:
- Workloads that are not worth rewriting but need to be off the on-premises data center.
- Workloads that are nearing end of life and will be retired soon.
- Workloads that are operationally expensive on-premises and the cloud would be cheaper to operate, even without rewriting.
The trap: the team rehosts a workload, the cloud bill is higher than the on-premises cost, and the team concludes “the cloud is too expensive.” The conclusion is wrong. The right conclusion is “we rehosted the wrong workloads.”
Replatform
Replatform is the right answer for:
- Workloads that need minor changes to benefit from the cloud (e.g., moving from a self-managed database to RDS).
- Workloads that are too expensive to refactor but too important to rehost as-is.
The trap: the team replatforms a workload and discovers the cloud bill is 2x what they projected. The fix is usually in the data transfer costs (egress, cross-AZ traffic) or in the licensing costs (Microsoft, Oracle) that the on-premises setup was avoiding.
Refactor
Refactor is the right answer for:
- Workloads that are core to the business and need to scale.
- Workloads that are operationally expensive on the current architecture.
- Workloads that need to be cloud-native to integrate with the rest of the stack.
The trap: the team refactors a workload that does not need to be refactored, the migration takes a year, and the team is exhausted. The fix is to start with the workload that has the highest business value and the highest cost reduction, and refactor that one. The rest can wait.
Retire and retain
Retire is the right answer for:
- Workloads that are no longer used.
- Workloads that have been replaced by a newer system.
- Workloads that were created for a one-off project and never cleaned up.
Retain is the right answer for:
- Workloads that are too expensive to migrate and too cheap to operate to justify the migration cost.
- Workloads with regulatory or compliance requirements that are easier to meet on-premises.
- Workloads with latency requirements that are easier to meet on-premises.
FAQ
What is cloud migration?
The process of moving workloads from an on-premises data center to a cloud provider. The process can be rehost, replatform, repurchase, refactor, retire, or retain.
What is the difference between rehost and replatform?
Rehost is moving the workload as-is to the cloud. Replatform is moving the workload with minor changes - e.g., moving from a self-managed database to RDS. Replatform is the middle ground; it is the most common strategy.
Which cloud migration strategy is the cheapest?
Rehost (lift and shift) is the cheapest and fastest. Retire is the cheapest overall if the workload is no longer used. Refactor is the most expensive but has the highest long-term benefit.
How do I decide which workloads to migrate?
List every workload the team owns, score each on business value and migration cost, and pick the strategy for each. The result is usually 60% rehost, 20% replatform, 10% refactor, 5% repurchase, 5% retire, 0% retain.
If you are sizing a cloud migration project, the RunxBuild hosting calculator is the place to model the line items. The compute, the storage, the egress, the licensing - each one is a separate number, and the team’s mental model for the project is the sum of those numbers. The RunxBuild dashboard is where the team sees the post-migration production observability in one place.