Cloud Modernization Frameworks Compared: Rehost, Replatform, or Refactor?

Rehost when speed and risk reduction matter more than long-term cost or agility. Replatform when a few targeted changes, such as a managed database or containerized runtime, unlock most of the operational benefit without a rewrite. Refactor when an application is strategically important and its current architecture is actively blocking the business. A sound cloud modernization framework does not pick one of these for your entire estate. It assigns the right approach to each workload based on business value, technical condition, and your team's capacity to absorb change.

The rest of this post explains how each approach works, where the terminology comes from, and how we recommend making the call workload by workload.

Why This Decision Keeps Stalling Teams

Most organizations we talk to are not short on cloud ambition. They are stuck at the decision point. A few patterns show up repeatedly:

• One strategy applied to everything. Leadership mandates "lift and shift by Q4" or "go cloud-native," and the mandate collides with an estate where workloads have very different needs.
• Inconsistent vocabulary. One team's "refactor" is another team's "replatform," so planning meetings argue about words instead of tradeoffs.
• Cost surprises after migration. Workloads that were rehosted without rightsizing often cost more in the cloud than they did on premises, which erodes confidence in the whole program.
• Rewrites that never finish. Ambitious refactors lose sponsorship halfway through because they deliver no value until the very end.

A framework exists to make these tradeoffs explicit and repeatable.

Where the Cloud Modernization Framework Vocabulary Comes From

The "R" terminology traces back to Gartner's 2010 "5 Rs" model (rehost, refactor, revise, rebuild, replace). Cloud providers have since published their own variants:

• AWS describes seven strategies in its Prescriptive Guidance on migration strategies: retire, retain, rehost, relocate, repurchase, replatform, and refactor.
• Microsoft's Cloud Adoption Framework uses overlapping terms but draws some boundaries differently. Its definitions of "refactor" and "rearchitect" don't map one-to-one onto the AWS definitions.
• Google Cloud publishes migration guidance that groups approaches into lift-and-shift, improve-and-move, and remove-and-replace.

The practical lesson: define your terms in writing before you classify a single workload. In this post, we use the AWS definitions for the three approaches in the title:

Rehost, Replatform, Refactor: The Tradeoffs in Detail

Rehost (lift and shift)

Rehosting moves servers as-is to cloud infrastructure, often with automated replication tooling.

Choose it when:

• A hard deadline exists, such as a data center lease expiry or hardware end-of-support.
• The application is stable, low-change, and unlikely to need new features.
• You need to build cloud operating muscle (identity, networking, monitoring) before tackling harder workloads.

Watch out for:

• Rightsizing. On-premises servers are frequently over-provisioned. Carry that sizing into the cloud and you pay for it hourly.
• Licensing. Some commercial software licenses change terms in cloud or virtualized environments. Check before you move.
• Deferred debt. Rehosting doesn't fix architectural problems. It relocates them.

Replatform (lift, tinker, and shift)

Replatforming keeps the core application intact but swaps selected components for managed equivalents. Common examples include moving a self-managed database to a managed service, running the app in containers, or replacing a self-hosted queue with a managed one.

Choose it when:

• Operational burden (patching, backups, failover) is a bigger pain than the code itself.
• The application has a reasonable lifespan ahead of it.
• You want measurable improvement without the risk profile of a rewrite.

A typical replatform change is small in code but meaningful in operations. Externalizing configuration so the app can point at a managed database is often the first step:

# Before: hardcoded connection to a self-managed host
# conn = psycopg2.connect(host="db01.internal", dbname="orders", user="app")

# After: configuration injected by the platform; credentials from a secrets manager
import os
import psycopg2

conn = psycopg2.connect(
    host=os.environ["DB_HOST"],          # managed endpoint
    dbname=os.environ["DB_NAME"],
    user=os.environ["DB_USER"],
    password=os.environ["DB_PASSWORD"],  # injected at runtime, never committed
    sslmode="require",
)

This aligns with the Twelve-Factor App principle of storing config in the environment, and it makes later steps, including a future refactor, much easier.

Refactor (re-architect)

Refactoring changes the application's structure to take advantage of cloud-native capabilities: decomposing a monolith, adopting event-driven patterns, moving to serverless, or redesigning the data layer.

Choose it when:

• The application is a genuine differentiator and the business needs it to change faster.
• Scaling limits, deployment friction, or reliability issues are rooted in the architecture itself.
• You have sustained engineering capacity and executive sponsorship for a multi-quarter effort.

