Modernise, Rebuild, or Replace: A Decision Framework for Legacy Systems

Why the strategy matters more than the technology

The most common mistake in legacy modernisation is jumping to a solution before understanding the problem. “We need to move to the cloud” or “we need to rebuild in React” are technology decisions, not strategy decisions. The strategy should come first: what are we trying to achieve, what constraints do we have, and which approach delivers the best outcome for the investment?

A good strategy accounts for business continuity, risk tolerance, budget, timeline, team capability, and the system’s current state. The technology follows from those decisions, not the other way around.

The six strategies

These are commonly called the “6 Rs.” Each applies to different situations and carries different cost, risk, and outcome profiles.

Retain (keep as-is)

What it means: Leave the system in place. Do not invest in modernisation.

When it fits:

• The system works well enough and is not blocking business initiatives
• The cost of modernisation exceeds the cost of continued maintenance over the relevant time horizon
• The system is approaching end of life and will be retired naturally

Risk: Low in the short term. Increases over time as security, talent, and compliance risks accumulate.

Cost: Ongoing maintenance costs continue unchanged. Consider managed application support to stabilise costs and reduce risk while you plan the next step.

Retire (decommission)

What it means: Turn the system off. Migrate data to other systems or archive it.

When it fits:

• The system’s functionality has been replaced by another system
• The system is used by few or no users
• The data can be preserved in an archive or migrated to a successor system

Risk: Low, but requires careful data migration and stakeholder communication. Verify that no critical process depends on the system before decommissioning.

Cost: One-time data migration and decommissioning. Saves ongoing maintenance and hosting costs.

Rehost (lift and shift)

What it means: Move the system to cloud infrastructure without changing the application. The same code runs on Azure VMs instead of on-premises servers.

When it fits:

• The system runs on infrastructure that needs replacing (hardware end of life, data centre exit)
• You need quick cloud benefits (disaster recovery, scalability, cost flexibility) without application changes
• The application is stable and does not need architectural changes

What you get: Cloud infrastructure benefits (pay-as-you-go, backup, disaster recovery, global availability) without application risk. The application itself is unchanged.

What you do not get: Cloud-native capabilities (autoscaling, managed services, serverless). The application still has the same technical debt; it is just running somewhere different.

Timeline: Weeks, not months.

Cost: A one-time migration investment per application. Ongoing cloud hosting costs replace on-premises costs (may be higher or lower depending on the workload profile). See pricing for current ranges.

Replatform (lift, shift, and optimise)

What it means: Move the application to a managed cloud platform with targeted changes. Replace the database with a managed service (Azure SQL). Move from IIS to Azure App Service. Adopt managed caching instead of self-hosted Redis. The application code changes minimally.

When it fits:

• The application architecture is sound but the infrastructure is outdated
• You want managed services (patching, scaling, monitoring) without rewriting the application
• The application can run on a modern managed platform with minor changes

What you get: Reduced operational burden (the cloud provider manages patching, scaling, and availability), improved resilience, and a foundation for further modernisation.

Timeline: 2-8 weeks per application.

Cost: Scales with application complexity. Lower ongoing operational costs due to managed services. See our pricing for current ranges.

Refactor (re-architect for cloud-native)

What it means: Restructure the application for cloud-native architecture. Break a monolith into services. Replace tightly coupled components with APIs. Adopt containers, CI/CD, and infrastructure as code. The business logic is preserved; the architecture changes.

When it fits:

• The application needs to scale, integrate, or evolve in ways the current architecture prevents
• Specific components are bottlenecks (performance, reliability, maintainability)
• The business logic is sound but the packaging is not

What you get: A modern, maintainable architecture that can scale, integrate with other systems, and evolve independently. Improved developer productivity and reduced time-to-change.

What it requires: The most skilled approach. Understanding the current system deeply enough to restructure it without breaking behaviour. This is where AI-augmented analysis delivers the most value: AI tools map dependencies, identify coupling, and generate the refactoring plan that would otherwise require weeks of manual investigation.

Timeline: 1-2 months per major component.

Cost: Scales with component size and complexity. AI-augmented delivery compresses both the analysis and the implementation. See pricing for current ranges.

Rebuild (rewrite from scratch)

What it means: Build a new system using the old system as a specification. The existing code is not migrated. The behaviour, data, and business rules are reproduced in modern architecture.

