Skip to content
NDABefore code accessIPAssigned to youTermsMonth to monthExitNo penalty
Talk To An Engineer
Comparison Guide

Rehost vs Refactor vs Rebuild

Rehosting moves the system. Refactoring improves it in place. Rebuilding replaces it. Each strategy fixes a different problem, and most estates need more than one.

Talk To An Architect

The Three Strategies Defined

  • Rehost

    Move the application to new infrastructure with little or no code change. Often called lift and shift. The code, its structure and its problems arrive unchanged.

    • Changes: where it runs
    • Keeps: code and architecture

  • Refactor

    Restructure the existing code and architecture in steps while the system stays in use. Behaviour is preserved. Tests guard each change.

    • Changes: internal structure
    • Keeps: behaviour and most business logic

  • Rebuild

    Write a new system that covers the same scope, usually on a new stack. The old system keeps running until the new one can take over.

    • Changes: nearly everything
    • Keeps: the requirements

Decision Matrix

Apply the matrix to one application at a time, not to the whole estate.

SituationRehostRefactorRebuild
Hardware or data centre contract is endingBest fit: fastest way offToo slow alone. Rehost firstToo slow alone. Rehost first
Code is sound but hard to changeDoes not helpBest fitMore than needed
Language or framework is no longer supportedBuys time onlyFits if an upgrade path existsBest fit if no upgrade path exists
No automated tests existFits: code is untouchedAdd tests first, then refactorFits, but behaviour must be rediscovered
Business rules are poorly documentedFitsBest fit: rules stay in the codeRisky: rules are easy to miss
Requirements have changed a great dealDoes not helpFits for partial changeBest fit
Application is small and low riskFitsFitsFits: cost of a rebuild is contained

Side-By-Side Comparison

RehostRefactorRebuild
Cost shapeLow up front. Running cost may rise or fallSteady spend over a longer periodHigh up front, plus running two systems
Main riskOld problems move with the systemWork stalls part way and leaves two styles of codeMissed requirements and a late or failed cutover
SpeedFastest to completeValue arrives in stepsSlowest to first value
Team impactMostly infrastructure and operationsDevelopers need deep knowledge of the current codeTeam is split between old and new systems
ReversibilityHigh: the old environment can be kept for a periodHigh: each step is small and can be rolled backLow after cutover

Whether rehosting reduces running cost depends on the workload and how it is sized. It is not automatic.

Hidden Risks In Each Strategy

  • Rehost: the bill does not drop

    An application designed for fixed servers may run inefficiently on rented infrastructure. Size and measure before you assume a saving.

  • Refactor: no clear finish

    Without defined goals, refactoring continues without end. Set a target state and a way to tell when you have reached it.

  • Rebuild: the moving target

    The old system keeps changing while the new one is built. The new system must catch up with a target that does not stand still.

  • All three: data migration

    Moving and validating data is often the hardest part. Plan it early and rehearse it, whichever strategy you choose.

A Phased Way To Decide And Act

  1. 1
    Phase 1

    Inventory

    List each application, its dependencies, its owner and its business value.

  2. 2
    Phase 2

    Assess

    Rate each application for code health, test coverage, platform support and rate of change.

  3. 3
    Phase 3

    Assign a strategy

    Choose rehost, refactor, rebuild or leave alone, one application at a time.

  4. 4
    Phase 4

    Pilot

    Start with one low-risk application. Prove the process and the rollback.

  5. 5
    Phase 5

    Roll out

    Proceed in order of risk and value. Review the plan after each move.

Two Anonymised Scenarios

Both scenarios are invented illustrations. They are not client stories.

  • Scenario A

    A hosting deadline and healthy code

    Imagine a company whose hosting contract is ending. The application works and the code is in reasonable shape. Rehosting fits as the first move. It meets the deadline. Refactoring can follow once the pressure is off.

    • Deadline is fixed
    • Code is not the problem
    • Improvement comes second
  • Scenario B

    An unsupported framework with no upgrade path

    Imagine a company with an internal tool built on a framework that no longer receives updates. There is no supported upgrade route. A rebuild fits, done in stages. The team documents the current behaviour first, so that rules are not lost.

    • Platform has no future
    • Behaviour documented before work starts
    • Cutover is staged

Recommended Next Step: Resilience Audit

We review your applications with your team and discuss a strategy for each one. Leaving an application alone is a valid result.

Talk To An ArchitectTake The Risk Assessment

Related Insights

View All Articles

Frequently Asked Questions

Have More Questions?

No. Replatforming makes limited changes, such as moving to a managed database, without restructuring the code. You can also replace an application with a bought product, retire it or leave it as it is. This guide covers the three that involve the most engineering work.

Yes. This is a common sequence. Rehosting meets an infrastructure deadline. Refactoring then happens in the new environment at a pace the team can sustain.

When the platform has no supported future, when requirements have changed so much that little of the old design applies, or when the application is small enough that the risk is contained.

Often, yes. Changes are made in small steps behind tests and released through the normal process. Some changes, particularly to data structures, need careful sequencing. No approach removes all risk.

They join your team and work in your repository and tools. You interview each developer before any contract. You own all code and IP.