Refactor and replatform are the two cloud migration strategies that genuinely modernise the workload. Both produce lower steady-state cost than lift-and-shift; both cost more to execute upfront. The decision between them, and the decision of which workloads to apply each to, is one of the most consequential strategy choices in any cloud migration programme. This page is the 2026 cost reference for the comparison: per-workload cost, ongoing run-rate, break-even analysis, and the practical decision framework.
Replatform makes targeted modifications to a workload to take advantage of cloud-managed services without redesigning the application. The application code remains substantially intact; the platform underneath changes. Typical replatform examples: moving SQL Server from a self-managed VM to Azure SQL Managed Instance (managed database service, no application code changes required); moving a Tomcat web server to AWS Elastic Beanstalk (managed platform, configuration change rather than application change); moving an on-premise ASP.NET web application to Azure App Service (managed PaaS, minor configuration changes).
Refactor (or re-architect) rebuilds the application to be cloud-native. The application architecture changes fundamentally: monolithic applications become microservices, long-running processes become serverless functions, server-based deployments become container orchestration, batch jobs become event-driven pipelines. Typical refactor examples: rebuilding a Java monolith as Spring Boot microservices on Amazon EKS; converting a Python batch processing system to AWS Step Functions plus Lambda; rebuilding a .NET Framework application as .NET 8 microservices on Azure Container Apps.
The per-workload migration cost difference between replatform and refactor is substantial and consistent across the major cloud migration cost surveys.
Per-workload migration cost, 2026
| Strategy | Per workload (low) | Per workload (typical) | Per workload (high) | Timeline per workload |
|---|---|---|---|---|
| Rehost (lift-and-shift, baseline) | $3,000 | $5,500 | $8,000 | 2 to 4 weeks |
| Replatform | $8,000 | $16,000 | $25,000 | 4 to 12 weeks |
| Refactor / re-architect | $25,000 | $52,000 | $80,000 | 12 to 52 weeks |
| Refactor (complex monolith to microservices) | $80,000 | $200,000 | $500,000+ | 26 to 78 weeks |
The cost premium for refactor over replatform is roughly 3 to 4 times. The cost premium for replatform over lift-and-shift is roughly 2 to 3 times. These ratios are stable across the major migration cost surveys (AWS, McKinsey, Forrester, Gartner) and provide a reliable rule of thumb for scoping.
The run-rate reduction varies by workload pattern. The headline figures from the major cloud cost surveys: replatform typically produces a 10 to 20 percent run-rate reduction versus lift-and-shift; refactor typically produces a 30 to 50 percent run-rate reduction. The reductions are real but depend on the workload pattern matching the cloud-native architecture.
Run-rate cost impact by strategy, typical mid-market workload
| Strategy | Monthly run-rate vs on-prem | Monthly run-rate vs lift-and-shift | 3-year run-rate saving (per workload) |
|---|---|---|---|
| On-premise (baseline) | 100% | n/a | n/a |
| Rehost (lift-and-shift) | +5 to +15% | Baseline | Negative; lift-and-shift typically costs more |
| Replatform | -5 to -15% | -10 to -20% | $3K to $15K per workload |
| Refactor | -25 to -45% | -30 to -50% | $15K to $60K per workload |
The 3-year saving figures assume a workload with $1,000 to $3,000 per month of on-premise run cost. For workloads with higher run cost the savings scale proportionally; for workloads with lower run cost the savings are smaller. The break-even analysis below shows how the per-workload economics work out.
The decision between replatform and refactor on any single workload should be based on the break-even between the additional migration cost and the run-rate saving. The analysis is straightforward:
Refactor break-even formula
Worked break-even examples for typical workload sizes:
Refactor vs replatform break-even, by workload run cost
| Monthly run cost (on replatform) | Monthly run cost (on refactor) | Run-rate saving (per month) | Break-even (months) | Verdict at 36 months |
|---|---|---|---|---|
| $500 | $300 | $200 | 180 | Replatform wins (refactor never pays back) |
| $1,500 | $900 | $600 | 60 | Replatform wins (close but not enough) |
| $3,000 | $1,800 | $1,200 | 30 | Refactor wins ($7K saving by month 36) |
| $5,000 | $3,000 | $2,000 | 18 | Refactor wins ($36K saving by month 36) |
| $10,000 | $5,500 | $4,500 | 8 | Refactor wins ($90K saving by month 36) |
| $25,000 | $12,500 | $12,500 | 3 | Refactor wins ($420K saving by month 36) |
The break-even pattern is clear. Refactor wins on high-run-rate workloads where the monthly saving is large enough to amortise the additional migration cost within the workload's expected lifetime. Replatform wins on low-run-rate workloads where the saving is too small to recoup the additional cost. The rough rule: refactor pays back at $3K per month of run cost or above; below that, replatform is the better choice.
The headline 30 to 50 percent run-rate reduction from refactor assumes the cloud-native architecture genuinely matches the workload pattern. When the architecture is forced (e.g. a monolithic batch processing job refactored to microservices because microservices is the architectural fashion), refactor can produce higher run-rate than even lift-and-shift. The two most common failure patterns:
First, microservices overhead. Splitting a monolith into 15 microservices adds inter-service communication overhead (typically 5 to 15 percent CPU and network cost on top of the previous monolith), observability tooling cost (distributed tracing, log aggregation, service mesh), and operational complexity (15 deployment pipelines instead of one). For workloads that genuinely benefit from the microservices model (independent scaling, independent deployment cycles, independent team ownership), the overhead is worth it. For workloads that are functionally a monolith with 15 service boundaries drawn arbitrarily, the overhead is pure cost.
Second, serverless overhead at sustained load. AWS Lambda, Azure Functions, and Google Cloud Functions are cost-effective for sporadic or burst workloads but expensive at sustained load. A function executing 24x7 at high concurrency costs materially more than equivalent EC2 or Azure VM capacity. Refactoring a continuously-running batch processing system to serverless functions often increases run-rate by 50 to 200 percent. Serverless wins on the workload pattern it was designed for (sporadic events, burst load); applied to the wrong pattern it loses badly.
A representative cost build for a 50-workload migration comparing three strategy mixes across the same workload set. The workloads include 10 high-traffic web applications, 10 databases, 15 batch processing jobs, 10 internal-tool servers, 5 legacy applications.
50-workload programme comparison across three strategy mixes
| Strategy mix | Migration cost | 3-year run cost | 3-year TCO |
|---|---|---|---|
| 100% rehost (lift-and-shift only) | $275,000 | $3,600,000 | $3,875,000 |
| 60% rehost, 30% replatform, 10% retire | $520,000 | $3,150,000 | $3,670,000 |
| 40% rehost, 35% replatform, 15% refactor, 10% retire | $1,180,000 | $2,650,000 | $3,830,000 |
| 30% rehost, 40% replatform, 25% refactor, 5% retire | $1,650,000 | $2,420,000 | $4,070,000 |
| 20% rehost, 30% replatform, 45% refactor, 5% retire | $2,800,000 | $2,250,000 | $5,050,000 |
The mixed strategy with 60% rehost, 30% replatform, and 10% retire produces the lowest 3-year TCO of the realistic mixes. Pure lift-and-shift is cheaper to migrate but more expensive to run; aggressive refactor produces lower run-rate but the additional migration cost does not pay back within 3 years for most workloads. The optimum strategy mix depends on the specific workload pattern, but for most mid-market estates the 60-30-10 mix produces the best 3-year economics.
The refactor versus replatform decision is one of the most consequential strategy choices in any cloud migration. The teams that produce on-budget, on-target outcomes are the ones that apply the break-even analysis honestly per workload, avoid forcing cloud-native architecture where it does not fit, and default to the simpler strategy where the economics are close. The most common failure mode is refactoring everything because cloud-native is the strategic direction; this typically produces 3-year TCO above pure lift-and-shift and operational complexity that the team cannot sustain.
A. Replatform makes targeted modifications to take advantage of cloud-managed services without redesigning the application. Examples: moving SQL Server to Azure SQL Managed Instance, moving a Tomcat web server to AWS Elastic Beanstalk, moving an on-premise web app to App Service. Refactor (or re-architect) rebuilds the application to be cloud-native, typically using microservices, serverless functions, containers, and event-driven patterns. Replatform preserves the application architecture; refactor replaces it.
A. Replatform typically costs $8K to $25K per workload upfront with a 10 to 20 percent run-rate reduction versus lift-and-shift. Refactor typically costs $25K to $80K+ per workload upfront with a 30 to 50 percent run-rate reduction versus lift-and-shift. The break-even on the additional migration cost versus the lower run-rate depends on workload run cost; for high-traffic workloads refactor pays back in 12 to 24 months; for low-traffic workloads it never pays back.
A. Refactor when the workload has high run-time cost (compute spend over $5K per month per workload), has an active development team that can maintain the cloud-native architecture, and is expected to live for 3+ years. Replatform when the workload has moderate run-time cost ($1K to $5K per month), has limited development capacity, or is expected to live 18 to 36 months. Lift-and-shift everything else.
A. Enterprise cloud migrations typically use a mixed strategy: 50 to 65 percent rehost (lift-and-shift), 20 to 30 percent replatform, 5 to 15 percent refactor, 5 to 15 percent retire. The refactor share is small because the cost per workload is high and the operational discipline required is significant. Most enterprises refactor a handful of strategic high-value workloads and replatform or lift-and-shift the rest.
A. Not always. Refactor produces a lower run-rate when the cloud-native architecture genuinely matches the workload pattern. Serverless functions for sporadic workloads. Container orchestration for elastic web apps. Managed databases for standard relational workloads. When the architecture is forced (e.g. monolithic batch jobs refactored to microservices because microservices is the architectural fashion), refactor can produce higher run-rate than even lift-and-shift due to inter-service communication overhead, observability tooling cost, and operational complexity.
A. Replatform takes 4 to 12 weeks per workload depending on complexity. Refactor takes 12 to 52 weeks per workload depending on complexity. The duration matters: refactor workloads in active migration cannot easily ship feature work, which adds opportunity cost on top of the direct refactor cost. Most enterprises stagger refactor across the migration programme rather than doing all refactor work in parallel.
Strategy cost tables ->
7Rs framework, per-workload
Lift-and-shift per server ->
$3K to $8K band
100-server worked scenario ->
Full mid-market reference
On-prem to AWS ->
MAP, EC2, Snowball
On-prem to Azure ->
Hybrid Benefit, FastTrack
On-prem to GCP ->
Sustained-use, BigQuery
10 hidden costs ->
Detailed playbook
ROI / break-even ->
Programme-level break-even
Updated 2 May 2026