Replatform, Refactor, or Rebuild: A Decision Framework for Application Modernization

Thesis: The 7Rs are a planning vocabulary, not a decision. For most applications, there are only three real choices: Keep, Lift-and-Shift, or Rewrite. Four measurable inputs decide which one fits: business criticality, change velocity, technical debt load, and runtime cost trajectory.

TL;DR for Technology Leaders

Most application modernization programs start with the wrong question. Buyers ask "should we refactor, replatform, or rebuild?" before deciding whether the application should change at all. The 7Rs taxonomy gives seven labels, but in practice only three program shapes get funded: Keep (Retain or Retire), Lift-and-Shift (Rehost, Replatform, Relocate, Repurchase at the infrastructure layer), or Rewrite (Refactor or Rebuild).

This framework chooses between those three using four inputs measurable from data your engineering organization already has: business criticality, change velocity (DORA Four Keys gap), technical debt load (five named signals), and runtime cost trajectory. The article closes with a decision matrix, a "when the framework breaks" section, and a worked scenario on a mid-size insurance claims platform.

Why "Modernization" Is the Wrong Question to Start With

Modernization is not a project type. It is a label buyers attach to budget once a decision has been made elsewhere, often on the wrong basis. The comparison most teams skip is against doing nothing: many applications run for another five years on their current stack with no business penalty. The cautionary point is that "modernization" framing assumes the answer before the question is well-formed, which is why so many programs miss their stated targets.

Three buyer framings recur, each with a predictable failure mode:

1. Replatform-all. Premise: "move everything to containers and managed services, and the rest will follow." Miss: platform plumbing does not change the shape of the application. A monolith on Kubernetes is still a monolith.
2. Lift-and-shift everything. Premise: "move first, then improve." Miss: shifts cost from capital to operating expenditure with no architectural change, then runs out of budget before phase two. Flexera's State of the Cloud surveys show buyers underestimate post-migration spend.
3. Rewrite-as-rescue. Premise: "the codebase is beyond saving; rebuild from a clean sheet." Miss: rewrites destroy domain logic encoded in the existing code. Multiple public commentaries on legacy modernization (including McKinsey and Standish CHAOS reporting) put large rewrite failure rates above half.

The framework starts from a different first question: what would have to be true about this application for any change to pay back? "Nothing" is Keep. "Small operational changes" is Lift-and-Shift. "Structural changes to how teams ship" is Rewrite.

The 7Rs Collapsed Into Three Real Decisions

The 7Rs framework (Retain, Retire, Rehost, Relocate, Replatform, Repurchase, Refactor, Rebuild) was popularized by AWS migration guidance and Gartner commentary on application portfolio rationalization. It is useful as a taxonomy but weak as a decision aid: seven options is too many for procurement, staffing, and budgeting. By the time a program reaches a steering committee, options collapse into three buckets that map to different team shapes, vendor profiles, and budget envelopes. The cautionary note: the three buckets are not interchangeable program plans; a team hired for Lift-and-Shift cannot run a Rewrite, and the budget cycle for a Rewrite is two to four times that of a Lift-and-Shift.

7Rs label	Three-bucket mapping	What changes	Typical program shape
Retain	Keep	Nothing (yet); planned re-evaluation in 12 to 18 months	Quarterly portfolio review
Retire	Keep (terminal)	Application is decommissioned; users migrate to alternatives	Wind-down project with sunset date
Rehost (lift-and-shift to IaaS)	Lift-and-Shift	Infrastructure layer; OS, network, storage	Migration squad, 6 to 12 months
Relocate (to managed hypervisor)	Lift-and-Shift	Hosting venue; very limited code change	Migration squad, 3 to 6 months
Replatform (lift-and-reshape)	Lift-and-Shift	Runtime substrate (containers, managed DB); minimal code change	Platform squad plus application owners, 9 to 18 months
Repurchase (drop and shop)	Keep (replaced) or Lift-and-Shift (integration program)	Application is replaced by SaaS; integrations rebuilt	Procurement-led with integration squad
Refactor / Re-architect	Rewrite	Application structure, deployment unit boundaries, data ownership	Multi-quarter program with dedicated team
Rebuild	Rewrite (terminal)	Everything; greenfield replacement of existing application	Multi-year program, high risk

