What it is
The six Rs are a sorting tool for a migration portfolio. Each application gets a label: rehost, replatform, refactor, repurchase, retire or retain. The label describes the change you make to run that app in the cloud, not the order you work in. A single program will use several labels, sometimes on the same day.
Rehost moves the workload as it is, often a virtual machine image copied to cloud compute. Replatform makes a targeted change, such as moving a self-managed database to a managed service or putting an app in a container without rewriting its core. Refactor changes the design, splitting a monolith or replacing a batch process with events. Repurchase replaces the app with SaaS. Retire shuts it down. Retain keeps it where it is for now.
The labels are not a maturity ladder. A payroll system with a vendor-supported cloud image may be a good rehost. A reporting job that duplicates a SaaS tool may be retired. A latency-sensitive control system may be retained. The useful question is which option meets the business need with the least operational risk. The answer changes by app, not by company policy.
How it works
Start with an inventory that a finance lead and an engineer both trust. For each app, record the owner, business process, user count band, data stores, integrations, authentication, batch jobs, license terms and recovery target. Add the reason the app exists. That last item exposes apps that can be retired.
Then score each app on a small set of filters: business value, technical debt, vendor support, data sensitivity, integration depth and team skill. Use a simple high, medium, low scale. The score does not make the decision, but it shows where a rehost is safe and where a refactor has a real payoff. Write the reason for each label in a short decision record. Future teams will ask why an app stayed on premises.
For each chosen path, define the work. A rehost needs a landing zone, identity mapping, network rules, backup, monitoring and a cutover plan. A replatform needs a compatibility test and a rollback path. A refactor needs a design review and a phased release plan. Repurchase needs data export, integration and a contract exit clause. Retire needs archive and legal hold checks. Retain needs a review date and a trigger for the next decision.
Test the plan on one workload before you scale. Move a low-risk app, run it in parallel, compare performance and cost, and fix the landing zone. The first migration teaches more than a spreadsheet. Then update the labels with what you learned.
Why it matters for a business
A per-app decision keeps the migration budget honest. Refactoring every app is slow and expensive. Rehosting every app leaves you with the same operating problems on new hardware. The six Rs let you spend engineering time where it changes a business outcome and use simpler moves elsewhere.
It also gives finance and operations a clear view. Retire reduces support contracts and patching. Retain avoids a bad move for a system that needs local hardware or a vendor that does not support cloud. Repurchase can cut maintenance, but it adds subscription cost and integration work. Naming those trade-offs early prevents surprises after cutover.
The labels help with risk. Rehost is fast but carries old settings, old certificates and old failure modes into the cloud. Replatform reduces some operational load but adds a dependency on a managed service. Refactor can improve scale and release speed, but it is a product change, not a hosting change. Retain is a valid answer when the cost or risk of moving is higher than the benefit.
Common mistakes
The first mistake is treating refactor as the default. Most apps do not earn a rewrite. A rewrite adds months, a new test burden and a second system to run during the transition. Pick refactor when the current design blocks a clear business goal, such as handling peak load or meeting a release cadence.
The second is a rehost with no operating model. A copied server still needs patching, backup tests, log review and access control. If the team keeps the same manual runbooks, the cloud bill and the outage risk both grow. Rehost should include a cleanup list for the settings that made sense in the data center and do not make sense now.
Other misses are common. Teams skip retire and retain, so low-value apps keep paying rent. Repurchase projects ignore data export and integration until late. Licensing is treated as a finance detail after the design is fixed. Cutover plans have no rollback. The migration is called done at go-live, before monitoring and cost controls are in place.
How to get started
Pick one application and write a one-page brief. State the business process, the target outcome, the data it touches and the deadline. List the six options and mark the two that fit. Add the cost drivers you can see: engineering time, license change, training, integration and run cost. That page is enough to start a real review.
Build a small landing zone before the first move. Set up accounts, identity, network segments, logging, backup and infrastructure as code. Define what good looks like for the app: response time, recovery point, recovery time and support hours. Run a pilot cutover and a rollback drill. Record what broke and fix the template.
Then group apps into waves by pattern, not by department. Put clean rehosts in an early wave. Keep refactors in a separate wave with product owners. Put retire candidates through an archive check. Give retain decisions a review date. If you want a structured starting point, Cloudverg's Discovery and roadmap sprint is a two-week fixed price engagement at $9,500 that ends with an architecture, a phased roadmap and a fixed price for phase one. It is one option among others, and you can run the same exercise with your own team.
Frequently asked questions
What are the 6 Rs of cloud migration?
They are rehost, replatform, refactor, repurchase, retire and retain. Each label describes how an application changes when it moves to the cloud. You apply them per application, not as one program-wide choice.
Is rehost the same as lift and shift?
Yes. Rehost means moving the workload with little or no code change, often as a virtual machine. It is a good fit for a stable app that needs to leave a data center quickly. Plan for patching, backup and access cleanup so the old problems do not move with it.
Should every application be refactored?
No. Refactor is the most expensive option and it should answer a clear business goal. Many apps are better rehosted, replatformed, repurchased or retired. Some should stay where they are until a trigger forces a new review.