Watch out for:

• Big-bang rewrites. We strongly prefer incremental approaches such as Martin Fowler's Strangler Fig pattern, where new services gradually take over routes from the legacy system.
• Distributed systems complexity. Microservices trade code complexity for operational complexity. If your team lacks observability and on-call maturity, that trade may not pay off yet.

A strangler-style cutover can be as simple as routing rules at the edge:

# Route the new, refactored service; everything else still hits the monolith
location /api/v2/orders/ {
    proxy_pass http://orders-service;
}

location / {
    proxy_pass http://legacy-monolith;
}

Each route you move delivers value on its own, which keeps the program funded.

How to Decide, Workload by Workload

We recommend scoring each application on a small number of dimensions and letting the scores drive a default recommendation, which humans then review. Keep the model simple enough that stakeholders trust it.

# Example per-workload assessment record
workload: order-management
business_criticality: high        # low | medium | high
change_frequency: high            # how often the business needs new features
technical_health: poor            # code quality, test coverage, dependency age
operational_burden: high          # patching, manual failover, on-call load
remaining_lifespan_years: 5+
hard_deadline: none
team_capacity: medium

# Heuristic outcome (reviewed by architects, not applied blindly)
recommended_approach: refactor
rationale: >
  High change frequency and poor technical health on a long-lived,
  business-critical system. Use strangler pattern; replatform DB first.

Some heuristics that hold up well in practice:

1. Low change, short lifespan, hard deadline → rehost, then reassess or retire.
2. High operational burden, moderate change, healthy code → replatform.
3. High change, high criticality, architecture is the bottleneck → refactor incrementally.
4. Nobody can name the owner or the users → investigate for retirement before migrating anything.

Don't skip the retire and retain options. Every workload you decommission is one you never have to migrate, secure, or pay for.

Sequencing: The Approaches Are Not Mutually Exclusive

The most effective programs treat these approaches as stages rather than permanent labels. A common and sensible path:

1. Rehost to meet the deadline and establish a cloud landing zone with sound identity, network, and logging foundations.
2. Replatform the highest-toil components, usually the database and the runtime, once workloads are stable.
3. Refactor selectively, focusing on the services where architecture limits business outcomes.

This sequencing reduces risk because each stage is independently valuable and reversible. It also builds team skills progressively instead of demanding cloud-native expertise on day one.

Common Pitfalls to Avoid

• Skipping discovery. Undocumented dependencies such as batch jobs, file shares, and hardcoded IPs are the most common cause of failed cutovers. Invest in dependency mapping early.
• No baseline metrics. If you don't measure cost, latency, and deployment frequency before migrating, you can't show improvement afterward.
• Treating security as a phase. Identity, encryption, and network segmentation decisions belong in the landing zone design, not in a post-migration audit.
• Ignoring FinOps. Tagging, budgets, and cost ownership should exist before the first workload moves.

Where to Start

If you are building or revisiting your own framework, start small: agree on definitions, assess a representative sample of ten to twenty workloads, and pressure-test the heuristics against real constraints. If you want a senior partner to help with assessment, landing zone design, or incremental refactoring, our cloud and engineering capabilities describe how we approach this work. Regulatory and operational constraints vary widely by sector, so it is also worth reviewing how modernization differs across industries before you lock in a plan.

FAQ

What is a cloud modernization framework?

It's a structured method for deciding how each application in your portfolio should move to or evolve in the cloud. It typically combines a shared vocabulary (such as the "Rs"), assessment criteria, and sequencing guidance so that decisions are consistent and defensible across teams.

Is rehosting a waste if we plan to refactor later?

Not necessarily. Rehosting can meet a hard deadline, establish cloud foundations, and give your team operational experience. The risk is stopping there. Treat rehost as a stage with a scheduled reassessment, and rightsize resources immediately to avoid paying for on-premises over-provisioning.

What is the difference between replatform and refactor?

Replatforming swaps components, such as a database or runtime, for managed equivalents while leaving application logic largely unchanged. Refactoring changes the application's architecture and code to use cloud-native patterns. Note that vendors define these terms slightly differently, so confirm definitions before planning.

How do we avoid a refactor that never finishes?

Refactor incrementally using patterns like the Strangler Fig, where new services take over specific routes or capabilities one at a time. Each increment should ship to production and deliver measurable value, which keeps sponsorship intact and limits risk.