What Are Migration Patterns in Cloud Computing

Section 01

The 10 Cloud Migration Patterns (The R's and Beyond)

Gartner's original "5 R's" and the 6 and 7 R's AWS later popularized are a decent starting point, but the 2025 cloud reality is more complex. The modern playbook includes patterns for dealing with monoliths, containers, and massive data gravity. Here’s the full list, from simple moves to complex architectural shifts.

1. Rehost (“Lift-and-Shift”)

Fastest time-to-cloud, lowest risk. Move VMs/databases as-is using AWS Application Migration Service, Azure Migrate, Google Cloud Migrate to Virtual Machines, or VMware HCX. 2025 reality: still the correct first move for many workloads when you have hard regulatory or M&A deadlines.

2. Replatform (“Lift-Tinker-and-Shift”)

Minimal code changes for big wins: on-prem Oracle/SQL Server → managed Amazon RDS/Aurora, WebLogic → Tomcat on AWS Fargate, IIS → AWS Elastic Beanstalk. Typical payoff: lower operational burden and minimal-downtime cutovers with AWS Database Migration Service (DMS) CDC.

3. Repurchase (“Drop-and-Shop”)

Replace with SaaS: Salesforce instead of Siebel, Workday instead of PeopleSoft, ServiceNow instead of Remedy. Highest ROI long-term but highest org-change pain. 2025 rule: only repurchase if the vendor's product already covers most of what you need.

4. Refactor / Re-architect

Break monoliths into microservices, move to containers (EKS/AKS/GKE) or serverless (Lambda, Cloud Functions). Only justified when you need far more scale than the current architecture can reach, a latency target it cannot meet, or independent team deployment velocity. Costs far more than rehost; never do it “because cloud-native is cool.” For a deep dive, see our guide on the Strangler Fig Pattern with examples.

5. Retire / Decommission

The highest-ROI pattern nobody budgets for. Most legacy portfolios contain applications that are unused or duplicated, and an inventory will find them. Kill them before migration and save millions in perpetual licensing and cloud spend.

6. Retain / Hybrid

Keep on-prem or in private cloud forever (mainframes, ultra-low latency trading, nuclear SCADA, massive Oracle Exadata that costs less on-prem). 2025 twist: run new workloads in public cloud while keeping the old beast behind AWS Outposts, Azure Stack, or Google Distributed Cloud until natural EOL.

7. Relocate

Hypervisor-to-hypervisor moves with zero architecture change (VMware on-prem → VMware Cloud on AWS, VMware → Azure VMware Solution, Hyper-V → GCP Bare Metal). Perfect for companies that want cloud billing but refuse to touch the app.

8. Containerize-First (The 2025 Dark Horse)

New default for any custom web app or backend service: package once into Open Container Initiative (OCI) containers, run anywhere (Amazon EKS Anywhere, Azure AKS, Google GKE, on-prem Kubernetes, Google Cloud Run, Azure Container Apps). Decouples “where it runs” from “how it’s built” and kills future migration tax.

9. Data-Gravity Reverse Migration (The One Nobody Talks About)

When very large datasets become too expensive to egress or need very low latency, move the compute back closer to the data (Snowball Edge, Outposts, GCP Distributed Cloud, Azure Local).

10. Strangler-Fig Pattern (The Only Safe Way to Kill a 25-Year Monolith)

Incrementally extract domains to new cloud-native services behind a facade (Amazon API Gateway, Istio, Amazon VPC Lattice). Each release retires another piece of the old system until nothing is left. Expect a long program, often measured in years, but it is a proven way to refactor without a Big Bang death march.

Section 02

High-Effort, High-Reward Patterns: Refactor and Rearchitect

Refactor and Rearchitect are the high-effort, big-budget end of the migration spectrum, reserved for core business applications where small tweaks no longer help. They fundamentally change an application's structure to unlock capabilities that are currently impossible.

Both patterns usually mean breaking down a monolith into smaller, independent pieces like microservices or serverless functions. But they are not the same, and the business case for each differs. Choosing this path just because "cloud-native is cool" is a reliable way to blow your budget. The business case has to hold up.

Distinguishing Refactor from Rearchitect

The terms are often used interchangeably, but their drivers differ. Understanding the difference is key to justifying the investment.

• Refactor: This is about changing the internal structure of the code without changing its external behavior. The goal is to improve things like performance, maintainability, or scalability. You might refactor a critical service to hit a sub-100 ms latency target because the current lag is costing you customers.
• Rearchitect: This is a much deeper change to the application’s fundamental architecture. The driver here is usually organizational or strategic. You might rearchitect a monolith to enable independent team deployment velocity, letting different product teams ship features on their own schedule without a massive, coordinated release day.

You refactor to make the current application better. You rearchitect to change how your organization builds and ships that application.

The decision to refactor or rearchitect is never just technical. It must be directly tied to a business outcome: more revenue from better performance, faster time-to-market from agile teams, or the ability to enter a new global market. Anything less is an expensive science project.

The Stark Realities of Cost and Risk

A full refactor can cost many times more than a simple rehost. It's often a multi-year commitment that brings on significant risk if you don't manage it with discipline.

This is why phased, incremental approaches matter. Our guide on the Strangler Fig Pattern with examples covers a lower-risk method for dismantling a large legacy system. This strategy lets you systematically carve off and replace pieces of the monolith over time, steering clear of a "big bang" cutover that rarely succeeds.

Refactoring is worth it only when the pain of the old architecture costs more than the migration itself. When you need far more scale, faster development, or performance SLAs you cannot meet today, refactoring is a strategic investment rather than an engineering exercise.

Section 03

The CTOs Decision Matrix for Choosing the Right Pattern

Knowing the different migration patterns is one thing; knowing which one to use for which application is the decision that matters. Getting it wrong has compounding financial and operational consequences.

The analysis is not complicated, but it does demand honesty about an application's actual business value versus its perceived importance.

Matching Patterns to Business Reality

Every pattern is a trade-off. Rehost is fast and cheap but delivers almost zero cloud-native value. Refactor is slow and expensive but can fundamentally reshape your business capabilities. There is no "best" pattern, only the one that best serves a specific, measurable business goal.

A common failure is treating all applications the same. Your high-volume e-commerce platform and the internal HR tool from 2005 do not deserve the same investment or risk profile. Forcing a one-size-fits-all strategy across a diverse portfolio reliably blows the budget and stalls the program.

This decision flow gives you a simplified mental model for modern workloads. It guides you from custom applications toward containerization and from old monoliths toward smarter strategies like the Strangler Fig pattern.

Modern patterns are highly specialized, so the right choice depends on the application's architecture and the business problem you're trying to solve.

Decision Matrix Every CTO Should Use

Use the matrix in week one, before any engineering work starts.

Section 04

Straight Answers to Hard Questions

Knowing the textbook definitions of migration patterns is one thing; applying them where budgets are tight and legacy code is a mess is harder. Technical leaders ask the same questions repeatedly.

Here are direct answers.

Replatform vs. Refactor: When Do You Choose Which?

This decision depends on the business driver more than the technology: are you chasing an efficiency gain or a fundamental business model change?

Go with Replatform for a quick win with a fast ROI. It is the classic high-return, low-effort move. A perfect example is moving an on-premise database to a managed cloud service like Amazon RDS. You immediately kill licensing fees and operational headaches.

Only choose Refactor when your application's architecture is a direct bottleneck to making money or keeping up with competitors. If your system physically cannot scale to meet customer demand, or if your painfully slow deployment speed means you can't ship features fast enough, then a refactor is justified. Otherwise, it's just an expensive science project that burns cash for no clear return.

Picking Refactor without a rock-solid business case is a common and expensive mistake. It has to be driven by a firm need for massive scale or development velocity, not just a vague desire to be "cloud-native."

Is the Strangler-Fig Pattern Always the Best Way to Kill a Monolith?

It’s the safest way to decommission a complex, high-risk monolith without a "big bang" failure, but it's definitely not always the best way. This pattern is a serious commitment, demanding years of sustained architectural discipline.

The Strangler-Fig is reserved for systems that are too valuable to turn off but far too risky to rewrite in one go. If a monolith is non-critical, has low business impact, or could be replaced entirely by a SaaS tool (Repurchase), those are much faster and cheaper options. Don't bring a scalpel when a sledgehammer will do the job.

When Does It Actually Make Sense to Just Rehost?

Rehosting often gets a bad rap as a lazy "lift-and-shift," but it's the right strategic call in a few specific scenarios where speed is everything and risk has to be minimized.

• Hard Deadlines: You have to be out of a data center before a contract expires. An M&A deal requires you to integrate systems by a fixed date. There's simply no time for anything fancier.
• Stable, "Don't Touch It" Apps: The application works, it's not under active development, and there’s no business reason to change it. Rehosting is a perfectly logical move here.
• Portfolio-Wide Lift: This is a tactical first step to get an entire application portfolio into the cloud quickly, stop the on-prem spending bleed, and then circle back to optimize high-value applications later.

In these cases, a lift-and-shift is a sound business decision that prioritizes the most urgent needs over long-term perfection.

---

Choosing the right migration pattern is just step one. Picking the right implementation partner is where most of these projects actually succeed or fail. Software Modernization Intelligence publishes independent research on modernization partners and approaches, so you can make a defensible decision without the vendor sales pitch. Get your vendor shortlist at https://softwaremodernizationservices.com.