You’re staring at a legacy system that needs to move to the cloud. The question isn’t whether to modernise—it’s how. Do you rip everything out and replace it in one go, or do you chip away at it gradually while keeping the lights on?
Here’s the thing—most big bang replacements fail. The failure rate exceeds 70% for IT systems. But evolutionary approaches take longer and require you to stick with it. Your choice comes down to business constraints, technical maturity, and how much risk you can stomach.
In this article we’ll walk you through evolutionary versus big bang approaches, compare re-hosting against re-platforming against re-architecting, and give you the decision criteria that eliminate analysis paralysis. By the end, you’ll know which path fits your constraints—essential knowledge for AI-assisted legacy modernisation.
What Is Evolutionary Modernisation and Why Does Martin Fowler Prefer It?
Evolutionary modernisation replaces legacy systems bit by bit while keeping everything running. You build new functionality in modern services while the legacy system stays operational until you’ve completely replaced it. Each step delivers value and learning that informs what comes next, unlike big bang’s all-or-nothing gamble.
Martin Fowler coined the strangler fig pattern back in 2004. It’s named after those fig vines that gradually surround and replace host trees. The metaphor fits—you’re not cutting down the old tree, you’re growing a new one around it.
Why does Fowler prefer this? Risk reduction through incremental validation. You don’t bet the farm on a single cutover event. Instead, you validate each step before moving to the next. If something breaks, the blast radius is small and contained.
Business continuity is the other big win. Production keeps running throughout the transition. Your customers don’t know you’re modernising—they just keep getting service.
The evolutionary approach also helps you avoid the feature parity trap. You’re not trying to replicate exact legacy functionality including all the inefficiencies. You’re focusing on value delivery. What does the business actually need? Build that, not a carbon copy of what existed.
The typical timeline runs 18 to 36 months total, with value delivery every 3 to 6 months. Compare that to big bang’s 6 to 18 month development period with zero value until cutover.
The tradeoffs? It’s a longer total timeline. You need transitional architecture—temporary components that facilitate migration but represent additional investment. And it demands discipline. Incremental progress requires sustained commitment versus the sprint-to-finish mentality of big bang—a reality that’s central to the broader AI-assisted transformation context for modern enterprises.
What Is Big Bang Modernisation and When Does It Actually Make Sense?
Big bang modernisation attempts complete system replacement in a single comprehensive cutover event. You build the replacement in parallel, freeze requirements, then switch everything over during a scheduled downtime window.
For large, complex systems, the failure rate exceeds 70%. Why? Feature parity traps, integration surprises, requirements that freeze during 6 to 18 months of development while business needs keep evolving, organisational resistance to massive change, and testing limitations that make comprehensive validation impractical.
TSB Bank learned this the hard way in 2018. Their failed big bang migration caused over £330 million in losses and regulatory fines. That’s the all-or-nothing risk playing out in real money.
So when does big bang actually make sense?
Small, well-bounded systems under 10,000 lines of code with clear interfaces are candidates. If the system is truly small and you understand all its dependencies, big bang becomes feasible.
Non-critical applications that can tolerate downtime for cutover without business impact work too. If users can wait while you switch over, the risk calculus changes.
Extensive test coverage is another green light. When you have automated testing that validates replacement before cutover, you’ve eliminated one of the big risk factors.
Isolated subsystems within a broader evolutionary approach sometimes benefit from complete replacement. You might use strangler fig for the overall modernisation but do big bang on specific components that are too tangled to extract gradually.
The cost comparison isn’t pretty either. Big bang requires £500,000 to £2 million upfront capital versus evolutionary’s phased £100,000 to £500,000 per quarter investment. That upfront capital requirement creates its own risks—if the project fails, you’ve spent everything and got nothing.
How Do Re-Hosting, Re-Platforming, and Re-Architecting Compare?
Now we’re getting into the actual migration strategies. AWS calls it the 7 Rs framework—Retire, Retain, Rehost, Relocate, Repurchase, Replatform, Refactor. We’re focusing on the three transformation strategies: rehosting, replatforming, and re-architecting.
Re-hosting, or lift-and-shift, moves your application to cloud infrastructure without code changes. Timeline is weeks. Cost runs £50,000 to £200,000 depending on system size. You get fast cloud migration and immediate infrastructure cost savings with minimal disruption.
But you’re not getting architectural improvement. Technical debt persists. You’ve moved the mess to the cloud, but it’s still a mess.
When does re-hosting make sense? Non-differentiating workloads that don’t need modernisation. Time-constrained migrations where you need to get out of a data centre fast. Or as the first step in a flywheel approach where you re-host quickly, then use the savings to fund later modernisation.
Re-platforming sits in the middle. You migrate to cloud with targeted optimisations for managed services. Timeline is months. Cost runs £100,000 to £500,000 for a typical enterprise application. This captures 31.85% of modernisation projects as of 2025.
What changes? You replace your on-premises database with RDS. You swap cron jobs for Lambda. You adopt S3 for file storage. You’re taking advantage of cloud-managed services without a fundamental architecture overhaul.
The benefits are real—cloud-managed services reduce operational overhead, you get some technical debt reduction, moderate cost optimisation. But legacy architecture patterns persist. You’re not fully cloud-native yet.
Re-architecting is the fundamental restructuring to cloud-native microservices architecture. Timeline is quarters to years depending on complexity. Cost runs £500,000 to £2 million or more for enterprise systems.
But the market growth tells you something—22.74% CAGR from 2025 to 2030, fastest-growing approach. Why? Because it’s the only path that gets you full cloud-native capabilities: elasticity, resilience, API-first design. It eliminates technical debt. And it enables agentic AI.
That last point matters. If you’re planning to adopt AI agents that need to scale dynamically and integrate via APIs, you need cloud-native architecture. Re-hosting won’t get you there. Understanding why legacy systems block agentic AI adoption helps clarify this architectural imperative.
Let’s compare the three across key dimensions.
Risk: Re-hosting is low risk—you’re not changing code. Re-platforming is moderate risk—some code changes for managed services. Re-architecting is high risk but manageable with evolutionary approach.
Timeline: Re-hosting takes weeks. Re-platforming takes months. Re-architecting takes quarters.
Cost: Re-hosting is lowest. Re-platforming is moderate. Re-architecting is highest but delivers highest ROI.
Technical debt reduction: Re-hosting eliminates none. Re-platforming reduces some. Re-architecting eliminates it.
AI readiness: Re-hosting leaves you not ready. Re-platforming gives you partial readiness. Re-architecting gives you full agentic AI support.
Which Modernisation Approach Delivers the Fastest Time-to-Value?
Here’s where it gets interesting. Evolutionary modernisation delivers the fastest time-to-value despite the longer total timeline. You’re getting business benefits every 3 to 6 months, not waiting until the end.
Time-to-value measures when the business realises measurable benefits, not just technical completion.
With evolutionary approach, first value delivery happens at 3 to 6 months for the initial increment. Then you’re delivering again every 3 to 6 months throughout the 18 to 36 month total timeline.
There’s also learning ROI. Each increment informs the next, reducing waste and increasing targeting. You’re not guessing at what the business needs—you’re learning and adapting.
Example: You build a modern API that replaces a legacy batch process. That API delivers business value in month 4, not month 24. The business can start using it immediately.
Big bang’s time-to-value is brutal. First value delivery happens at cutover after 6 to 18 months of development. During that entire development period, you’re getting zero business benefit. It’s a value drought.
And the all-or-nothing risk means complete failure delivers zero value despite full investment.
Re-hosting is different. Migration completion takes weeks. The value you get is infrastructure cost savings and operational efficiency. But there’s no business capability improvement or technical debt reduction.
This is where the flywheel strategy comes in. Phase 1: Re-host for quick cloud migration in weeks. Phase 2: Capture infrastructure savings and operational learnings over months 1 to 6. Phase 3: Use those savings to fund evolutionary re-architecting from month 6 onwards.
Benefit: Continuous value stream from week 1 while building toward transformational change. You’re not choosing between fast or good—you’re sequencing them.
How Do You Modernise Without Breaking Production Systems?
Business continuity matters for production systems. The strangler fig pattern handles this by routing traffic through an indirection layer that gradually redirects from legacy to new services.
The strangler fig pattern operates through several components working together. You identify a software seam—a natural boundary where a new service can replace a legacy function. Then you create an indirection layer like an API gateway, message router, proxy, or facade that intercepts requests. The new service implements behind this layer with an interface that mimics the legacy behaviour.
Traffic routing starts small through feature flags, then monitoring validates correctness through parallel runs comparing outputs. You gradually increase traffic to the new service as confidence builds, then decommission the legacy component once it’s fully replaced. Then you repeat the process for the next software seam.
The indirection layer is your safety net. It provides transparent traffic routing between legacy and new implementations. Implementation options include API gateway for REST or GraphQL, message broker for event interception, reverse proxy, or application facade.
Capabilities you want: Percentage-based routing, A/B testing, versioning, observability, and rollback. This is temporary architecture that gets removed after migration completes.
Progressive rollout techniques reduce deployment risk. Feature flags give you runtime toggles that enable or disable new functionality without deployment. Canary deployments route 1% to 5% of traffic to the new service, validate it, then incrementally increase. Blue-green deployment runs both versions with instant switch or rollback capability.
Validation strategies keep you safe. Parallel run means both legacy and new process the same inputs, you compare outputs, and alert on discrepancies. Automated testing with comprehensive test suites validates new service behaviour. Monitoring and observability provides detailed metrics comparing legacy versus new performance, errors, and latency.
And rollback readiness is required. Every increment needs a documented rollback procedure you can execute within minutes if things go wrong.
Software seam discovery combines analysis techniques with business knowledge. You’re looking for natural architectural boundaries where replacement can occur independently. Discovery techniques include event storming workshops, domain-driven design analysis, and dependency mapping.
Examples of good seams: API endpoints, message consumers, batch processes, UI components, data transformations. Selection criteria: High business value, low interdependency, clear interface contracts.
When Should You Keep Legacy Systems and Wrap Them with APIs?
Sometimes modernisation is years away but you need integration now. API wrapping encapsulates the legacy system and connects it to new access layers via APIs.
This involves minimal code changes and low risk. You’re not touching the guts of the legacy system. You’re just putting a modern API in front of it.
When does this make sense? The legacy system is stable and working. Full modernisation timeline is years away. You need AI integration or other connectivity now. You don’t have budget for proper modernisation yet.
How do you do it? API gateway exposing legacy functions as REST or GraphQL endpoints. You develop APIs to connect modernised systems with existing applications.
The limitations are real though. API wrapping doesn’t improve legacy maintainability. It adds a complexity layer. And eventual modernisation is still needed—you’re just buying time.
Think of it as a tactical bridge while planning evolutionary modernisation. The use case is simple: You need legacy data or functionality accessible to modern systems right now, but you can’t justify or afford full modernisation yet. Wrap it, use it, plan the real modernisation for later.
How Do You Choose the Right Modernisation Path for Your Constraints?
Selecting migration strategies is a big decision for large migrations. The choice depends on your business drivers, constraints, and desired outcomes.
No universal approach exists—each legacy system requires a tailored modernisation strategy. Here’s how to match your constraints to the right approach.
Assess across five dimensions to determine your path:
Business criticality drives evolutionary versus big bang preference. High criticality means evolutionary reduces risk, low criticality means big bang becomes acceptable.
Technical debt level determines re-hosting versus re-platforming versus re-architecting. High debt means re-architecting delivers value, moderate debt means re-platforming balances cost and benefit, low debt means re-hosting moves you to cloud quickly.
AI adoption timeline influences architecture needs. If AI is on your roadmap and the timeline is urgent, re-architecting provides the foundation you need. If AI is 2-plus years away, phased approach lets you sequence investments.
Budget constraints shape the flywheel strategy. Constrained budget suggests re-hosting first to generate savings, then use those savings to fund later re-architecting. Flexible budget enables direct re-architecting.
Risk tolerance affects the overall approach. Low risk tolerance means evolutionary with strangler fig. Higher risk tolerance means big bang becomes acceptable for appropriate systems.
Here are the specific indicators for each migration strategy:
Rehost when: Workload is stable and compatible with cloud. You need low-risk migration. Short-term cloud adoption goals. No immediate modernisation need. Team has limited cloud experience.
Before choosing rehost, confirm the workload won’t require modernisation within two years. If it will, you’re just kicking the can down the road.
Replatform when: You want to simplify reliability and disaster recovery. Reduce OS and licensing overhead. Improve time-to-cloud with moderate investment. Get cloud benefits without full re-architecture.
Rearchitect when: Application requires modularisation or service decomposition. Scaling needs vary by component. Architecture must support future innovation. AI adoption is on the roadmap.
The business driver emerges from the gap between workload’s current state and desired future state. Define that gap clearly and the right path becomes obvious.
What Does Cloud-Native Actually Mean and Why Does It Matter for AI?
Cloud-native applications exploit cloud platform advantages through architecture specifically designed for cloud environments. This differs from simply running existing applications in the cloud.
Re-architecting is driven by strong business demand to scale, accelerate product and feature releases, and reduce costs. The refactor migration strategy involves taking full advantage of cloud-native features to improve agility, performance, and scalability.
Microservices are the foundation of modernising legacy applications. You’re breaking down large monolithic applications into smaller, more manageable components or services. Each service can scale independently, deploy independently, and fail independently.
Why does this matter for AI? Agentic AI requires elastic scaling—agents need to spin up and down based on demand. That needs cloud-native architecture. AI needs API-first integration to connect with your systems. That needs microservices. AI needs event-driven processing for asynchronous workflows. That needs cloud-native patterns.
You can’t bolt agentic AI onto a monolith running in a re-hosted environment. The architecture won’t support it. This is why re-architecting shows the fastest growth—it’s the path that enables the next generation of capabilities.
The cloud-native characteristics: Elastic scaling that adjusts to demand. API-first design that enables integration. Managed services that reduce operational overhead. Event-driven architecture for asynchronous processing. Resilience patterns that handle failure gracefully.
If AI is on your roadmap, then cloud-native architecture provides the foundation everything else builds on.
Making Your Choice
You’ve got the framework now. Evolutionary versus big bang comes down to system size, complexity, and business criticality. Small, non-critical systems can use big bang. Everything else should use evolutionary with strangler fig pattern.
Re-hosting versus re-platforming versus re-architecting depends on technical debt, AI timeline, budget, and desired benefits. Re-host for quick cloud migration. Re-platform for balanced modernisation. Re-architect for full transformation and AI enablement.
The flywheel approach sequences these: Re-host fast, capture savings, fund re-architecting. You’re not choosing one strategy for everything—you’re orchestrating multiple strategies across your portfolio.
Strangler fig pattern with indirection layer, progressive rollout, and validation keeps production running while you modernise. API wrapping buys time when modernisation is years away but integration is needed now.
Cloud-native architecture is the destination if AI is in your future. You can get there through re-hosting then re-platforming then re-architecting. Or you can aim for it directly. But you need to get there eventually.
The analysis paralysis stops when you apply these criteria to your specific context. What’s your business criticality? What’s your technical debt? What’s your AI timeline? What’s your budget? What’s your risk tolerance?
Answer those questions honestly and the right path becomes clear. Then execute it with discipline and sustained commitment. That’s how you modernise without breaking production and without betting the farm on a single cutover event.
Once you’ve chosen your path, the 90-day implementation playbook provides the step-by-step execution guidance to turn your legacy modernisation strategy into reality.
