The 6 Rs of Cloud Migration: How to Assign Each Workload

The six strategies, and when each one fits

• Retire: switch off what nobody uses. Check access logs first, because something usually still depends on it.
• Retain: leave the workload where it is for now. Set a review date, or "for now" becomes permanent.
• Rehost: move the application largely unchanged. It is the fastest route, and any existing inefficiency moves with it.
• Replatform: move with small changes, such as a managed database. Watch for behavior changes at the database or queue boundary.
• Repurchase: replace the function with a SaaS product when it is a commodity a vendor runs better. Plan the data migration and the contract exit.
• Refactor: re-architect for cloud-native operation. It has the longest timeline and the most unknowns, so it needs a written business case.

How to choose for each workload

Every workload gets its answer after four checks:

1. Does anyone use it? Usage logs, a named owner and the date of the last change. Retire candidates usually show up here.
2. What does it depend on? Upstream and downstream systems, scheduled jobs, certificates, DNS records and licenses. This is the step most often skipped.
3. What does changing cost, compared with waiting? Model both over the same period, with the assumptions written down, in USD.
4. What rules govern the data? Data-protection rules apply as applicable in your jurisdiction, and they shape where personal data may be stored and how transfers are documented. Those rules can narrow the options for a given data set.

Then sequence the work. This order works for many estates. It is a heuristic, not a rule:

• Retire first. It is the cheapest saving and it shrinks the scope.
• Rehost the stable and simple. It gets workloads off aging hardware quickly.
• Replatform what a managed service runs better.
• Repurchase or refactor only with a written case and a named owner.
• Retain with a review date. A retained workload is still a decision.

How TiCON runs the classification

TiCON runs a free one-week discovery. It classifies each workload to one of the six Rs and delivers a fixed-quote roadmap. Typical durations in our project record are 4 to 8 weeks for small migrations, 8 to 16 weeks for medium ones, and 4 to 6 months for large ones. Discovery results move these numbers. AWS funding programs may apply to a migration; eligibility is AWS's decision, not ours.

Each workload goes into a decision register, one line each:

• Name and owner
• The chosen R, and one sentence on why
• Dependencies and data classification
• The rollback trigger and how long a rollback may take
• A review date for Retain, or the success metric for everything else

Finance, security and the CTO will each ask for this register. Building it during discovery costs less than rebuilding it during an incident. The framework is the same whether the target is AWS, Azure or Google Cloud. Engagements are quote-based and billed in USD; other currencies are by contract, so ask.

Next step: send us an inventory, or talk to an architect. For a rough range first, use the migration cost calculator.

Related reading

[Cloud Migration Checklist: Ten Gates Before Cutover](/resources/blog/cloud-migration-checklist) The gates to pass before data moves and before cutover, with the evidence each gate needs.

[Why Cloud Migrations Fail, and What to Do About Each](/resources/blog/why-cloud-migrations-fail) The common failure patterns and the checks that catch them early.

[How Much Does Cloud Migration Cost?](/resources/blog/how-much-does-cloud-migration-cost) The cost drivers, timelines by size, and what a USD quote should contain.