Rehost, Replatform or Refactor: How to Choose

Reviewed by the DESSS engineering team

Choosing rehost vs replatform vs refactor is a question of how much of the problem sits in your infrastructure and how much sits in the code itself. Rehosting moves the software unchanged, replatforming adjusts a few parts to use better services, and refactoring reshapes the code while keeping its behavior. Getting this right matters more than the choice of cloud vendor. For the wider decision about what to build or keep, see our application development consulting overview. Here, we focus on how to choose between the options, one application at a time.

Start With the Actual Problem

Modernization projects go wrong when "the system is old" is treated as the problem. Age alone costs nothing. Ask what is actually hurting.

• The data center lease is ending or the hardware is failing. That is an infrastructure problem.
• The operating system or database is falling out of support. That is a platform problem.
• Every small change takes too long and breaks something else. That is a code problem.
• The business has moved on, and the data model no longer fits. That is a design problem.
• A commercial product now does the same job well. That is a sourcing question.

Each of these points to a different route, and many applications have more than one of them. Write down the top two before comparing options, because they become your test for whether the money was well spent.

The Options Explained

Rehost

Rehosting, often called lift and shift, moves the application to new infrastructure with little or no code change. Virtual machines in a data center become virtual machines in a cloud, for instance.

It is the least disruptive move and suits deadlines driven by a lease or hardware failure. You gain better recovery options and can stop running physical servers. You do not fix slow code, tight coupling or an unsupported runtime, and cloud bills can disappoint when servers sized for peak load keep running around the clock.

Replatform

Replatforming makes targeted changes so the application can use better underlying services without changing its overall design. Typical examples include moving a self-managed database to a managed service, moving a runtime to a supported version or packaging the application in containers.

This route often gives the best return for applications that work well but sit on tired foundations. Expect some code changes and a full regression test, because a new database engine or runtime version can change behavior in small, surprising ways.

Refactor

Refactoring restructures code while preserving what it does. You might separate a business rule into its own module, add automated tests or split one part of a large application into a service.

It suits software whose rules are valuable but whose code has become difficult to change. Refactoring rarely impresses users in the short term, and it can be hard to fund for that reason. Tie it to something visible, such as the backlog item that keeps being delayed because nobody dares touch that module.

What about rebuild and replace?

Two more options sit beyond these. Rebuilding writes the application again on a new foundation, and it is justified when the data model or technology genuinely blocks where the business is heading. Replacing retires the software in favor of a product. Keep both on your comparison, since they are sometimes the honest answer, but test them against the same problem statement.

Comparing the Routes

How to Choose for Each Application

Treat a portfolio as a collection of separate decisions. Your payroll interface and your customer portal do not need the same answer.

Score business value and technical health

Plot each application on two simple scales: how much the business depends on it and how healthy it is technically. High value with poor health deserves investment. Low value with poor health may simply be retired. High value with good health should mostly be left alone.

Check the dependencies

Applications rarely stand alone. Trace what reads from each database, which reports rely on it and which file drops other systems expect. Moving one application without its neighbors can introduce latency or break a nightly job nobody remembered.

Find out what you can actually test

A route that depends on behavior staying the same requires a way to prove that it did. If no tests exist, capture how the current system behaves before changing anything: sample outputs, reports and calculations you can compare later. This step feels slow, yet it prevents the arguments that come later about whether a difference is a bug.

Consider moving in stages

The strangler pattern replaces parts of a system gradually, routing selected functions to new components while the old system keeps handling everything else. It reduces the risk of a single big cutover, although running two systems side by side adds work for a while. Combining routes is common too: rehost now to meet a deadline, then replatform the database, then refactor the worst module.

A Word on Vendor Deadlines

End-of-support dates often trigger these projects, and they deserve a calm reading. Paid extended support programs may exist, and isolating a system can reduce exposure, but neither one fixes the underlying issue. Treat the date as a planning input, then check your vendor's lifecycle page directly instead of relying on a secondhand summary.

Pre-Decision Checklist

Complete this for each application before approving a route.

• ☐ The top two problems are written down in business terms
• ☐ An owner has been named on both the business and IT sides
• ☐ Source code is available and matches what runs in production
• ☐ Dependencies, reports and scheduled jobs are listed
• ☐ Backups have been restored successfully in a test environment
• ☐ Current behavior has been captured for later comparison
• ☐ Vendor support dates have been checked on the vendor's own site
• ☐ Rebuild and replace were considered and rejected for stated reasons
• ☐ A rollback plan exists for every stage of the move
• ☐ Someone has defined how you will know the project worked

If you want help carrying out the plan once it is settled, our application modernization services page describes how we deliver this work.

Frequently Asked Questions

What is the difference between rehosting and replatforming?

Rehosting moves an application to new infrastructure with essentially no code changes. Replatforming goes one step further by changing a specific layer, such as adopting a managed database or a newer runtime, while leaving the overall design alone. Rehosting is usually quicker to carry out. Replatforming requires more testing, though it tends to deliver more operational benefit afterward.

Is lift and shift a bad idea?

No. It is often the sensible answer when a deadline, such as a lease or failing hardware, drives the move. Problems arise when people expect it to solve slow code or high running costs. Treat it as a first stage, size servers based on actual use, and plan what you will improve once the application is safely running in its new home.

When is refactoring worth the money?

Refactoring pays when a valuable application changes often and each change is slow or risky. If the software rarely needs updates, the benefit is small. Start with the module causing the most trouble, add tests around it and measure whether changes become easier. That evidence makes the next round much easier to justify to people holding the budget.

Can we modernize without moving to the cloud?

Yes. Modernization describes improving an application, and the cloud is only one possible destination. You can upgrade runtimes, refactor code and add APIs while staying on your own servers, which may suit data rules or plant-floor systems. Decide based on your problem, then choose hosting. Cloud should follow from those needs instead of being the goal in itself.

Not Sure Which Route Fits?

Contact DESSS with the application's name, what it runs on and what is hurting. We can review the code and dependencies and give you a written recommendation you can use with or without us.