From Legacy Systems to Modern APIs: Rebuilding for Performance at HCD

Holiday Caravans Direct (HCD) wasn't just a platform rebuild — it was a complete technical evolution. When I stepped into the project, I inherited a legacy PHP-based platform that had grown organically with the business but was showing its age. Performance issues, brittle code, and scalability concerns were all part of the package.

The task? Rebuild the system with performance and maintainability at the forefront, while ensuring the existing business could continue operating.

Shedding the Legacy

The original system relied heavily on server-side rendering and direct database coupling, making it fragile and difficult to scale. Instead of trying to patch it, I proposed a clean break — a full rewrite using .NET Core, with a focus on APIs and a component-driven front end powered by Vue.js.

But I couldn’t just abandon the old system. There were still business operations relying on it, and we needed a way to co-exist during the transition. So I built a service wrapper — essentially a façade API — that exposed data from the old system in a structured way. This allowed us to begin developing the new platform while still operating from the existing database.

It was my first step toward a more service-oriented approach, even within a monolithic environment. It also introduced clear boundaries that made it easier to test, evolve, and eventually replace components.

Performance By Design

A major bottleneck in the old system was the booking calendar — it was overloaded with logic and rendering overhead. To solve this, I moved from server-rendered pages to a two-step API-driven process:

1. First, fetch availability

2. Then, fetch pricing details

This reduced payload sizes and improved responsiveness, particularly on mobile. It also let us cache availability results more effectively, since pricing changes more frequently and is user-specific.

Combined with lazy-loading components in Vue, this approach made the booking journey feel faster and more responsive — all without sacrificing flexibility.

Decoupling for Maintainability

I took the opportunity to enforce separation of concerns from day one. Each feature was treated as a standalone module with its own API endpoints, front-end components, and isolated logic. That meant we could make changes in one area without triggering regressions elsewhere — a critical feature when you're the only developer and can't afford to constantly firefight.

Wherever possible, I avoided tight coupling between front-end components and back-end logic. Instead, the front end was built to consume contract-based APIs, making the system easier to scale or replace down the line.

The Payoff

By the time the new platform was running, the difference was night and day. Pages loaded faster, the system was easier to extend, and the business could finally think about growth without fearing technical collapse.

More importantly, I had created a foundation that would allow the product to evolve. Even though it remained a monolith in structure, its behaviour and architecture had been modernised.

Sometimes rebuilding a legacy system isn’t about microservices or buzzwords — it’s about applying core architectural principles that make performance, scalability, and maintainability part of the design, not an afterthought.

That’s what we did at HCD. And it’s a mindset I bring to every project I take on today.