Three options is the practical ceiling for a steering-committee working session. The 7Rs labels still matter once a bucket is chosen: they describe how the work is done.

Input 1: Business Criticality

Business criticality is the load-bearing input because it sets the cost of failure and the budget envelope. An application is highly critical when unavailability or incorrect output causes immediate revenue loss, regulatory exposure, or customer harm. Criticality changes slowly; it is set by the business model and the regulatory environment, not by engineering choices. Score on four sub-dimensions, each rated 1 to 4. Cautionary note: engineering-led scoring overstates criticality for systems engineers find interesting; pull the score from finance, legal, and customer operations.

Sub-dimension	1 (low)	4 (high)
Revenue dependency	No direct revenue impact within 30 days of outage	Direct revenue impact within hours of outage
Regulatory exposure	No regulated data; no audit requirement	Regulated data (financial, health, government); active audit cycle
User audience	Internal only; small user base	Customer-facing; external paying users
Recovery time tolerance	RTO measured in days; manual workaround viable	RTO measured in minutes; no viable manual workaround

Sum the four scores on a 4 to 16 scale: 12 to 16 is high, 8 to 11 is medium, 4 to 7 is low. High-criticality applications restrict the choice set; they tolerate Keep and well-governed Lift-and-Shift, but tolerate Rewrite only with explicit dual-running and rollback engineering, which raises program cost roughly two to three times relative to a low-criticality Rewrite of equivalent scope.

Input 2: Change Velocity

Change velocity is the rate at which the engineering organization ships changes to this application, measured against the rate the business needs. The standard signals come from the DORA Four Keys research at dora.dev: deploy frequency, lead time for changes, change-failure rate, and time to restore service. DORA metrics are extractable from version control, CI, and incident tooling, which makes them less prone to wishful reporting. Capture six months of data per application and compare to the business target. Cautionary note: DORA metrics describe team behavior on this codebase; a team can be high-performing on one application and low-performing on another in the same organization, and the reason is usually the codebase.

DORA metric	High velocity (target)	Low velocity (signal of trouble)
Deploy frequency	On-demand (multiple per day)	Monthly or less
Lead time for changes	Under one day	More than one month
Change-failure rate	0 to 15 percent	Above 30 percent
Time to restore service	Under one hour	More than one day

Velocity gap is the input that matters. Gap of zero or negative implies Keep. Gap closeable by removing operational toil (manual deployment, brittle tests, long CI queues) implies Lift-and-Shift. Gap requiring changes to module boundaries, data ownership, or deployment unit size implies Rewrite.

Input 3: Technical Debt Load

Technical debt load is the measurable cost the codebase imposes on every change. Compared to "code smell" or architecture-review opinion, debt load is observable from data the engineering organization already collects. Cautionary note: high debt load alone does not justify a Rewrite; with low criticality and zero velocity gap, debt is a sunk cost the business is paying willingly. Five signals carry most of the value. Track each as a trend over six to twelve months, not a single snapshot.

Signal	What to measure	Trouble threshold
Test coverage trend	Line or branch coverage on changed files, six-month moving average	Trending down for two or more quarters
Mean PR review time	Calendar time from PR open to merge, P50 and P90	P50 above three days; P90 above two weeks
Build and CI time	Wall-clock time for the full CI pipeline	Above thirty minutes for a typical PR
Incident MTTR	Mean time to restore service for production incidents tied to this application	Trending up year over year
Dependency age	Median age of third-party dependencies versus current major version	More than two major versions behind across more than 30 percent of dependencies

