Choosing Among the 7Rs and Where to Modernize

Goal

The previous section explained how to sequence migration work. This section explains how to choose the path each application should take inside that sequence.

The Short Version

The right migration strategy is rarely one answer for the whole estate. Each application earns its path based on business value, technical friction, and future fit.

Faster move -------------------------------------- Deeper change
Retain | Retire | Rehost | Relocate | Replatform | Repurchase | Refactor

That line is a simplification, not a scorecard. The 7Rs are decision paths, not maturity rankings.

What The 7Rs Are For

The 7Rs help teams avoid two bad habits:

forcing one migration pattern onto every workload for consistency, and
treating the most technically ambitious answer as automatically the best answer.

Each application should be judged against questions such as:

Does this workload still matter to the business?
Does it need to move quickly, or is there time to redesign?
Is the current platform a cost, support, or resilience problem?
Can the team safely change the application now?
Would replacement be cheaper than keeping a custom solution?
Is the application already hosted on a virtualization platform that supports a different relocation path?

A Practical Reading Of The 7Rs

Path	Practical Meaning	Often Chosen When
Retain	Keep it where it is for now.	A dependency, regulatory constraint, contract, or timing issue makes movement unwise.
Retire	Remove it instead of migrating it.	The workload is redundant, unused, or replaceable by a simpler process.
Rehost	Move it with minimal application change.	Speed matters and the fastest safe move is more valuable than early redesign.
Relocate	Move the environment with very limited change, often at the virtualization layer.	The current stack supports a relocation pattern and the goal is quick platform exit.
Replatform	Make targeted platform changes without rewriting the core application.	The team wants operational improvement without full redesign.
Repurchase	Replace the application with a SaaS or packaged alternative.	Custom ownership is not worth the long-term cost.
Refactor	Redesign or rewrite meaningful parts of the application.	Business value is high and deeper change materially improves agility, scale, or resilience.

Do not memorize the table as theory. Use it as a portfolio conversation tool.

Rehost Is Not Automatically A Weak Answer

Rehost often gets dismissed because it does not sound modern enough. That is a mistake.

If the organization must exit a data center quickly, reduce hardware risk, or stabilize a fragile estate before deeper change, rehost can be the strongest answer. It buys time, reduces immediate risk, and creates a cleaner place from which to observe real workload behavior.

What makes rehost weak is not the label itself. It becomes weak when the organization pretends the first move solved deeper problems that it actually postponed.

Replatform When The Platform Friction Is Clear

Replatform usually makes sense when the core application still works, but its surrounding operational model is the problem.

Examples:

Moving a self-managed database to a managed database service.
Moving a web tier into containers while keeping most business logic intact.
Replacing custom backup or logging scripts with platform-native patterns.
Simplifying session handling, deployment, or scaling without rewriting the domain model.

This path often delivers a strong middle ground: better operations and lower platform burden without the cost and schedule risk of refactoring everything at once.

Refactor Only Where The Payoff Is Real

Refactor should be earned.

It makes sense when:

The application is strategically important.
The current architecture blocks delivery speed or resilience.
The business expects meaningful future change.
The team has enough system understanding to modify it safely.
The new platform model will actually be used well.

If those conditions are missing, refactor can become an expensive way to delay migration while increasing failure risk.

Example: Four Applications, Four Different Answers

A portfolio contains:

A stable Windows line-of-business application with low change volume.
A heavily customized monolith that supports a differentiating customer process.
A legacy reporting tool that duplicates newer dashboards.
A web API with clean boundaries and a team already comfortable with containers.

A practical set of decisions might be:

Rehost the Windows application first because it needs a safe landing more than redesign.
Refactor only the parts of the monolith that block future delivery or resilience.
Retire the legacy reporting tool instead of spending money to migrate dead weight.
Replatform the web API into containers because the team can improve deployment and scaling without a full rewrite.

That is not inconsistency. It is portfolio discipline.

Where Modernization Should Wait

Modernization should often wait when:

The current team does not understand the system well enough.
The migration deadline is driven by contract exit or hardware risk.
The landing zone and operating controls are not stable yet.
The application lacks observability, making deep change unsafe.
The organization has not proved it can run the workload well in AWS.

It is usually better to make one honest move and one later improvement than to promise one heroic move that accomplishes neither.

Common Mistakes

Treating rehost as automatically weak architecture.
Refactoring too early without clear business payoff or platform readiness.
Applying one migration pattern to every application for organizational neatness.
Migrating low-value systems instead of retiring or replacing them.
Calling something "modernization" when it is only a hosting move with new terminology.

If Someone Asks You

How do you decide between rehost, replatform, and refactor?

A good answer is:

I start with business value, delivery urgency, platform pain, and team readiness. Rehost is strong when speed and risk reduction matter most. Replatform is useful when the application can stay mostly intact but the operating model needs improvement. Refactor is worth it when the workload is strategically important and deeper change clearly improves agility, resilience, or cost enough to justify the added risk.

What You Should Remember

The 7Rs are decision paths, not maturity rankings. The best path is the one that matches business value, timing, and operating reality.

Questions to Check Your Understanding

Why can rehost be the right answer even when the architecture is not ideal?
What conditions make replatform more attractive than refactor?
Which application signals suggest retire or repurchase should be considered seriously?