Modernizing or replacing legacy software is rarely a purely technical matter. Business value, available resources, and the actual condition of the system are all factors that play a role. Many companies, out of habit, continue to use the old system, or, out of impatience, opt for something completely new without seriously considering the intermediate options.
Anyone looking to modernize legacy software has four intermediate options between continuing to use the existing system and building a new one. The 6R model categorizes them as follows: Retire, Rehost, Revise, Refactor, Rebuild, Replace. Four factors determine which option fits: technical condition, business value, available resources and strategic goal. A stable but hard-to-maintain system usually needs Refactor, not Replace.
Modernizing Legacy Software Using the 6R Model
The 6R model distinguishes six approaches for legacy systems, ranging from the smallest to the largest change (ARDURA Consulting, 06/2025).
| Option | What Happens | This works if |
|---|---|---|
| Retire | System will be shut down without a replacement | there is no longer any measurable business value |
| Rehost | Move to new infrastructure without making any changes | It's just the platform that's outdated, not the code |
| Revise | Minor technical adjustments without architectural changes | A few minor flaws are bothersome, but not the overall picture |
| Refactor | Rewrite the code structurally; the functionality remains the same | the code is stable but difficult to maintain |
| Rebuild | New development based on the existing logic | the architecture is no longer expandable |
| Replace | Replacement with a completely new solution | Technology and business logic are both at an end |
The Decision Tree in Seven Questions
The order of the questions determines how quickly an option can be ruled out.
- Does the system still provide measurable business value? No, then retire it. This question is often resolved more quickly than expected when no one really knows the usage figures.
- Is the underlying technology a total loss? If the manufacturer is no longer around, there is no longer any support, and there is no developer community, then there is no alternative to rebuilding or replacing the system.
- Is the architecture fundamentally extensible? If not, even if the code works, this limits all modernization options except for a rebuild or a replace.
- Is the code technically stable but difficult to maintain? This is exactly where Refactor fits in best (ARDURA, 06/2025). The business value is there; the technical problem lies in the code quality, not in the architecture.
- Is a new infrastructure enough without changing the code? In that case, rehosting is the fastest and most affordable option.
- Are there only minor technical issues? In that case, Revise is sufficient, without any major changes.
- Is there no clear answer to any of the questions one through six? In that case, a more in-depth technical assessment is needed before a decision is made. Hasty decisions at this stage are the most common reason why modernization projects fail later on.
What Really Determines the Decision
According to ARDURA, choosing the right option depends on four factors: technical condition, business value, available resources, and strategic goals (ARDURA, 06/2025). A system with high business value and poor technical condition justifies investment. A system with low business value rarely justifies investment, regardless of its technical condition.
It’s worth taking a clear stance here. In practice, those looking to modernize legacy software often skip refactoring because “replace” seems like the more thorough approach—a new system free of old baggage. This is a fallacy when the business value of the legacy system is high and the code is merely difficult to maintain but technically stable. In this case, a rebuild or replacement costs significantly more time and money than the actual problem—maintainability—justifies.
Assess Your Legacy System Based on the Seven QuestionsWe'll take a look at the architecture, dependencies, and usage metrics and let you know which of the six options remains.
Modernization During Operation
Rehost and Revise are usually carried out alongside day-to-day operations. Rebuild and Replace, on the other hand, almost always require a transition phase with parallel operation, during which the old and new systems run simultaneously.
One contractual detail is often overlooked in this context. Anyone replacing a legacy system should assess the extent to which the new provider or development partner creates a new lock-in. We describe the most important safeguards for this in the Article on Avoiding Vendor Lock-in. The breakdown of the costs over five years is provided in the article on hidden costs.
Frequently Asked Questions
How can you tell if a system is a total technological loss?
Typical signs include a manufacturer that no longer offers support, a programming language or platform for which it is difficult to find developers, and an architecture that no longer allows for new features without compromising existing ones. If several of these points apply, there is hardly any way around rebuilding or replacing the system (ARDURA, 06/2025).
Is it possible to modernize while operations are ongoing?
For "Rehost" and "Revise," yes, because infrastructure changes or minor adjustments can usually be implemented without downtime. For "Rebuild" and "Replace," parallel operation over weeks or months is the norm, requiring a corresponding investment of time and resources for both systems simultaneously.
How much does it cost to simply keep a legacy system running?
The costs of inaction are rarely immediately apparent, but they grow with each passing year. These include rising maintenance costs, increasing security risks, and a loss of adaptability to new business requirements. Before companies modernize their legacy software, it’s worth assessing their own systems, as general figures are of little help here.
The Next Step
torck evaluates legacy systems using the 6R model before recommending a rebuild, refactor, or replace. Our development teams in Maxhütte-Haidhof, Vienna, and Rabat are familiar with the pitfalls from their own modernization projects for industry and retail. The contractual partner for this project is the German company torck GmbH. In the Initial Consultation Let's go over your system together.
German 
English 
French