Three or more signals in the trouble column constitute high debt load. Two constitute medium. Zero or one constitutes low. The framework treats high debt load as a multiplier on whichever bucket gets chosen, not as a determining input on its own. Thresholds in these tables are calibrated against StackAuthority portfolio reviews; treat them as starting values, not industry constants.

Input 4: Runtime Cost Trajectory

Runtime cost trajectory is the direction of unit cost over time, not the absolute number. Compared to a TCO snapshot, trajectory tells you whether the application is on sustainable footing. Cautionary point: absolute cost is almost always defensible at any given moment; trajectory exposes whether the architecture bends the curve the wrong way as load grows. Track three measures over the trailing twelve months, normalized per unit of business work.

Measure	Calculation	Trouble threshold
Unit cost trajectory	$/transaction or $/user, month over month	Growing faster than transaction volume; net cost per unit rising
License trajectory	Annualized license and support spend on application-specific software	Compounding at more than 10 percent year over year with no usage growth
Infrastructure elasticity gap	Difference between peak provisioning and sustained P50 utilization	More than 3x over-provisioning that cannot be reduced without code change

Unit cost rising without a corresponding rise in business value signals that a Lift-and-Shift will buy only a quarter or two of relief. License trajectory growing on legacy commercial middleware often points to Repurchase or partial Rewrite. Elasticity gap rewards Lift-and-Shift to a managed runtime more directly than the other two measures, which is why elasticity often drives the strongest near-term return.

The Decision Matrix

The matrix maps the four inputs to one of the three buckets. It is not a substitute for judgment, but it forces the conversation onto the same axes across every application in the portfolio. Compared to a value-versus-fit grid (Gartner TIME), this matrix is denser because it carries through to a program shape, not just a category. The cautionary note: the matrix uses criticality and debt load as primary axes, with velocity and cost trajectory as modifiers, because criticality and debt load change least often.

Business criticality	Technical debt load: Low	Technical debt load: Medium	Technical debt load: High
Low (4-7)	Keep. No business case for change. Re-evaluate in 12 to 18 months.	Keep. Apply targeted Lift-and-Shift only if runtime cost trajectory is unfavorable.	Keep or Retire. If the application is on the way out, freeze the codebase and plan a sunset date.
Medium (8-11)	Keep. Address velocity gap with team-level changes (CI investment, test backfill) before touching the application.	Lift-and-Shift. Move to managed runtime; resolve elasticity gap; defer architecture change.	Lift-and-Shift, then Rewrite by service. Move first to stabilize cost, then begin extraction of the top one to three painful modules.
High (12-16)	Keep. Do not modernize for the sake of modernization. Tighten operational discipline.	Lift-and-Shift with strict rollback gates. High criticality limits aggressive change.	Rewrite, incrementally. Strangler-fig pattern with dual-running and named rollback gates. Plan multi-year.

Two modifiers apply. Change velocity gap: zero or negative argues against any change; a wide structural gap pushes toward Rewrite; a wide operational gap pulls toward Lift-and-Shift or Keep with team investment. Runtime cost trajectory: unit cost compounding upward shortens the window for Keep; license trajectory compounding upward biases toward Repurchase or modular Rewrite of the licensed portion.

When the Framework Breaks

The framework assumes the buyer has discretion over the application. Four common conditions remove that discretion. Compared to the matrix above, these situations require a different kind of decision because the inputs cannot move the answer. Cautionary point: pretending the framework applies here produces program plans that do not survive contact with reality.

1. Regulated workloads with frozen vendor stacks. Some regulated industries require a specific vendor stack for certified workloads (payment processing on certified HSMs, government workloads on FedRAMP-authorized environments). Rewrite requires a parallel re-certification pipeline that often doubles program duration.
2. Unbreakable third-party integrations. When the application is system-of-record for a third party with its own release schedule (a partner clearinghouse, a market data feed, a government filing system), changes must accommodate that party's cadence. Timelines stretch and rollback gates multiply.
3. Applications already scheduled for retirement. If the application is on a sunset path, the only sensible bucket is Keep until the sunset date, with frozen scope and security-only changes.
4. Mergers, acquisitions, and divestitures. The modernization decision is subordinate to the integration decision. Do not act on the framework's answer until the integration decision is settled.

