A replatform that did not lose a day of trading
A D2C apparel brand shipping about 900 orders a day
A brand outgrowing its hosted storefront, needing custom logic its platform could not express — without a migration that cost it a peak week.
- Client
- A D2C apparel brand shipping about 900 orders a day
- Industry
- Retail & Ecommerce
- Duration
- 12 weeks
- Team
- 4 engineers, 1 designer
- Year
- 2024
The situation
The hosted platform could not express the brand's bundle pricing and loyalty rules, which had been approximated with three paid apps that frequently disagreed with each other.
Page performance on mobile had degraded as apps accumulated, and mobile was the large majority of traffic.
Inventory in the warehouse and inventory on the storefront drifted apart daily, producing oversells during campaigns.
Any migration risked losing SEO rankings built over four years, and a bad cutover during a sale period would have been costly.
What we did
Migrating the catalogue before the storefront
We ran the new system as the inventory source of truth for six weeks while the old storefront still served customers, syncing one way. This surfaced every data inconsistency before customers could be affected, and it meant cutover day was a DNS change rather than a migration.
Preserving URL structure exactly
Every existing product and category URL was preserved, with 301s for the handful that had to change. We mapped the full URL inventory from the sitemap and server logs first — including URLs that ranked but were not in the sitemap, which is where this usually goes wrong.
Pricing and loyalty rules as a first-class engine
Bundle pricing, tiered discounts and loyalty accrual were built as one rules engine rather than three apps, so the rules could not contradict each other. Conflicts are resolved by explicit precedence rather than by whichever app ran last.
Cutover outside peak trading
We deliberately scheduled the switch for the quietest fortnight in the brand's calendar, with a tested rollback that stayed available for a week. It was not needed, but the decision to have it shaped how the whole migration was sequenced.
The parts that were actually hard
Problem
Four years of customer accounts had passwords hashed with the old platform's scheme, which could not be replicated.
How we handled it
We imported the hashes and verified against the old scheme on first login, then transparently rehashed to the new one. Customers never saw a reset prompt, which would have cost a meaningful share of the returning base.
Problem
The warehouse system exposed no API and exported fixed-width text files on a nightly schedule.
How we handled it
We wrote a parser for the fixed-width format and moved to a 15-minute polling cycle, which the warehouse system tolerated. Not elegant, but it reduced the inventory drift window from a day to a quarter of an hour without asking the client to replace a working warehouse system.
What shipped
- Custom Next.js storefront with the existing URL structure preserved
- Unified pricing, bundle and loyalty rules engine replacing three apps
- Fifteen-minute inventory synchronisation with the warehouse system
- Transparent customer account and password migration
- Tested rollback plan retained for a week after cutover
Outcomes
- Cutover completed without a day of lost trading and without a rollback
- Mobile page performance improved substantially after removing the accumulated app scripts
- Oversells during campaigns became rare once the sync window dropped from daily to quarter-hourly
- Organic traffic recovered to pre-migration levels within about six weeks, consistent with a clean URL migration
Outcomes are described qualitatively where no clean measured baseline existed before the work started.
Built with
Services involved
Have a problem shaped like this one?
Tell us what you are dealing with. We will come back with a scoped estimate and an honest view on whether we are the right fit.