Rewrite, Refactor, or Replatform: An Evidence-Based Model for Inherited Software

A rewrite is a business migration decision, not a verdict on whether the code looks modern. Refactor when valuable behavior can be improved behind controlled boundaries. Replatform when the runtime or operating platform is the main constraint and the application's behavior can largely remain stable. Rebuild only when the required business and operating model is incompatible with the existing system and a staged replacement is better supported by evidence than the alternatives.

No universal score can make that decision for you. The model below uses seven factors to expose the evidence, constraints and unknowns behind it. It can return stabilize, incremental refactor, replatform or staged modernization, parallel replacement, or assess first. That last result is deliberate: an unknown production baseline or migration path must not be averaged into false confidence.

Download the rewrite, refactor or replatform decision worksheet to record the evidence, confidence, hard blockers and reversible first step without uploading repository, customer or commercial data.

What this model is—and what it is not

This is a transparent H Product Studio decision aid. It is not an industry standard, a valuation method or a calculator that turns seven answers into a mandatory architecture.

That distinction matters because modernization choices combine competing objectives. The Carnegie Mellon Software Engineering Institute's Architecture Tradeoff Analysis Method evaluates architecture relative to business drivers and quality attributes such as modifiability, security, performance and availability. Improving one can change another. A system can be structurally awkward yet operationally dependable; a cleaner target architecture can still create unacceptable migration and cutover risk.

AWS likewise frames modernization readiness across business, functional, technical and financial significance. Its assessment questions include interfaces, dependent applications, databases, batch jobs, security, recovery objectives and operations—not just source code.

The score here therefore does two jobs only:

1. make the current evidence visible; and
2. show which option deserves a bounded proof next.

It does not approve production work. It does not replace a system-specific estimate, data migration design, security review or accountable business decision.

Before scoring: establish a trustworthy baseline

Do not score a folder that may not match production. A received repository, a running container, an infrastructure dashboard and a database migration folder can each describe a different release.

For inherited production software, first map:

authoritative source revision → build definition → immutable artifact → deployment record → running workload → runtime configuration schema → migration state → observed business behavior

SLSA provenance describes provenance as verifiable information about where, when and how an artifact was produced, including the source used by the build. The model does not require a particular SLSA level, but it does require the same basic question: can the team trace what customers use back to controlled source and repeatable production operations?

Before choosing a modernization path, collect at least:

• the current business objective and the capability that must change;
• critical customer, revenue, access, data and operational flows;
• canonical source, infrastructure and migration repositories;
• production revision or artifact identity and deployment path;
• data stores, queues, object storage, jobs, integrations and manual operations;
• recovery expectations and actual restore or redeploy evidence;
• owners for product, data, infrastructure, security, release and cutover decisions;
• current incidents, unsupported components, vendor constraints and contractual deadlines;
• a representative cost baseline for infrastructure, providers, support and unplanned work.

If the system was only recently inherited, complete the 30-day software project takeover checklist before using this model as a budget decision. If the assessment is happening before an acquisition, the small-SaaS technical due diligence guide adds rights, supplier, customer-promise and transaction evidence that this modernization model does not decide.

How to record each factor

Use four states:

Every state needs an evidence link or location, an owner and a confidence note. U is not zero. A zero says you looked and found a problem; U says the decision lacks a fact that may change the recommendation.

Do not total the numbers into a rewrite threshold. Keep the seven-position evidence profile—for example 2 / 1 / U / 0 / 1 / 2 / U—and read it together with the hard blockers and option profiles below. The vector shows where uncertainty and constraint live; a total would hide that information.

Factor 1: Critical behavior evidence

Question: Can the team prove what must continue to work while the system changes?

Score the evidence for business behavior, not a repository-wide coverage percentage.

• 2: Critical flows have reliable automated checks or repeatable characterization tests, production observations and named business acceptance criteria. Failures and edge conditions are represented.
• 1: Main flows are understood, but evidence is partial, brittle or dependent on manual verification.
• 0: Known critical behavior cannot be reproduced or verified, or existing checks routinely pass invalid outcomes.
• U: Nobody can state which behavior is authoritative, and production/support evidence has not been reconciled.

An inherited system with weak tests can still be refactored, but not by pretending the risk is absent. The first modernization slice may be characterization: capture current behavior, reconcile it with product policy, and add checks around the seam before changing it.

Do not preserve every legacy quirk automatically. Classify observed behavior as required, accepted temporarily, defect to correct, or unknown. Otherwise a rebuild can reproduce years of accidental behavior, while a refactor can silently remove a rule the business still depends on.