If the application is a thin layer over a vendor SaaS product, the framework reduces to a Repurchase question and the four inputs do not move the answer.

Common Misconceptions

Three claims surface in nearly every modernization conversation. Each has a kernel of truth and a load-bearing wrong premise. Definitionally, a misconception is a claim that is true under conditions buyers usually do not check; comparatively, these three are worth flagging because they routinely cause budget to be misallocated; cautionary point: even sophisticated buyers repeat them.

Claim: Lift-and-shift always reduces cost. Reality: Public cloud lift-and-shift shifts cost from capital to operating expenditure and from fixed to variable, but does not automatically reduce total cost. Flexera's State of the Cloud survey reports waste in the 25 to 30 percent range. Lift-and-shift reduces cost only when (a) the source environment has high fixed cost that disappears, (b) the target is right-sized aggressively post-migration, and (c) the application has elasticity the source could not exploit. Many programs hit zero or one of the three.

Claim: Refactor is always cheaper than rebuild. Reality: Refactor is cheaper when the existing codebase carries correct, well-tested domain logic. When the codebase is opaque, undocumented, and undertested, refactor often costs as much as rebuild with worse outcomes, because the team is constrained by the existing structure. Sam Newman treats rebuild-versus-refactor as conditional on coupling, cohesion, and the existence of seams; assuming refactor is the safer default is a common error.

Claim: Cloud migration is modernization. Reality: Migration is a venue change. Modernization, as defined here, requires moving at least one input score. A migration that lands a monolith on managed compute with no structural change has not modernized. Calling migration "modernization" obscures whether the inputs actually moved, which makes the next budget conversation harder.

A Real-World Scenario: Mid-Size Insurance Claims Platform

A mid-size property and casualty insurer runs a claims platform on an eight-year-old Java monolith: about 600 KLOC, deployed as a single WAR to a commercial application server cluster, with an Oracle database. The platform handles roughly 25,000 first-notice-of-loss intakes per week and supports 1,400 internal adjusters and 240 external partners. Definitionally a high-criticality, high-debt application; comparatively, most insurers stumble on whether to lift-and-shift or rewrite first; the cautionary point is that doing either without scoring all four inputs costs an extra six to twelve months. Scoring:

• Business criticality. Revenue dependency: 3 (outage within 24 hours triggers regulatory notice). Regulatory exposure: 4 (state insurance regulators audit claims handling; SOC 2 applies). User audience: 4 (customer-facing through partners). Recovery time tolerance: 3 (RTO 4 hours; manual workaround degrades capacity to 30 percent). Total: 14. High criticality.
• Change velocity. Deploy frequency monthly; lead time 6 weeks P50; change-failure rate 22 percent; MTTR 3 hours P50. Business target: bi-weekly deploys with under one week lead time. Release sequencing, not CI, is the bottleneck. Velocity gap is structural.
• Technical debt load. Coverage down three quarters (54 to 47 percent on changed files); PR review 4 days P50, 17 days P90; CI 47 minutes; incident MTTR rising year over year; 38 percent of dependencies two or more majors behind. Five of five signals in trouble. High debt load.
• Runtime cost trajectory. Unit cost per claim up 14 percent year over year while volume grew 6 percent; license trajectory compounding at 9 percent annually with no negotiated relief; peak provisioning 4x sustained P50 with no horizontal scaling without code change. Trajectory is unfavorable.

Apply the matrix. High criticality plus high debt load lands in the "Rewrite, incrementally" cell. Structural velocity gap confirms the bucket. Unfavorable cost trajectory shortens the window for inaction but does not change the bucket; criticality is too high to risk a fast move. License trajectory argues for a modular Repurchase of the application server layer as a parallel track.

