Case study · Legacy modernization
Re-platforming a live SaaS with no maintenance window.
A fashion-technology platform had outgrown the servers it was built on. We moved it onto modern managed infrastructure without a cutover weekend, without touching the running system, and without customers noticing anything at all.
01 The situation
The product ran on two long-lived virtual machines — one for the web application, one for the API. They had been up for years. The people who originally configured them had moved on, and nobody was entirely confident about what was installed where.
The platform is not a simple CRUD app. It carries live chat, real-time notifications and scheduled background jobs that run against production data. That makes it exactly the kind of system where a bad deployment is visible to every user at once, immediately.
The business needed to be on modern, managed, reproducible infrastructure. What it could not afford was the usual way that goes.
02 The risk we were hired to avoid
Most re-platforming projects end in a cutover weekend. A maintenance window, a late-night switch, a rollback plan nobody has ever executed, and a Monday morning spent finding out what the staging environment failed to reproduce.
That plan has two problems. It concentrates every unknown into the few hours you are least able to think clearly, and its fallback — "put it back" — is the one step that has never been rehearsed.
03 How we approached it
-
i
Build the safety net before touching anything
Before a single piece of infrastructure changed, we captured the system's existing behaviour in automated tests — including the scheduled jobs that had never had an executable description of what they did. Type checking, security scanning and coverage were turned from advisory reports into checks that actually block a broken change. This is the unglamorous half of the project and the reason the rest of it was uneventful.
-
ii
Build the new production alongside the old one
The entire new platform — both environments, load balancing, certificates, secrets, identities and deployment pipeline — was stood up in parallel and validated against real production data, while serving no customers. The original servers were never modified. Not one configuration change, not one restart.
-
iii
Reduce the cutover to one reversible step
Because the old system was untouched and the new one was already proven against real data, the remaining move is a single DNS change per environment — reversible in minutes, with the original platform still running warm behind it. No maintenance window, no weekend, no unrehearsed fallback.
04 What the business got
-
A migration nobody had to stay up for
Every unknown was resolved in daylight, on real data, with the existing platform untouched and available throughout.
-
Deployments that check themselves
A new version now starts at zero traffic, is smoke-tested automatically — including its real-time features, not just a health check — and only receives customer traffic once it has proven it works. A failing release never reaches a user.
-
Latent defects found before customers met them
Running the new platform in parallel surfaced real problems that had been invisible — including one piece of background work quietly running against production data, and a login fault that users had been hitting occasionally and could never reproduce on request.
-
Security that holds up to a questionnaire
No long-lived cloud credentials anywhere. Each service runs under its own least-privilege identity, deployments are pinned to exact immutable builds, and production releases require a second person's approval.
-
A system the team can operate
Infrastructure defined as code and reproducible, with written runbooks and developer guides — so the knowledge lives in the repository rather than in one contractor's head.
05 The detail, in the open
We wrote this engagement up honestly — including the things that went wrong and what they cost to fix. Thirteen articles covering the quality baseline, the parallel build, and four failures that would never have paged anyone: a deployment check that was validating its own input, a rejected release that never stopped running, a credential quietly counting down to expiry, and an edge nobody could see.
If you want to know how a supplier actually works, read what they publish about their own mistakes.
06 Contact
Running something important on infrastructure you have outgrown? The move does not have to involve a weekend and a held breath. Get in touch.
connect@happy.software