Factor 2: Coupling and replaceable boundaries

Question: Can one business capability change without an uncontrolled cascade?

File counts are a weak proxy. A change touching many generated files may be safe; a one-line change to shared state can have a wide blast radius. Trace runtime and data dependencies instead.

• 2: Boundaries, interfaces, ownership and shared data are explicit enough to isolate and verify a bounded component.
• 1: Useful seams exist, but cross-module calls, shared tables or duplicated rules require preparatory work.
• 0: The selected capability cannot change without uncontrolled changes across critical flows or data ownership.
• U: Static structure is visible, but runtime calls, jobs, consumers or shared-data behavior are not mapped.

When the score is one, the right first step is often to create a seam rather than replace a service. Put an interface around a provider, isolate a rule, route one read path through a stable contract, or introduce observability that proves which consumers exist.

A low score does not automatically favor a rewrite. It may mean the organization cannot yet divide the problem into independently deliverable units. A blank-page system still needs boundaries, and it inherits the same integration and data realities at cutover.

Factor 3: Knowledge, custody and change authority

Question: Can the current team independently build, release, diagnose and recover the system?

Repository contributor history can help identify where to interview, but commit counts are not a bus-factor verdict. Squash merges, bots, renamed authors, generated files and work outside Git distort the result. Use history to select capability tests, then verify the capabilities directly.

• 2: Client-controlled source and provider ownership are established; more than one qualified person can explain critical flows and perform a documented release and recovery exercise.
• 1: Control exists, but runbooks, recovery identities or key operational knowledge remain concentrated.
• 0: A departing person or supplier controls a critical account, deploy, migration or recovery capability.
• U: Source-to-production parity, owners or change authority have not been verified.

A zero or critical unknown usually means stabilize the takeover first. Starting a rewrite while the current system cannot be released or recovered creates two systems without a trustworthy operational baseline.

Factor 4: Platform and dependency viability

Question: Can the current runtime, framework, database and provider set be supported through the decision horizon?

Inventory the exact runtime versions, lockfiles, operating systems, managed services, libraries, extensions and vendor contracts. Then verify support horizons, security response, upgrade paths, platform limits and available skills using the official documentation for those exact versions.

• 2: The platform is supported through the planning horizon, with repeatable upgrades and known provider constraints.
• 1: Support remains available, but deferred upgrades, abandoned components, licensing or vendor limits create a dated constraint.
• 0: A critical component is unsupported or cannot meet a required security, reliability, scale or operating constraint, and no bounded upgrade path is viable.
• U: The dependency/runtime inventory or production versions are incomplete.

Run ecosystem-specific analysis only in an isolated, authorized environment after package and lifecycle scripts are reviewed. A generic scanner command is not a modernization strategy, and zero reported findings do not prove supportability.

This factor is the clearest signal for replatforming when application behavior remains useful but the runtime or operating model is the main problem. Microsoft's 6 Rs guidance distinguishes replatforming—moving to a new runtime platform with limited code changes—from refactoring, which changes existing code without a major external behavior change, and rebuilding, which starts over.

Factor 5: Data and migration risk

Question: Can data remain correct, available, secure and explainable through the transition?

Data risk is not “does the schema look normalized?” A mature but unusual schema may encode valuable business rules. A clean target schema can still lose history, change rounding, duplicate events or break downstream consumers.

• 2: Critical datasets have defined owners, grain, quality rules and consumers; migration/coexistence can be reconciled; rollback and retention behavior are explicit.
• 1: The model broadly fits, but quality gaps, shared ownership, backfills or compatibility work require a controlled migration stage.
• 0: Current data semantics are incompatible with the required business model, or a proposed path cannot preserve and reconcile material records.
• U: Stores, jobs, consumers, quality, retention or restore behavior are incomplete or contradictory.

Treat application replacement and data migration as related but separate programs. For each dataset define the authoritative side, cutover unit, transformation version, validation totals, exception queue, rollback boundary and post-cutover reconciliation.

Do not assume that letting old and new applications write the same schema makes replatforming safe. Shared writes can preserve hidden coupling, create incompatible assumptions and make rollback ambiguous. Explicit ownership and compatibility rules are required whether the data stays in place, moves once, dual-writes temporarily or synchronizes through change events.

Factor 6: Business-change pressure and strategic fit

Question: Can the current system shape support the workflows and operating model the business actually needs?

Separate urgent commercial pressure from architectural evidence.