The recommended program is a strangler-fig decomposition over 24 to 36 months, with the first 6 to 12 months on the anti-corruption layer, traffic routing, and extraction of the two highest-pain modules (rules engine, partner integration gateway). The application server is replaced with a lightweight container runtime as part of the first module extraction. Dual-running and named rollback gates are mandatory at every module cutover. The companion Leading Application Modernization Partners ranking covers the vendor side. This is not an argument for a clean-sheet rebuild; at this criticality and scale, public research puts large-rewrite failure rates above 50 percent, and the eight years of domain logic in the codebase are themselves an asset.

Key Takeaways

1. The 7Rs are a planning vocabulary, not a decision. Three buckets (Keep, Lift-and-Shift, Rewrite) cover how budget actually moves; portfolio review should resolve to one.
2. Four measurable inputs decide the bucket: business criticality (4-16 rubric), change velocity (DORA Four Keys gap), technical debt load (five named signals), and runtime cost trajectory.
3. High business criticality limits the choice set. Rewrite at high criticality requires dual-running and named rollback gates, raising program cost two to three times relative to an equivalent low-criticality Rewrite.
4. Cloud migration is not modernization unless an input score moves. Lift-and-shift without a velocity, debt, or cost-trajectory improvement is a venue change and should be budgeted as one.
5. The "do not modernize" path is a first-class outcome. Low criticality plus any debt load defaults to Keep; high criticality plus low debt load defaults to Keep with operational tightening.
6. Re-run the framework on a 12 to 18 month cycle. Every input moves, and the right bucket can change without the application changing.
7. Procurement and vendor selection follow the bucket choice, not the other way around.

Further Reading

• Leading Application Modernization Service Providers (2026): the StackAuthority ranking of service partners against this framework's bucket choices.
• Leading AI Engineering Service Providers: companion ranking for the AI-engineering side of modernization programs that include AI components.
• Architecture-First AI Delivery: a complementary framework for sequencing design before code when AI is part of the target architecture.
• StackAuthority Methodology: how the four inputs were chosen and how the matrix is maintained.

References

• AWS Migration Strategies: the 7Rs. Public primary documentation. https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• Gartner public commentary on application portfolio rationalization and the TIME framework (Tolerate, Invest, Migrate, Eliminate). Public summaries of the published research.
• Martin Fowler. StranglerFigApplication. https://martinfowler.com/bliki/StranglerFigApplication.html
• McKinsey & Company. Published commentary on legacy modernization, failure rates, and program economics. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights
• Sam Newman. Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith. O'Reilly. Public author site at https://samnewman.io/books/monolith-to-microservices/.
• DORA research program. State of DevOps reports and the Four Keys metrics. https://dora.dev/
• ThoughtWorks Technology Radar. Public quarterly publication of practitioner guidance, including entries on monolith decomposition and microservices anti-patterns. https://www.thoughtworks.com/radar
• Microsoft Cloud Adoption Framework. Public migration patterns and the 7Rs mapping for Azure. https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/
• Flexera. State of the Cloud report. Annual public summary of cloud spend, waste, and migration patterns. https://www.flexera.com/about-us/press-center

About This Framework

StackAuthority's analysis of application modernization decisions across financial services, insurance, and public-sector buyers informed the four input definitions and the threshold values in the matrix. The framework draws on the Tier 1 sources listed in References and is reviewed every 90 days against new public research and reader feedback. No vendors were consulted in the development of the framework, and no vendor case studies were used as primary evidence.

The framework is intended for technology leaders making portfolio-level decisions about whether to modernize a given application, and if so, in which of the three program shapes. It is not a substitute for vendor due diligence; the companion Application Modernization Buying Guide and the Leading Application Modernization Partners ranking cover the vendor and contracting decisions that follow the bucket choice. Corrections and questions can be sent through the Contact page. The author's profile and prior writing are available at Mira Voss. For broader editorial standards, see the Methodology and About pages.