Modernization Frameworks for Legacy Systems

The 6R model — Rehost, Replatform, Refactor, Repurchase, Retain, Retire — has become the default vocabulary for legacy system modernization in enterprise IT. It is a useful framework. It is also a framework that has become more invoked than understood; many programmes describe their work in 6R terms without honestly assessing which R applies to which workload.

This piece is a practitioner view of what each R actually means in delivery, what the cost profile looks like, and where the temptation to choose the wrong R produces predictable failure modes.

The framework, restated

The 6R model originated as a cloud migration framework but has generalised to any legacy modernization. Each R describes a strategy for what to do with a specific application:

• Rehost. Move the application to new infrastructure with minimal change. Lift-and-shift. The application's architecture is unchanged; only its location changes.
• Replatform. Move the application with minor optimisations to take advantage of the new platform. Often called lift-tinker-and-shift. Some platform-specific dependencies are replaced; the architecture is largely intact.
• Refactor. Restructure the application's code to fit a new architectural model. Microservices decomposition, cloud-native patterns, modernised dependencies. Significant engineering investment; architecture changes.
• Repurchase. Replace the application with a commercial SaaS or off-the-shelf product. The custom application retires; the function moves to a vendor.
• Retain. Keep the application as-is. No migration. Continue operating where it is.
• Retire. Decommission the application entirely. The function is no longer needed, or has been replaced by something else.

The framework is useful because it forces explicit choice. The failure mode is that the choice is often made by what feels strategic rather than by what fits the workload.

Rehost — when it actually fits

Rehost is the cheapest option, the fastest to execute, and the most consistently undersold. The application is moved with no architectural change; the value comes from being on better infrastructure.

Where rehost fits:

• The application is functionally fine; the underlying infrastructure has aged
• There's a hard deadline (data centre exit, licence expiry, security mandate) that doesn't allow time for architectural change
• The application is not a strategic target; investment in it doesn't compound
• The team operating it is being changed and the institutional knowledge is leaving anyway

Where rehost fails:

