Enterprise API · Platform Engineering

API Proxies Management Platform:
Legacy Modernisation at Scale

Enterprise Tech Client

A cloud-native API management and integration platform serving internal developers, enterprise clients, and external partners. Inherited with 500+ open bugs and 200+ security vulnerabilities across three divergent UI versions. We stabilised, secured, and modernised it without disrupting production.

500+
Bugs resolved
200+
Vulnerabilities mitigated
3
Active UI versions
19
Modular frontend SPAs
The platform

Central API gateway for every integration

The platform lets organisations design, secure, deploy, and monitor APIs at scale. It acts as the central API gateway and orchestration layer. Every service request from every user type passes through it. Three distinct audiences depend on it: internal teams building and managing APIs, enterprise clients integrating their systems, and external partner developers consuming APIs.

All traffic is routed through a consistent gateway layer that enforces policy, handles transformations, and provides observability. Around 87 backend routes plus custom endpoints sit behind it, with the legacy UI layer alone routing approximately 150 paths.

State before involvement

500 bugs, 200 vulnerabilities, three versions to maintain

Stability
500+ open UI bugs
Accumulated across multiple UI versions. Heavy reliance on end-of-life frontend frameworks and outdated library versions that had not been upgraded in years.
Security
200+ known vulnerabilities
Authentication and token handling flaws, XSS exposure points, and input validation gaps, many sitting in legacy code that no one wanted to touch.
Architecture
Fragmented by design
A modern UI had been built on top of legacy components via a temporary compatibility shim that became permanent. Three separate UI codebases with overlapping dependencies and no shared upgrade path.
Three UI versions

On-prem legacy, on-prem modern, and public cloud

Version 1 · On-prem
Legacy UI
Contains the core business logic for API and proxy management. Built on older frontend technologies. ~150 UI routes. Stabilised and secured in place rather than replaced outright.
Version 2 · On-prem
Modern On-Prem UI
Backend-for-Frontend layer for orchestration plus 15 modular single-page applications built on shared libraries. Partially dependent on legacy components via compatibility layer, with the dependency surface being incrementally reduced.
Version 3 · Cloud
Public Cloud UI
19 modular single-page applications. More scalable and cloud-optimised. After extensive bug fixing and vulnerability mitigation, the most secure and maintainable of the three versions.
Security transformation

200+ vulnerabilities closed, without breaking anything

Every category of vulnerability was addressed systematically: authentication and token-related issues, cross-site scripting exposure, input validation and request handling flaws. The approach was surgical: unused and vulnerable legacy code was removed; outdated libraries and dependencies were upgraded; and where full replacement was not viable, specific mitigation strategies were introduced to contain the risk from legacy components.

The constraint throughout was backwards compatibility. Three versions, running in production environments with different customers, meant that no fix could break existing behaviour. Security improvements had to be introduced incrementally, tested against each version independently, and deployed without disrupting active users.

Zero-downtime deployments

Version switching in seconds, no user impact

Step 1
Versioned static assets
Each frontend application is deployed as immutable versioned assets. Every build produces a new version; the previous version remains available and untouched.
Step 2
Config-driven routing
A centralised configuration store holds a pointer to the active version. A routing layer reads this pointer and serves the corresponding assets dynamically, with no code changes and no redeployment.
Step 3
Instant switch or rollback
Promoting a release means updating the pointer. Rolling back means reverting it. Active user sessions are never disrupted. The entire switch happens in seconds with no downtime window required.
The hardest part

Modernising while keeping everything running

The hardest technical challenge was modernising a highly fragmented legacy system without being able to pause feature delivery. Multiple outdated technologies were running in parallel: AngularJS alongside modern Angular, older backend integrations alongside newer services, and a compatibility shim that had grown into a critical dependency rather than a temporary bridge.

The approach was incremental: stabilise first, then improve. Bug fixes and security mitigations ran alongside feature work. Framework upgrades were sequenced to minimise blast radius. At every stage, all three UI versions had to continue working for their respective deployment environments. There was no clean break moment. Modernisation happened gradually and continuously.

Release pipeline

On-demand releases with controlled approval gates

The pipeline runs from code commit through automated build, test, and staging deployment, followed by a validation and approval step before production. Releases are on-demand, driven by feature delivery, bug fixes, and business need rather than fixed cadence. Frontend assets are built and deployed automatically; version activation is a controlled configuration update with an explicit approval gate rather than a direct push.

Key numbers

Scale and complexity by the numbers

Frontend surface
15–19 modular SPAs
Across the two modern UI versions. Each SPA is independently deployable and consumes the platform API through the gateway layer.
Routing complexity
~87 backend + ~150 legacy routes
87 backend routes plus custom endpoints behind the gateway. Approximately 150 routes in the legacy UI layer alone, each one a potential regression surface during any upgrade.
Remediation
700+ issues closed
500+ UI bugs and 200+ security vulnerabilities resolved across all three versions, with full regression testing against each deployment environment.
Tech stack

Multi-generation stack, brought forward

AngularAngularJSGoScalaJavaBFF PatternModular SPAsVersioned deployments

Dealing with a platform in a similar state?

Legacy fragmentation, security debt, and live production pressure. We’ve navigated all three at once. Let’s talk.