Strangler pattern migration reduces page load times by 50%

The problem

Holiday Caravans Direct had built a successful booking platform on .NET Framework that had served them well as the business grew. However, as the platform matured, they faced a common challenge: how to modernise to current technologies without disrupting a live business.

The existing system worked reliably, but the technology stack was limiting future growth. .NET Core offered significant performance improvements, better hosting options, and access to modern development practices - but migrating a live booking platform is never simple.

The constraints

• The platform was in active use and could not go offline
• Historical data and existing integrations had to be preserved
• The team needed to continue delivering features during the migration
• A "big bang" rewrite would be too risky and resource-intensive
• The migration needed to be reversible if problems arose

Our approach

We implemented the strangler fig pattern - a proven technique for incrementally replacing legacy systems. Rather than rewriting everything at once, we built new functionality alongside the existing system and gradually migrated traffic.

API-first architecture

The key insight was recognising that the existing database represented years of valuable business logic and data. Rather than discarding this investment, we created a modern API layer that wrapped the existing database:

• Built a new .NET Core API that connected to the existing database
• Implemented clean endpoints that could serve both old and new frontends
• Gradually migrated functionality to the new stack, feature by feature
• Maintained the ability to fall back if any migration step caused issues

Phased migration strategy

The migration proceeded in careful phases:

1. API layer: Created new .NET Core API endpoints alongside the existing system
2. Read operations: Migrated read-heavy pages first (lowest risk)
3. Write operations: Progressively moved transactional features
4. Frontend: Updated the user interface to use new APIs
5. Decommission: Retired legacy components only after thorough testing

Risk mitigation

At every stage, we maintained the ability to route traffic back to the original system. This meant the business was never exposed to unacceptable risk - if a migrated component caused problems, we could revert within minutes.

Performance improvements

• 50% reduction in page load times across the platform
• Improved server response times from more efficient .NET Core runtime
• Better resource utilisation, reducing hosting costs

Technical outcomes

• Successfully migrated from .NET Framework to .NET Core
• Preserved all existing data and business logic
• Zero downtime during the entire migration process
• Modernised architecture ready for future enhancements

Business continuity

• Booking operations continued uninterrupted throughout
• New features could still be delivered during migration
• Team upskilled on modern .NET practices during the project
• Reduced technical debt without sacrificing business momentum

The strangler pattern in practice

The strangler fig pattern takes its name from the tropical plant that gradually envelops and eventually replaces its host tree. In software terms, it means:

1. Build alongside: Create new functionality next to the existing system
2. Redirect gradually: Route traffic to new components incrementally
3. Monitor carefully: Watch for issues and be ready to revert
4. Decommission safely: Only remove old code when confident in the replacement

This approach contrasts with "big bang" rewrites, which carry enormous risk. With the strangler pattern, each step is small enough to understand, test, and reverse if necessary.

Database as the integration point

A critical architectural decision was treating the existing database as the system of record throughout the migration. Rather than migrating data to a new structure (which would require complex data migration logic), we kept the database stable and changed only the application layer.

This meant:

• No risky data migrations
• Both old and new systems could coexist
• Gradual validation of new code against production data
• Simple rollback if any new component failed

Performance gains explained

The 50% improvement in page load times came from several factors:

• .NET Core efficiency: The runtime is fundamentally more performant
• Modern caching: Better caching strategies reduced database load
• Async improvements: Better use of asynchronous operations improved throughput
• Hosting optimisation: .NET Core's hosting model is more efficient

Lessons learned

The most important lesson from this migration: patience pays off. The temptation to "just rewrite it" is strong, but incremental migration is almost always safer for a live business system. The strangler pattern required more upfront planning, but delivered a smooth transition with minimal business risk.