Re-Platforming a 15-Year-Old E-Commerce Monolith for a Department Store Group
Let's Connect
Overview
What we built
A department store group's online shop ran on a 15-year-old monolith so entangled that every promotion needed a developer ticket and every holiday peak risked an outage. We replaced it piece by piece, behind a routing layer, without ever pausing trade.
In plain terms: the chain's 45 stores had a healthy online business sitting on top of a 15-year-old e-commerce monolith that nobody fully understood any more. Merchandisers could not change a price or launch a promotion without raising a developer ticket and waiting weeks. New software shipped once a quarter, after weekend-long deployment freezes, and when seasonal traffic surged the whole site could fall over. The platform had become the slowest, most fragile part of the business.
Rather than gamble on a risky big-bang rewrite, we replaced the monolith gradually. Catalogue, promotions, cart and checkout were carved out one by one into separately deployable services behind a routing layer, and a modern storefront replaced the ageing front end. Automated pipelines with feature flags took over from the quarterly freeze. The group now ships more than 20 production releases a month, merchandisers set up promotions themselves the same day, and checkout stayed up through two consecutive holiday peaks that had caused outages in prior years. Hosting and licensing costs fell by 31% once the last monolith servers were retired.
The Problem
Monolith blocking every promotion
The monolith had grown for 15 years, absorbing every promotion mechanic, integration and quick fix the business had ever needed. By the time we arrived, the codebase was so entangled that no single engineer understood the checkout path end to end. Changes anywhere could break anything, so every release demanded a weekend-long deployment freeze, and the organisation had settled into shipping once a quarter because shipping more often felt too dangerous.
The people who felt it most were not engineers. Merchandisers across the 45-store chain could not change a price or configure a promotion without raising a developer ticket, and a single promotion setup could take 3 weeks to work through the queue. Trading calendars bent around the platform's release schedule rather than the other way round, and seasonal campaigns were planned around what the system could tolerate.
Then there were the peaks. The busiest trading days of the year were exactly when the platform was least reliable: seasonal traffic spikes caused outages, and prior holiday seasons had seen checkout go down while customers were mid-purchase. Every peak season began with the same question, would the site hold, and nobody could answer it with confidence.
Quarterly releases
The entangled codebase made every change risky, so software shipped once a quarter behind weekend-long deployment freezes, and improvements queued for months at a time.
Promotions by ticket
Every price change or promotion needed a developer ticket, turning routine merchandising into a 3-week wait and pulling engineers away from real product work.
Peak-season outages
Seasonal traffic spikes overwhelmed the monolith, and holiday peaks, the most valuable trading days of the year, had a history of checkout outages.
Nobody knew checkout
The code had grown so entangled over 15 years that no single engineer understood the checkout path end to end, making every fix a gamble.
What it was costing them
The platform taxed every part of the business. Merchandisers waited weeks for promotions competitors launched in days, engineers spent their time steering around fragile code instead of improving it, and each quarterly release consumed a weekend of freeze and firefighting. Worst of all, outages landed during seasonal peaks, when every minute of checkout downtime meant abandoned baskets and lost revenue at the busiest moments of the year.
The Solution
Incremental strangler-fig replatform
We ruled out a big-bang rewrite early. Replacing a 15-year-old monolith in one move would have paused the roadmap for years and bet the whole online business on a single cutover. Instead we took a strangler-fig approach: carve capabilities out of the monolith one at a time, run old and new side by side behind a routing layer, and retire the legacy code only once each new service had proven itself in production.
Catalogue, promotions, cart and checkout each became separately deployable Node.js services, so a change to promotions could ship without touching checkout. A Next.js storefront replaced the server-rendered legacy front end, giving customers a faster experience and the team a modern base to build on. The routing layer decided, request by request, whether traffic went to the monolith or a new service, which made every migration step reversible.
Just as important was how the team shipped. Automated CI/CD pipelines replaced the quarterly release freeze, and feature flags let new capabilities go to production dark, then switch on gradually and safely. Promotion setup moved into merchandiser self-service, so the people who plan campaigns stopped depending on the developer ticket queue, and engineers got their time back for the platform itself.
Key decisions
Strangler fig, not rewrite
New services grew around the monolith and took over traffic gradually, so the business kept trading through every step and no cutover ever bet the whole shop.
Carve out by capability
Catalogue, promotions, cart and checkout became separately deployable services, so teams could change one part of the shopping journey without redeploying, or risking, the rest.
Route traffic, keep a fallback
A routing layer sent each request to the monolith or its replacement service, making every migration step observable and reversible in production.
Flags instead of freezes
Feature flags let code reach production switched off and roll out gradually, replacing weekend-long deployment freezes with routine, low-drama releases the team could ship any day.
Self-service for merchandisers
Promotion and price changes moved into tools merchandisers operate directly, ending the developer ticket queue for routine trading changes and freeing engineers for platform work.
Measurable Impact
What changed after launch
The release cycle tells the story most plainly: a platform that shipped once a quarter now sees more than 20 production releases a month, each one small, flagged and reversible. Promotion setup that took a 3-week developer ticket is now same-day merchandiser self-service, so trading moves at the pace of the calendar rather than the ticket queue.
The platform also proved itself where it used to fail. Checkout ran with zero downtime through two consecutive holiday peaks that had caused outages in prior years. And once the final monolith servers were retired, hosting and licensing costs came down by 31%, so the modern platform costs less to run than the fragile one it replaced.
Release cadence
One quarterly release behind weekend-long freezes
More than 20 production releases per month
Promotion setup
A 3-week developer ticket for every promotion
Same-day promotion setup by merchandisers themselves
Peak reliability
Holiday traffic spikes caused checkout outages
Zero checkout downtime through two consecutive holiday peaks
Platform costs
Ageing monolith with heavy hosting and licensing costs
Costs down 31% after the monolith servers retired
Headline results
Release cycle shortened from one quarterly deployment to more than 20 production releases per month
Promotion setup moved from a 3-week developer ticket to same-day merchandiser self-service
Zero checkout downtime through two consecutive holiday peaks that had caused outages in prior years
Hosting and licensing costs reduced by 31% after the final monolith servers were retired
Tech & Tools Used
What powered the build
Every tool below earned its place in this engagement. Here is the part each one played.
Next.js
Powers the new storefront that replaced the server-rendered legacy front end, giving shoppers faster pages and the team a modern base for every subsequent release.
Node.js (NestJS)
The framework behind the carved-out catalogue, promotions, cart and checkout services, keeping each one separately deployable with a consistent structure across teams.
GraphQL
Gives the storefront one query layer over the new services and the remaining monolith, so pages never cared which side of the migration their data came from.
PostgreSQL
The relational store behind the carved-out services, holding catalogue, promotion and order data as each capability left the monolith's database.
Redis
Caches hot catalogue and session data in front of the services, absorbing the seasonal traffic spikes that used to overwhelm the monolith.
Docker
Packages each service identically from laptop to production, so the growing set of deployable units stayed consistent and easy to run anywhere.
Kubernetes (AWS EKS)
Runs the containerised services and scales them out during peak trading, replacing the fixed capacity that had failed under holiday load.
GitHub Actions
Runs the automated CI/CD pipelines that build, test and ship every service, turning the quarterly release freeze into routine, frequent releases.
LaunchDarkly
Manages the feature flags that let new capabilities reach production dark and switch on gradually, including the traffic shifts of each migration step.
Datadog
Watches every service and the routing layer through migration and peak trading, so the team saw problems before customers did.
Ready to Build your Department Store Retail Business with Legacy Platform Refactoring
Ask Byte
Ask Byte
Typically replies instantly
just Now
Hi! I'm OrganByte's assistant. How can I help you today?
AI-generated content may be incorrect
