Platform rebuild · Modanisa · 2018 – 2022

Rebuilding eight core domains without stopping the store

An international fashion platform whose core had grown into one brittle block.

8core domains moved to a new architecture in sequence; checkout conversion up ~18%

In short

Situation: A high-traffic, international fashion e-commerce platform in which listings, checkout, basket, homepage, search, warehouse, customer service and supplier functions had grown into one block. Every change risked everything. Decision: No big bang. Rebuild the core domain by domain on a modern architecture, highest impact first, with the old platform running alongside until each cut-over. Performance, scalability and reliability written into the acceptance criteria. Result: Eight core domains on one architecture. Releases no longer put the whole store at risk, and the company had a platform it could change again. My role: Product manager for the programme: scope, sequencing and the alignment between engineering, business and design.

My role: E-Commerce Product Manager
Period: 2018 – 2022
Scale: 8 core domains · international customer base
Key figure: 8 domains · ~18% conversion lift

Situation and complexity

The platform served customers in many countries and carried real traffic peaks around campaigns. Its core (listings, checkout, basket, homepage, search, warehouse, customer service and supplier functions) had been built up over years into one tightly coupled block.

That coupling was the business problem. A change in search could break checkout; a supplier-facing fix could delay a campaign. Releases were cautious because they had to be, and the cost showed up as slow feature delivery and operational fragility exactly when trading mattered most.

Options on the table

Big-bang rewrite
Rejected. It concentrates all risk on one launch date.
Keep hardening the monolith
Rejected. It would have bought time, but every change would still have touched everything, and delivery speed would not have recovered.
Domain-by-domain rebuild, old platform alongsideChosen
Each domain moves when its own cut-over criteria are met, and there is always a way back.

The decision and how it was organised

Impact and risk set the sequence together. The domains that blocked the most change moved first, and nothing moved without named cut-over criteria. Performance, scalability and reliability went into each domain's acceptance criteria, so “modern architecture” meant something that could be tested.

Every domain had an explicit owner, and business stakeholders saw the sequence and its trade-offs before work started. I decided the sequence and the criteria. The engineering teams did the rebuilding.

Cosmetic redesigns that would have ridden along with the migration were deliberately left out. They would have hidden regressions behind a new look.

Result

8 → 1eight core domains on one modern architecture

Domain by domaincut-overs in sequence, with the old platform running alongside

~18%conversion lift from A/B tests on the checkout flow

Performance and reliability figures are shared in conversation as relative changes.

What went wrong, what I learned

Intent: Move the whole core in the planned sequence.

What went wrong: Hidden dependencies between domains came to light only mid-programme and forced us to re-sequence. Some supplier-facing functions moved later than the business wanted.

What changed afterwards: A dependency map is now the first deliverable of any migration I run, before the sequence is promised to anyone.

Get in touch