An anonymised account of a real client engagement. The client, the product and the technology stack are withheld under NDA; the modernisation work and the results described here are real.
The situation
A specialist engineering-software company ran a sophisticated, browser-based design application — the kind of tool where users open large, complex models, edit them in real time, and commit their work back. The product was strong; the architecture beneath it capped its growth. A brand-new database and a dedicated, always-on server had to be stood up for every customer — 150+ of them — and the application ran coupled to its database in a single tier, with no way to scale out and no caching at any layer.
The constraint
The honest constraint was not that the technology was old. It was that the shape of the system capped the shape of the business: a server-per-customer model does not scale commercially, and a single coupled tier does not scale technically. A full rewrite of a live, business-critical product is exactly the big-bang gamble that sinks modernisation programmes — so the work had to make the platform safely changeable without taking it offline or betting the product on a rebuild.
What we did
We sequenced quick wins before rewrite, working on a controlled branch off the latest stable release with unit tests mandated so existing behaviour never broke. Each step was delivered to a test environment and proven before it earned its way to production. Nothing was a big bang.
- Decoupled the application and database into independent, separately scalable tiers.
- Containerised the application onto managed, autoscaling infrastructure with blue/green deployment behind load balancing.
- Codified the whole environment as infrastructure-as-code and built a one-run CI/CD pipeline from build to deploy.
- Migrated the database to a managed, resilient service with failover.
- Introduced true multi-tenancy in the application — one shared codebase serving many customers, with each tenant’s data isolated, requests routed per tenant, and caching scoped per tenant.
- Removed the two blockers to horizontal scaling: a licensing model tied to a specific host, and a dependence on local disk (every file category moved to shared storage).
- Shipped it behind a feature flag, so old and new behaviour ran side by side — backwards-compatible, reversible, and de-risked.
Where it’s going
With the platform now elastic and multi-tenant, later phases of the programme apply AI and bespoke optimisation algorithms to the core design work itself — accelerating the most demanding parts of the user’s job. It is the pattern we advocate: make the foundations safely changeable first, then let AI compound on a platform that can carry it, without surrendering the gates that keep change trustworthy.
The results
- New-customer setup fell from ~4–5 days of hands-on work to 1–2 hours through an end-to-end automated provisioning pipeline.
- Run-time infrastructure was cut by roughly 85–90% — from a dedicated, always-on server for each of 150+ customers to one shared, autoscaling cluster running at about a tenth of that compute at idle and an eighth at peak load.
- 150+ customers, once each on an isolated stack, are now served from one shared multi-tenant platform with per-tenant data isolation preserved.
- The whole rollout was zero-downtime and reversible, behind a feature flag.
Why it worked
No rewrite. No big bang. We changed the architecture exactly enough to lift the ceiling — decouple, make elastic, make multi-tenant, automate the path to production — each step small, tested, reversible, and earned. Ivaaya set the architecture and the sequencing; disciplined engineering delivery ran it to production.