Application Modernization Patterns & Approaches
The seven application modernization approaches are rehost, replatform, refactor, rearchitect, rebuild, replace, and retire. They run from least to most invasive, and choosing among them means matching each application to the lightest approach that solves its real problem — driven by the system's business value, technical health, and the pressure it is actually under, not by a preference for one approach across the whole estate.
Part 1 made one claim the rest of this series rests on: modernization is a spectrum, not a binary, and the work of strategy is choosing where on that spectrum each application belongs. This part makes the spectrum concrete. It names the seven approaches, explains what each actually changes, and gives you a way to decide between them that does not collapse into “rewrite everything” or “lift and shift everything.”
A note on scope. The seven approaches below are the same seven the industry calls the 7 Rs, and the legacy-modernization series already breaks them down in detail in The 7 Rs of Modernization Explained and the focused comparison Rehost vs Replatform vs Refactor vs Rebuild. This part will not re-derive each R from first principles — it links there for the deep treatment. What it adds is the strategy layer: how to choose, why the choice is per-application rather than per-estate, and how the approaches combine in a real program.
The seven approaches, least to most invasive
Ordered by how much they change about the application, from a change of address to a change of identity:
| Approach | What changes | What it solves | What it does not |
|---|---|---|---|
| Retire | The application stops existing | A system the business no longer needs | Nothing — it is the absence of work |
| Rehost | Where it runs | Platform problems: EOL hardware, data center exit | Changeability, architecture, code health |
| Replatform | The runtime/platform, lightly | Operational cost, handed off to a managed service | Core structure of the code |
| Replace | The whole application, for a product | Commodity functions a product does better | Anything truly differentiated to the business |
| Refactor | The code’s structure, not its behavior | Maintainability, testability, change speed | The architecture or the platform |
| Rearchitect | The structure, to enable new capability | Scale, decoupling, new things the old shape blocked | Is the most involved short of a rebuild |
| Rebuild | Everything, from the ground up | Cases where nothing salvageable remains | Anything cheaply — it is the costliest, riskiest option |
A few of these deserve emphasis because they are the most often misjudged.
Retire is an approach, not a non-answer. The cheapest modernization is the one you do not do because the application turned out to be dead weight. Every system you can switch off is cost and risk removed from the program entirely. A portfolio assessment that does not surface retirement candidates is not finished — which is the subject of Part 5.
Replace is underused. A surprising amount of custom software re-implements a commodity — a CMS, a ticketing system, a scheduler — that an off-the-shelf product now does better and cheaper. Replacing it frees the team to spend its rebuild budget on the systems that actually differentiate the business. The judgment call is honest scoping of “differentiated”: teams routinely overestimate how special their custom system is.
Rebuild is the option to be most suspicious of. It is the most expensive, the slowest, and structurally the most likely to fail, because it asks the business to wait the longest for value while betting on a single cutover. It is sometimes correct — when the existing system is genuinely unsalvageable — but it should be reached for last, not first. We treat the failure modes in why modernization projects fail.
The two axes that actually drive the choice
The mistake teams make is choosing an approach by preference — “we’re a cloud-native shop, so everything gets rearchitected” — rather than by fit. Fit is a function of two axes, and almost every reasonable decision falls out of plotting an application against them.
Axis one: business value. How much does this application matter to the business, now and over the planning horizon? A system that is central to the strategy and under active change pressure earns more investment than one that is peripheral and stable.
Axis two: technical health. How hard is this application to change safely today? A system with clean seams, usable tests, and supported dependencies is cheap to evolve; one that is entangled, untested, and built on dying runtimes is expensive to touch at all.
Plot the two and the approaches sort themselves:
- High value, poor health — the systems that hurt the most. These justify the heavier approaches: refactor, rearchitect, and occasionally rebuild. This is where modernization investment earns its highest return.
- High value, good health — keep investing in features; modernization is light or unnecessary. Do not fix what is not broken.
- Low value, poor health — strong candidates for retire or replace. Do not lovingly rebuild something the business barely uses.
- Low value, good health — leave it alone, or rehost it if the platform forces a move. The cheapest possible touch.
The point is that the same estate will sensibly use different approaches for different applications. A program that applies one approach uniformly is optimizing for tidiness, not for return.
Combining approaches within one application
The approaches are not even mutually exclusive within a single application. A large system is rarely all one thing. In practice a serious modernization sequences several approaches against different parts of the same application:
- Retire the dead modules nobody uses — found during discovery, removed before anything else.
- Replace the commodity sub-functions with products — authentication, reporting, document storage.
- Rearchitect the parts that genuinely differentiate the business and are under the most change pressure.
- Rehost or replatform what is left and stable, simply to get off the dying platform.
This is the difference between an approach and a strategy. An approach is a verb applied to a component; a strategy is the sequenced combination of approaches across an application and an estate, ordered so that the cheapest wins come first and the riskiest work is the smallest possible scope.
Why pace is a separate decision
It is worth repeating the point from Part 1 that the approach (what you change) and the pace (how you deliver it) are independent axes, because they get conflated constantly. You can deliver a rearchitecture incrementally or as a big bang; the approach does not dictate the pace.
The pace decision — covered in full in incremental vs. big-bang modernization — is where most of the risk lives, more than the approach choice itself. A rearchitecture delivered slice by slice behind a strangler facade, with each slice proven at a parity gate before it carries load, is a fundamentally different risk profile from the same rearchitecture delivered as a two-year big-bang cutover, even though the target architecture is identical. The approach sets the destination; the pace decides whether you arrive.
ModernLift’s position is that the heavier the approach, the more the pace matters: a rebuild delivered big-bang is the single most dangerous combination in the field, while the same ambition delivered slice by slice becomes a sequence of recoverable steps. Choose the approach for fit; choose the pace for survival.
What this framework can’t tell you
The two-axis framework is a way to think, not a formula that emits an answer. Two judgments inside it are genuinely hard and no chart resolves them. Business value over a multi-year horizon is a forecast, and forecasts about which systems will matter are often wrong — a peripheral system can become central when the strategy shifts. Technical health cannot be read accurately from the outside; an application that looks healthy can hide entanglement that only surfaces when you try to change it, and one that looks hopeless can have cleaner seams than expected.
This is exactly why a serious program does not pick approaches from a slide. It runs a discovery phase first — reading the actual code, data, and dependencies — so the two axes are measured rather than guessed. The framework tells you what questions to answer; discovery answers them with evidence. Choosing the approach before the evidence is in is how programs commit to a rebuild that a refactor would have served.
Where this leads
This part gave the series its vocabulary: seven approaches, two axes, and the principle that fit beats preference. The most common follow-on question is where all this overlaps with the cloud — because “modernization” and “cloud migration” are used almost interchangeably, and they are not the same thing. Part 3, Application Modernization vs Cloud Migration, draws the line: what each one actually changes, why moving to the cloud is not the same as modernizing, and how the two relate in a program that needs both.
Frequently asked questions
- What are the seven application modernization approaches?
- Rehost (move it as-is to new infrastructure), replatform (move to a managed platform with light changes), refactor (restructure the code without changing behavior), rearchitect (change the structure to enable new capability), rebuild (re-create on a modern architecture), replace (retire it for a commercial product), and retire (switch it off). They run from least to most invasive, and most real programs combine several across an estate.
- Which modernization approach is best?
- There is no single best approach — the right one depends on the application. The discipline is to match each system to the lightest approach that solves its actual problem rather than applying one approach across the whole estate. A high-value system under heavy change pressure may justify rearchitecting; a commodity function is often best replaced; a stable, low-value system may simply be rehosted or retired.
- Is rehosting real modernization?
- Rehosting changes where a system runs, not what it is, so on its own it does little for changeability — the code is just as hard to modify on new infrastructure. But it is real and often correct when the genuine problem is the platform: end-of-life hardware, an expiring data center contract, an unsupported runtime. The honest position is that rehosting solves a platform problem, not an architecture problem, and should not be sold as more than that.