Choosing a Cloud Migration Strategy for Custom Applications: The 7 Rs in Practice

"Should we move this application to the cloud?" is rarely the right question. The useful question is what should we do with this specific application: move it as it is, change its platform, rewrite part of it, replace it with a SaaS product, keep it where it is, or switch it off. The major cloud providers each publish a framework for that decision, usually called the "Rs" of cloud migration. This guide explains how those frameworks compare and how to apply them to custom applications, where you own the code and therefore have more options than with packaged software.

The Rs, according to the people who coined them

The lists differ slightly between providers, which is a common source of confusion in planning meetings. It helps to see them side by side.

AWS describes seven migration strategies, the "7 Rs": retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect.

Microsoft's Cloud Adoption Framework lists eight: retire, rehost, replatform, refactor, rearchitect, replace, rebuild and retain. It separates refactor (modernising code) from rearchitect (changing the architecture), and uses "replace" where AWS says "repurchase".

Google Cloud describes migration types including rehost (lift and shift), replatform (lift and optimise), refactor (move and improve), re-architect, rebuild (remove and replace) and repurchase, within a four-phase process of assess, plan, deploy and optimise.

The vocabulary varies, but the underlying choices are the same. For the rest of this article we use the following consolidated set:

• Retire — decommission the application.
• Retain — keep it where it is, for now.
• Rehost / relocate — move it with no or minimal change.
• Replatform — move it and swap parts of the platform for managed services, with limited code change.
• Refactor / rearchitect — change code or architecture to use cloud-native capabilities.
• Rebuild — rewrite it as a new cloud-native application.
• Replace / repurchase — swap it for a SaaS or vendor product.

Why custom applications need a different lens

With packaged software, your options are mostly limited to what the vendor supports: rehost it, upgrade it, or move to the vendor's SaaS edition. With custom software you control the source code, the data model and the release cadence, so every R is technically available. That freedom is exactly what makes the decision harder, because "we could rewrite it" is always on the table.

Custom applications also tend to carry hidden coupling: shared databases, file drops on network shares, hard-coded hostnames, scheduled jobs on the same server, and integrations nobody has documented. These dependencies, more than the application code itself, often determine which strategy is realistic.

A decision sequence that works in practice

Rather than scoring every application against every R, work through a short sequence of questions. Each one removes options early.

1. Should it exist at all? (Retire)

Start by removing work. AWS's guidance suggests candidates for retirement include applications with no business value in retaining or moving them, applications on unsupported operating systems or components, and applications with very low utilisation or no inbound connections over an extended period (it cites 90 days as an example window). Microsoft adds a simple test: retire when migration or modernisation cost outweighs the business benefit. Before retiring a custom application, confirm who still uses its data and whether records must be archived for legal or audit purposes.

2. Is something forcing it to stay? (Retain)

AWS lists common reasons to retain an application, including data residency and compliance requirements, dependencies on other applications that must move first, recent investment in upgrading the current environment, and dependencies on specialised hardware with no cloud equivalent. Retain is a legitimate decision, not a failure; record the reason and the condition that would change it.

3. Would a product do the job? (Replace / repurchase)

If a custom application reproduces commodity functionality, such as a basic CRM, ticketing or HR workflow, replacing it with SaaS may be the most sensible outcome. Microsoft's framework frames the driver as simplifying operations when there is little need for customisation and internal development resources are better used elsewhere. AWS notes that after purchasing, you still need to train users, migrate data, integrate authentication and configure networking. The more your application encodes processes that differentiate your business, the weaker the case for replacement.

4. Is it stable and not due for change? (Rehost / relocate)

Rehosting moves the application without changing it. AWS describes it as a way to migrate large numbers of machines with minimal disruption, noting that applications are easier to optimise once they are already running in the cloud. Microsoft adds two cautions that are especially relevant to custom applications:

• Don't rehost problematic workloads. Rehosting does not fix existing performance, reliability or architectural issues; it carries the technical debt with it.
• Rehost only if the workload won't need modernisation within about two years. Otherwise you pay for the migration twice.