When it fits:

• The architecture is fundamentally incompatible with modern requirements (monolithic, tightly coupled to obsolete technology)
• The technology stack blocks hiring (no developers available or willing)
• The data model does not reflect the current business domain
• The cost of refactoring exceeds the cost of rebuilding

What you get: A clean foundation with modern architecture, current technology, and the ability to evolve. No technical debt carried forward.

What it risks: Rebuilds take longer and cost more than planned. The old system contains undocumented behaviour that the rebuild must replicate. Second-system syndrome (over-engineering the replacement) is a common trap.

How AI changes the calculation: AI-augmented delivery compresses rebuild timelines by 40-50%. AI tools analyse the legacy codebase to extract business rules, data flows, and edge cases that would otherwise be discovered late in the project. The legacy system becomes a detailed specification that the AI-augmented team can work from, reducing the risk of missing undocumented behaviour.

Timeline: 2-6 months with AI-augmented delivery, less when accelerators apply.

Cost: The most significant investment of all strategies. See our pricing for current ranges.

How to decide: the decision framework

Step 1: assess the current system

Before choosing a strategy, understand what you have. A structured assessment answers:

• What is the system’s architecture? (monolithic, layered, microservices, something else)
• What is the technology stack? (current, supported, end-of-life)
• What is the code quality? (tested, documented, maintainable, or the opposite)
• What are the dependencies? (databases, APIs, third-party services, legacy protocols)
• What are the security and compliance gaps?
• Who understands the system? (documentation, team knowledge, key person risk)

AI-augmented assessment compresses this from weeks to days. The output is a clear, evidence-based picture that drives the strategy decision.

Step 2: define the business drivers

Why are you modernising? The answer determines the strategy.

Step 3: evaluate constraints

Budget. How much can you invest? Rehosting and replatforming require less upfront investment. Refactoring and rebuilding require more but deliver greater long-term value.

Timeline. When do you need results? Rehosting delivers cloud benefits in weeks. Rebuilding delivers a modern system in 2-6 months. Incremental approaches (strangler fig) deliver value continuously.

Risk tolerance. How much disruption can the business absorb? Incremental approaches reduce risk. Big-bang migrations increase it.

Team capability. Do you have (or can you partner with) a team that can execute the chosen strategy? AI-augmented delivery partners expand what is achievable with a given team size and timeline.

Step 4: choose a strategy per component

Most legacy systems are not one thing. They have multiple components with different characteristics. Apply the right strategy to each component.

The frontend may be a candidate for rebuilding (modern UI framework, better user experience). The business logic may be a candidate for refactoring (extract into services, add APIs). The database may need replatforming (move to Azure SQL with managed backups and scaling). Some utility functions may be candidates for retirement (replaced by SaaS).

The incremental approach

Strangler fig pattern

The safest approach to legacy modernisation is incremental. The strangler fig pattern works like this:

1. Identify a component to modernise (a specific feature, endpoint, or user journey)
2. Build the modern replacement alongside the legacy system
3. Route traffic to the new component (using an API gateway or load balancer)
4. Validate that the new component works correctly in production
5. Retire the legacy component
6. Repeat for the next component

The legacy system continues to operate throughout. There is no big-bang cutover. Risk is contained to one component at a time. If a new component has problems, traffic routes back to the legacy version.

AI-augmented teams accelerate each step: analysing the legacy component, building the replacement, generating tests that verify behavioural parity, and automating the routing and monitoring.

Data migration in parallel

Data migration often runs in parallel with application modernisation. Nightly migration pipelines synchronise data from the legacy system to the new platform, with anonymisation for non-production environments and validation checks for data integrity. This allows the new system to be tested with real data before the cutover.

Where to start

1. Get an honest assessment. A 2-4 week assessment with an AI-augmented team gives you an evidence-based view of your system’s state, risks, and options. This costs a fraction of the modernisation and prevents the most expensive mistake: choosing the wrong strategy.
2. Define the business driver. Why are you modernising? The answer shapes the strategy, the budget, and the timeline.
3. Start incremental. Unless there is a compelling reason for a big-bang approach, start with the strangler fig pattern. Deliver value continuously, contain risk, and build confidence.

See our legacy application modernisation service for how we approach this, or book a consultation to discuss your specific system. If you need to keep the legacy system stable while you plan, our managed application support service provides a bridge.