• 2: The system's concepts and boundaries support the required roadmap with contained change.
• 1: Delivery is expensive or slow, but targeted modernization can unlock the next material capability.
• 0: Required workflows, scale, product boundaries or operating responsibilities conflict with foundational assumptions in the current system.
• U: The target capability, success criteria, volume or decision horizon is not defined.

A stable product with low change demand may need maintenance, but “frozen” does not excuse unsupported software, missing recovery or security exposure. Conversely, a volatile roadmap does not automatically justify a rebuild. Requirements moving quickly can make a long parity program obsolete before cutover.

Write the business driver as a scenario: when a named event happens, which user or operator must do what, at what scale, with which measurable response and acceptable failure. That creates something architecture options can be evaluated against.

Factor 7: Disruption and dual-operation capacity

Question: Can the organization absorb the transition as well as build the target?

Include more than implementation labor:

• parallel infrastructure and provider spend;

• duplicate feature work and requirement drift;

• data synchronization and reconciliation;

• customer migration and support;

• operator training and temporary manual processes;

• security review, testing and observability;

• freeze, cutover, rollback and hypercare;

• decommissioning old jobs, access, data, contracts and infrastructure.

• 2: The organization can fund, staff and observe the transition; the cutover unit is bounded and reversible.

• 1: The path is feasible, but dual-running, support capacity or downtime constraints require staged scope.

• 0: The proposed transition exceeds acceptable outage, data-loss, staffing or operating limits.

• U: The blast radius, RTO/RPO, consumers, support load or cutover authority is unknown.

High blast radius does not make every rebuild wrong. It raises the proof required before any cutover and usually favors smaller migration units, coexistence and reconciliation. NIST contingency guidance starts recovery priorities from business impact; modernization should use the same discipline rather than assuming a technically successful deployment restores the business function.

Hard blockers: when the result must be “assess first”

Stop before recommending an option if any of these are material and unresolved:

• authoritative production source or deployed artifact provenance is unknown;
• critical business behavior has no trustworthy specification or observation;
• material data stores, jobs or downstream consumers are missing from the inventory;
• deploy, rollback or recovery depends on an unavailable person or supplier;
• target business capability and acceptance criteria are undefined;
• no owner can authorize, observe, stop and reconcile the transition.

“Assess first” is not indecision. It is a bounded result with an evidence backlog. Name the missing claim, the least risky way to verify it, the owner and the decision it can change.

Read the profile: four possible paths

1. Stabilize and maintain

Choose this profile when current business behavior remains fit and structural risks are bounded, but ownership, release safety, monitoring, recovery or support need repair.

The first proof is operational: establish source-to-production parity, make one representative build, test recovery, close critical access gaps and deliver a small reversible release. Stabilization is not a promise to keep every component forever. It creates the control needed to choose later work honestly.

2. Incremental refactor

Choose this profile when valuable external behavior should remain, constraints are concentrated in code or bounded modules, and seams can be created without moving the whole operating platform.

The first proof is one component with explicit before/after behavior, a controlled route, observability, rollback and a deletion condition. “The old path is no longer reachable and its data/jobs are reconciled” is a completion criterion; “the new service is running” is not.

3. Replatform or staged modernization

Choose this profile when runtime support, hosting, database operations or platform constraints are the primary limiter and application behavior can remain substantially stable.

Replatforming may include configuration and limited code changes, but it should not be used as a harmless label for an unpriced architecture and data rewrite. The first proof is one workload or interface on the target platform with compatibility, performance, cost, recovery and rollback evidence.

4. Parallel replacement or rebuild

Choose this profile only when the required business/operating model is incompatible with foundational assumptions in the current system and evidence shows that bounded refactoring or replatforming would be less viable.

The commitment is not “build the new application.” It is a migration program: behavior scope, data conversion, coexistence, customer and operator transition, feature divergence, cutover, rollback, reconciliation and decommissioning. For a live, high-impact system, the implementation can still be incremental even when the destination is a full replacement.

The Strangler Fig pattern is one possible mechanism: a façade routes behavior between old and new implementations while responsibilities move in stages. Microsoft explicitly notes the transitional infrastructure, shared-resource, cross-system dependency and data-store considerations. Use the pattern when a stable interception point and separable capabilities exist—not as a slogan applied after the rewrite decision.

The AI rewrite trap

AI-assisted development can make a new implementation appear quickly. That changes the cost of some coding, documentation and mechanical transformation tasks. It does not remove the work of discovering behavior, deciding what should change, proving rights and data handling, migrating live records, operating two paths or reconciling a cutover.

The official 2025 DORA report describes AI as an amplifier of the surrounding organization: it magnifies strengths and weaknesses. DORA's current capability guidance still emphasizes reliable tests, version control, small batches, continuous delivery and fast feedback. Those controls matter more when code can be generated faster.

