Migration is not one technical task.
It is a decision about how much of the existing system should survive.
That is why the 6 Rs are useful: rehost, replatform, refactor, rebuild, replace, and retire.
Each one solves a different problem.
Rehost: Move the System With Minimal Change
Rehosting is the simplest migration path.
You move the application to a new environment and change as little as possible.
Typical examples:
On-prem VM
↓
Cloud VM
or:
Old hosting environment
↓
New infrastructure
Best when
the application is stable,
infrastructure is the main problem,
you need to leave a data center quickly,
time is limited,
architectural change is not the immediate priority.
Watch out for
You are moving existing problems too.
If the application is hard to deploy, tightly coupled, or inefficient, those issues usually remain.
Rehosting changes where the system runs.
It does not automatically modernize how the system works.
Replatform: Improve the Environment Without Rebuilding
Replatforming keeps most of the application intact but makes targeted platform changes.
For example:
Self-managed database
↓
Managed database
or:
Legacy runtime
↓
Supported runtime
or:
Manual deployment
↓
Containerized deployment
Best when
The application still meets business requirements, but the operating environment is outdated, expensive, or difficult to maintain.
Watch out for
Scope creep.
A small platform change can quietly turn into a large redesign.
Before starting, define:
What changes?
What stays unchanged?
That boundary matters.
Refactor: Change the Architecture
Refactoring is appropriate when the application still has value, but its internal architecture is creating problems.
Common signals include:
tightly coupled modules,
fragile deployments,
hard-to-build integrations,
poor scalability,
large blast radius for small changes,
slow development because everything depends on everything else.
A refactor might introduce cleaner service boundaries, improve APIs, or reduce coupling.
Best when
The business logic is still useful, but the architecture is limiting maintainability, scalability, or delivery speed.
Watch out for
Open-ended redesign.
"Improve the architecture" is not a useful finish line.
Define a concrete goal.
For example:
Current:
One release deploys the whole application.
Target:
Billing can deploy independently.
That gives the project a measurable outcome.
Also watch for hidden business rules.
Old systems often behave correctly for reasons nobody remembers.
Rebuild: Create a New Application Around the Same Business Need
Sometimes the existing design is too constrained to evolve safely.
That is when rebuilding becomes a real option.
This is more than refactoring.
You are creating a new implementation.
Best when
the data model no longer fits the business,
major workflow changes are required,
the current architecture cannot support future needs,
incremental change is becoming more expensive than replacement.
Watch out for
Assuming the old system contains nothing valuable.
Legacy applications often include years of:
validation rules,
exception handling,
scheduled jobs,
integration behavior,
edge cases,
operational knowledge.
A rebuild that ignores those details can be technically clean and operationally wrong.
Before rebuilding, document the current behavior.
Replace: Use an Existing Product Instead
Not every system should remain custom software.
If a commercial or SaaS product can solve the same problem well, replacement may be more sensible than maintaining a custom application.
Best when
The system supports a standard business function and custom development no longer provides enough strategic value.
Examples might include common internal workflows, standard back-office functions, or capabilities already covered by mature platforms.
Watch out for
The last 10%.
A product may cover most of your current functionality but still miss the workflow that matters most to the business.
You also need to consider:
data migration,
integrations,
access control,
customization limits,
vendor lock-in,
recurring cost,
user adoption.
The right question is not:
Can this product replace the application?
It is:
Can this product support the business process?
Retire: Do Not Migrate What You No Longer Need
Retirement is probably the most underrated option.
Sometimes an application should not move anywhere.
It should disappear.
Systems stay alive for strange reasons:
nobody owns the shutdown decision,
another tool already replaced them,
usage is almost zero,
the business process no longer exists,
teams are afraid of hidden dependencies.
Then a migration project starts and the old system is added to the migration list automatically.
That can waste a lot of engineering effort.
Best when
The system no longer provides enough business value to justify its cost and risk.
Watch out for
Hidden dependencies.
Before retirement, check:
Scheduled jobs
Reports
Downstream systems
Data retention
Audit requirements
External consumers
Do not turn something off just because nobody remembers using it.
The 6 Rs Are Not a Maturity Ladder
I do not think this:
Rehost -> Replatform -> Refactor -> Rebuild
represents increasing technical maturity.
Sometimes rehost is the correct engineering decision.
Sometimes rebuilding would be unnecessary.
Sometimes replacing custom software is smarter than writing more code.
Sometimes retiring the system is the highest-value option.
The goal is not to choose the most technically ambitious R.
The goal is to choose the one that solves the actual problem.
Start With the Problem, Not the Technology
Before discussing cloud vendors, databases, frameworks, or architecture, write down the migration problem.
For example:
Problem:
Infrastructure is no longer supported.
Likely path:
Rehost or replatform.
Problem:
Architecture prevents teams from deploying independently.
Likely path:
Refactor.
Problem:
The current data model cannot support the new business model.
Likely path:
Rebuild.
Problem:
A mature SaaS product now covers the capability.
Likely path:
Replace.
Problem:
Nobody actually needs the system anymore.
Likely path:
Retire.
That is a much better starting point than:
"We should move this to the cloud."
A Portfolio Can Use Multiple Rs
One migration strategy rarely fits every application.
A typical portfolio might look like:
System A -> Rehost
System B -> Replatform
System C -> Refactor
System D -> Replace
System E -> Retire
That is not inconsistency.
It is good architecture planning.
Each application has different business value, technical risk, dependencies, and future requirements.
Treating them all the same may make the migration program easier to explain, but not necessarily safer or cheaper.
Practical Checklist
Before choosing a migration path, I would ask:
[ ] Is infrastructure the main problem?
[ ] Is the application still useful to the business?
[ ] Is the current platform supported?
[ ] Is architecture limiting delivery or scalability?
[ ] Are important business rules documented?
[ ] Could an existing product replace the capability?
[ ] Does the application still need to exist?
[ ] Are integrations and dependencies understood?
[ ] What business outcome should the migration improve?
[ ] What is the smallest change that solves that problem?
Then map the answer:
Infrastructure problem -> Rehost
Platform problem -> Replatform
Architecture problem -> Refactor
Fundamental design problem -> Rebuild
Commodity capability -> Replace
No remaining value -> Retire
The important part is not memorizing the six labels.
It is avoiding the mistake of treating every migration as the same kind of work.
A migration should remove a specific constraint.
If you cannot explain what that constraint is, you are probably not ready to choose the path yet.
I work on modernization and migration planning at Ksoft Technologies, and I wrote a longer version of this framework here:
[https://www.ksofttechnologies.com/blogs/6-rs-of-migration-explained]
Top comments (0)