A cloud migration built for peak season, not the test plan

The group ran three retail brands off a shared estate in two leased data centres. Capacity had been sized for peak, which meant the group paid all year for hardware it needed for roughly eleven days in November and December, and still ran out of headroom in two of the previous four peak seasons.

Scaling was a procurement exercise. Adding capacity took a quarter, so every peak plan was a forecast made in July and defended in December. When the forecast was wrong, the response was to disable features — personalisation, recommendations, live inventory — to protect checkout.

The three brands shared infrastructure but not architecture. A release for one brand required a change freeze across all three, because the blast radius of a bad deployment was the whole estate.

A prior lift-and-shift proposal had been costed and rejected. Moving the same architecture to rented compute would have preserved every scaling limitation while adding cloud pricing on top — a common way for cloud migration programmes to spend money without buying capability.

One data centre lease was expiring in nineteen months, which set the constraint that mattered most: the migration had a fixed end date that could not be renegotiated, and it ran straight through two peak trading seasons.

The objectives were: exit the expiring data centre inside the lease window, make capacity elastic rather than procured, decouple the three brands so releases stop being estate-wide events, hold or improve page performance at peak, and reduce annual run cost.

The migration was sequenced by risk, and the sequence deliberately did not start with the most valuable brand. The smallest of the three moved first, which meant the platform, pipeline, runbooks, and on-call model were all exercised against real production traffic before the flagship brand went anywhere near them.

Each application was assessed individually rather than migrated wholesale. Stateless web and API tiers were containerised and moved largely as they were. Batch pricing and inventory jobs were re-architected as event-driven services, because those were the components that had actually broken during previous peaks. A small number of legacy systems with no viable cloud path stayed put, connected over a dedicated link, and were scheduled for replacement separately.

Session state and caching came out of the application tier and into managed services early. Until that was done, horizontal scaling was theoretical — instances could be added but traffic could not be freely distributed across them.

Autoscaling was validated the only way worth trusting: by replaying the previous year’s peak traffic profile against the new platform at full volume, then at one and a half times that volume, before any customer request was routed to it. The first two runs found configuration limits that would have caused an outage in December.

Cost control was engineered in during migration rather than reviewed afterwards. Right-sizing, scheduled scale-down of non-production environments, storage lifecycle policies, and committed-use pricing for the stable baseline were all in place before the final wave.

Each brand landed in its own account boundary with shared platform services underneath, which is what ended estate-wide change freezes. A release for one brand now carries a blast radius of one brand.