Use AI where the output can be bounded and independently checked:

• summarize unfamiliar modules and identify questions for a human owner;
• draft characterization tests for reviewed critical behavior;
• map dependency candidates for confirmation with runtime evidence;
• propose mechanical transformations against a versioned rule;
• compare documented interfaces and migration manifests;
• draft runbook or decision-record sections from verified evidence.

Do not let AI assign the final factor state from a repository alone. It cannot observe unwritten customer promises, support history, manual operations, production-only changes or the business's tolerance for disruption unless those facts are supplied and verified.

Compare cost of delay with transition cost

Avoid both extremes: “technical debt is expensive” without measurement and a rewrite estimate that excludes coexistence.

Build two transparent views over the same decision horizon.

Current-state cost:

• incident and unplanned-work hours at loaded cost;
• support and manual-operation effort;
• provider, infrastructure and licensing cost by meaningful unit;
• delivery delay attributable to evidenced constraints;
• expired support, renewal and security mitigation work;
• probability-weighted exposure only where the probability, impact and owner are stated.

Transition cost:

• discovery and behavior characterization;
• implementation and platform work;
• data migration and reconciliation;
• dual operation and duplicated roadmap work;
• customer/operator migration and support;
• security, testing, observability, cutover and hypercare;
• decommissioning and residual retention obligations.

The FinOps Foundation's Unit Economics guidance recommends documenting how technology cost relates to a business unit or outcome and preserving definitions, assumptions and data sources. Use a unit that reflects this product—per tenant, transaction, case, report or another business outcome—rather than forcing a generic cloud-cost ratio.

Do not publish a payback claim until both views use the same scope, time horizon and confidence. Unknowns should appear as ranges or decision blockers, not hidden contingency.

Write the one-page decision record

The decision should survive beyond the person who proposed it. Record:

1. business capability and decision horizon;
2. exact system/release baseline;
3. seven factor states with evidence and confidence;
4. hard blockers and unavailable checks;
5. selected path and why it fits the evidence;
6. rejected paths and the facts that would reopen them;
7. transition cost categories and cost-of-delay baseline;
8. first reversible slice, acceptance and rollback criteria;
9. owner, review date and next decision gate.

The downloadable worksheet contains this structure. Keep secrets, production data, customer records and confidential commercial figures in the approved evidence system—not in the worksheet or an external AI tool.

FAQ

What total score means we should rewrite?

None. The seven values are an evidence profile, not a universal threshold. A low platform score with strong behavior and data evidence can favor replatforming; the same total with an unknown data model may require assessment first. Hard blockers and the location of each constraint matter more than the sum.

Does an unsupported runtime force a full rewrite?

It creates a dated risk that needs an owner and action. The response may be a version upgrade, replatform, bounded replacement or rebuild depending on compatibility, business fit, data and operating constraints. Unsupported software should not be left indefinitely because change demand is low.

Can the old and new applications use the same database during migration?

Sometimes, but shared access is not automatically safe. Define data ownership, compatible reads/writes, schema-change order, concurrency behavior, reconciliation and rollback. Direct shared writes can preserve the coupling the migration was meant to remove.

How long will the decision take?

Enough time to establish evidence for the selected scope. A bounded system with verified source, current documentation and tested recovery may be assessed quickly; an unknown production baseline, extensive integrations or live-data migration requires more work. Give an estimate only after the evidence request and critical flows are defined.

Is a full rebuild ever the right answer?

Yes. It becomes credible when the required operating model conflicts with foundational system assumptions, critical behavior and data are sufficiently understood, and the migration evidence shows bounded refactor or replatform paths are worse. The delivery can still use staged, reversible slices rather than one big-bang cutover.

Can AI perform the assessment?

AI can accelerate repository reading, draft tests and documentation, and help organize evidence. An accountable team must still verify production behavior, business intent, data, provider constraints, migration safety and the final decision.

Choose the next proof, not the most exciting architecture

If the result is ASSESS FIRST, establish the missing baseline. If the profile supports maintenance, restore operational control. If it supports refactoring or replatforming, prove one bounded slice with rollback. If replacement is credible, prove migration and coexistence before funding parity as a single promise.

H Product Studio's Application Modernization service starts with that evidence and sequences the work while the existing system continues to serve the business. For an unstable handover or missing production control, begin with Software Project Takeover. For a stable product that mainly needs ongoing releases and support, Application Maintenance may be the better first engagement.

Discuss your inherited system →