5. Can managed services remove operational burden with small code changes? (Replatform)

For many custom business applications, replatforming is the most valuable option. Typical moves include replacing a self-managed database server with a managed database service, moving from virtual machines to containers or an application platform, or moving files from a local disk to object storage. AWS gives examples such as moving a SQL Server database to a managed database service and containerising applications without code changes. The key constraint is "limited code change": if the list of required changes keeps growing, you are really refactoring and should plan it as such.

6. Is there a business driver for deeper change? (Refactor / rearchitect / rebuild)

Refactoring and rearchitecting unlock the most cloud value but carry the most risk. AWS describes refactoring as the most complex and costly strategy and recommends that, in large migrations, teams rehost, relocate or replatform first and modernise after the migration is complete. Microsoft's framework ties rearchitecting to specific signals: the application needs modularisation, different components have different scaling needs, or the architecture blocks future capabilities.

Choose this path when there is a concrete business driver — the application cannot scale to demand, release cycles are blocked by a monolith, or maintenance cost is unsustainable — rather than because the target architecture is attractive. Rebuilding from scratch is reserved for systems that are obsolete or where modernisation is not feasible; for gradual approaches, our ERP integration guide discusses the anti-corruption layer pattern, which also helps when old and new systems must coexist.

What to gather before deciding

Good strategy decisions depend on a few facts per application. Collect them before the workshop, not during it:

• Business owner and criticality — who depends on it and what happens if it is unavailable.
• Dependency map — databases, file shares, scheduled jobs, inbound and outbound integrations.
• Data constraints — residency, retention and regulatory requirements.
• Technical condition — runtime and framework versions, test coverage, deployment method, known issues.
• Utilisation — actual usage and resource consumption, which feeds retire and right-sizing decisions.
• Change roadmap — planned features in the next two years, which determines whether rehosting would be wasted effort.
• Team skills — whether the people who will operate it are ready for the target platform.

Sequencing: waves, not a big bang

Once each application has a strategy, group them into migration waves. A few principles help:

• Start with a low-risk pilot that exercises the landing zone, networking, identity and deployment pipeline end to end.
• Move tightly coupled applications together, or introduce an integration layer first so they can be separated safely.
• Put cost visibility in place before the first production workload lands, so you can see the effect of each wave. Our guide to cloud cost governance for custom applications covers the basics.
• Revisit decisions between waves. Microsoft's framework recommends a regular review cycle so treatment decisions keep pace with business priorities and lessons learned.

Define success per application

Each strategy implies a different definition of success. Microsoft's framework suggests attaching success metrics to each decision so it can be validated against the business driver, not just technical completion. For example: a rehosted application should meet its existing service levels; a replatformed one should show reduced operational effort; a refactored one should meet the scaling or release-frequency goal that justified it. Writing these down before migration makes the post-migration review objective.

Summary

• The providers' "Rs" lists differ in naming, not substance.
• Work through retire, retain, replace, rehost, replatform, then refactor — in that order.
• Don't rehost applications with known problems or near-term modernisation plans.
• Prefer replatforming for stable custom applications that would benefit from managed services.
• Reserve refactoring and rebuilding for clear business drivers, and consider modernising after the move.
• Collect dependency, data and roadmap facts before deciding.

If you are planning a migration of custom applications and want a second opinion on the treatment of each one, see our cloud and custom software services or contact our team.

Frequently asked questions

Is it 6 Rs or 7 Rs?

Both lists are in circulation. AWS currently documents seven strategies (including relocate), Microsoft's Cloud Adoption Framework lists eight, and Google describes six migration types. The decisions they represent are broadly the same.

What is the difference between replatform and refactor?

Replatforming changes the hosting environment — for example, adopting a managed database or container platform — with minimal code changes. Refactoring changes the application's code to take advantage of cloud capabilities or reduce technical debt.

Should we modernise during the migration or after?

AWS recommends modernising after migration for large programmes, because refactoring during migration adds complexity. Microsoft suggests modernising during migration only when the team has the skills and time, when compatibility updates are required anyway, or when the migration unlocks funding that would otherwise be lost.