• The cloud bill turns out higher than expected because the application has cloud-hostile characteristics (chatty I/O, no horizontal scale, expensive licence terms)
• The post-rehost expectation was further modernization that never gets funded
• The application's design fights against the cloud's failure modes (assumes always-on infrastructure that doesn't exist in cloud)

The most common rehost mistake is treating it as a stepping stone to refactor. In practice, once an application is operating successfully on new infrastructure, the funding for the next-step refactor often evaporates. If refactor is the goal, plan for it explicitly rather than expecting it to follow rehost.

Replatform — the practical middle

Replatform is the most commonly chosen R for workloads that need some change. The application's architecture stays largely intact; specific dependencies are modernised — database moves to managed service, web tier moves to container, authentication moves to managed identity provider.

Where replatform fits:

• The application has a small number of legacy dependencies that are now actively painful (the obsolete database, the unsupported web server, the deprecated authentication library)
• The team can absorb moderate change without a full rewrite
• The application will remain in service for several more years

Where replatform fails:

• The "minor change" turns out to be major when discovered in delivery
• The change to one component cascades into changes in others
• The replatformed application is harder to operate than the original was

The replatform sweet spot is changes that are well-bounded and well-understood. The replatform danger zone is changes that look small in scope but turn out to have surprising dependencies.

Refactor — the high-investment option

Refactor is the most expensive R and the one that produces the largest architectural change. The application is restructured — from monolith to services, from synchronous to event-driven, from local state to externalised state.

Where refactor fits:

• The application is strategically important and the team can fund a multi-year investment
• The current architecture genuinely constrains the business — scale limits, modification cost, integration friction
• The refactor target is well-understood, not aspirational
• The team has the engineering capacity and the platform substrate (Kubernetes, observability stack, deployment pipeline) to support refactored services

Where refactor fails:

• The refactor target is fuzzy ("modernise the architecture") rather than specific ("decompose into these three bounded contexts")
• The investment is approved in chunks that prove smaller than needed; the refactor stalls partway through
• The team doesn't have the engineering capacity; refactor becomes a perpetual project
• The legacy application is still being changed by the existing team; the refactor and the legacy diverge

Refactor is the option most often chosen for strategic reasons that turn out not to justify the cost. Be honest about the actual business case before committing.

Repurchase — when the function is commodity

Replacing custom application with commercial SaaS makes sense when the function is genuinely commodity — payroll, CRM, helpdesk, email, project management. The custom application was probably built because no good SaaS existed at the time; the SaaS landscape has matured; the custom code has become a tax.

Where repurchase fits:

• The function is commodity; competitive advantage doesn't come from doing it differently
• A credible SaaS option exists in the relevant geography with appropriate compliance posture
• The data and integration migration is tractable
• The custom application's domain knowledge can be expressed in the SaaS's configuration

Where repurchase fails:

• The function is more specialised than thought; the SaaS doesn't support critical edge cases
• The integration surface is larger than estimated; rewiring takes longer than the SaaS evaluation suggested
• The custom application's accumulated configuration encodes business logic that doesn't translate
• The SaaS vendor's product direction diverges from the customer's needs over time

The repurchase decision should be tested against the actual usage of the custom application, not against the application's documented features. Many custom applications have accumulated usage patterns that aren't in the documentation but are critical to operations.

Retain — the underused option

Retain is the option most often skipped. The instinct is that every legacy application needs a modernization plan; in reality, many legacy applications are functioning fine and should be left alone.

Where retain fits:

• The application is stable, operational, and not a strategic constraint
• The cost of modernization exceeds the value of modernizing
• The application's eventual retirement is scheduled (5+ years out), and intervening modernization isn't worth the investment
• The team doesn't have the capacity for the modernization work without dropping more important things

Where retain fails:

• The retain decision is made by default rather than by deliberate choice
• The application's vendor support lapses, security patches stop, talent becomes unavailable
• The "retain" turns out to be "retain forever" because retirement keeps slipping

Retain is honest when chosen explicitly. Retain is a problem when chosen by avoiding the conversation.

Retire — the most courageous option

Retire is the option that requires the most political courage. Killing an application means telling its users that the function they depend on is going away. The path is rarely smooth.

Where retire fits:

• The function is no longer needed (the regulation changed, the business unit closed, the workflow was redesigned)
• The function is now handled elsewhere (by another application, by a SaaS, by a different team)
• The application's usage has dropped below the threshold that justifies operating it

Where retire fails:

• The remaining users are vocal and politically protected
• The function turns out to be needed by adjacent systems that nobody mapped
• The data retention obligations weren't planned

Successful retirements have explicit timelines, executive sponsorship, communication plans, and migration paths for remaining users. Unsuccessful retirements stall indefinitely as one stakeholder after another raises objections.

Choosing the right R

For each legacy application, the diagnostic questions:

1. Is the function still needed? If no, retire.
2. Is the function commodity, with a credible SaaS option? If yes, repurchase.
3. Is the application strategically important and will it remain so for 5+ years? If yes, refactor candidate.
4. Is there a small bounded change that unblocks the application's continued operation? If yes, replatform candidate.
5. Does the application have a hard deadline (data centre exit, contract expiry) without time for architectural change? If yes, rehost.
6. Is the application stable, operational, and unimportant strategically? If yes, retain.

The honest assessment usually distributes a portfolio across multiple Rs. The mistake is choosing one R for the whole estate; the estates that modernize successfully have an explicit per-application choice rationale.

What we recommend

For an organisation evaluating legacy modernization:

1. Run a portfolio assessment. Every legacy application gets a recommended R with documented rationale.
2. Sequence the Rs by value-cost ratio. Retire first (lowest cost); retain confirmed; rehost for deadline-driven; replatform for bounded-change; refactor for strategic.
3. Avoid the temptation to refactor everything. Most estates need refactor for 10-20% of applications, not for the majority.
4. Plan for the operating model that each R requires. Rehost and replatform don't change the operating model much; refactor and repurchase change it significantly.

For an existing modernization programme showing strain:

1. Audit whether each in-flight application has the right R for its situation. Many programmes commit to refactor for applications where replatform would have produced 80% of the value at 20% of the cost.
2. Identify the retire candidates that have slipped. Bring the retirement decisions forward.

The 6R framework is useful when applied with discipline. Each R has a cost profile, a value profile, and a fit profile. Choosing well between them is the difference between modernization programmes that compound value and modernization programmes that consume budget without producing the operational improvement that was justified at funding.