Rehost, Replatform, Refactor, or Rewrite?
8 questions to understand which modernization path fits your legacy system best, along with its risks and trade-offs.
This is an educational, orientative guide, not a technical audit. Your answers stay in your browser.
The paths at a glance
Based on the "7 Rs" migration strategies documented by AWS Prescriptive Guidance, grouped into the paths most relevant for legacy modernization.
| Path | What it is | When it fits | Main risk |
|---|---|---|---|
| Retain or retire | Leave the system as-is (retain) or shut it down if it no longer adds value (retire), without investing in technology changes. | The business logic is no longer critical, the system sees little use, or the risk of touching it now outweighs the benefit of modernizing it. | Postponing an inevitable decision: technical and support risk keeps growing in the meantime. |
| Rehost (lift-and-shift) | Move the system as-is — same code, same behavior — to new infrastructure, for example from on-premise servers to the cloud. | You need to move off at-risk hardware or infrastructure quickly and with a low change budget, without touching the code. | It doesn't resolve technical debt or software limitations: the underlying problem stays, only where it runs changes. |
| Replatform | Targeted platform adjustments (runtime version, database engine, operating system) without redesigning the architecture or business code. | The business logic is valid, but the platform is out of support or needs a specific capability, like exposing an API. | The original architecture's limits persist: the same problem can resurface in a few years if the underlying design is never addressed. |
| Refactor / re-architect | Redesign parts of the system (architecture, modules, integrations) while keeping the business logic that still works. | The business logic is valuable, but the code or architecture no longer supports growth, scale, or new integrations. | A larger-scope, longer project than a rehost or replatform; it requires good knowledge of the current system to avoid losing business rules along the way. |
| Rewrite | Build the system from scratch with current technology and architecture, replicating or rethinking its functionality. | The code is hard to maintain, almost no one fully understands it, or the business changed so much the original design no longer applies. | It's the highest-effort, highest-risk option; losing undocumented business rules is a real risk if it isn't carefully validated during the build. |
| Replace with SaaS | Stop maintaining in-house software and adopt a market SaaS solution that already covers the need. | The function isn't a competitive differentiator, and a mature market solution already covers it well. | Dependency on a third party, customization limits, and the need to migrate existing data and integrations. |
Answer 8 questions about your system
This tool is educational and orientative — it is not a technical audit. It only reflects what you answer here; a real decision also needs a direct look at the code, the architecture, and the team.
- Risk
- Effort
- What changes
- What stays
Incremental approach recommended
With low tolerance for interruptions and a system with critical integrations, it's usually worth migrating incrementally instead of in one big leap: new modules are built around the current system and gradually replace its pieces until the original system is no longer needed. This is the pattern Martin Fowler describes as Strangler Fig.
See the Strangler Fig pattern in the glossaryAlso worth considering:
What to ask before deciding
Which parts of the system are truly the business differentiator, and which are generic ("commodity") functionality?
Who currently knows the undocumented business rules, and what happens if that person is unavailable?
How much disruption or change can operations tolerate during the migration window?
Are there critical integrations that depend on the current system's exact behavior?
Is the available budget and timeline compatible with the effort of the chosen path?
Has this already been compared against market SaaS solutions before investing in custom development?
What happens if this decision is postponed six months or a year longer?
This recommendation is educational and orientative, based only on your own answers — not a technical audit.
Let's review your case
We review it together with specialized strategic migration partners: Nextsoft builds new modules, integrations, frontend, and QA, and stays your single point of contact throughout.
Frequently asked questions
Does this guide replace a technical audit?
No. It's an educational, orientative guide based on your own answers, meant to help you understand the modernization paths and their trade-offs. A technical audit reviews the code, architecture, and infrastructure directly.
What is the Strangler Fig pattern, and when does it show up in the result?
It's a pattern described by Martin Fowler for migrating systems incrementally, replacing pieces of the original system little by little instead of making one big leap. This guide suggests it when the system has critical integrations and there is low tolerance for interruptions or large changes.
Does Nextsoft migrate legacy systems on its own?
No. Legacy system migration is delivered together with specialized strategic migration partners; Nextsoft handles new modules, integrations, frontend, and QA, and stays the single point of contact throughout the process.
Let's review your case
We review it together with specialized strategic migration partners: Nextsoft builds new modules, integrations, frontend, and QA, and stays your single point of contact.