Leaving Adobe Commerce
Instead Of Upgrading It.
Replacement of a six-year-old Adobe Commerce build with a Shopify Plus storefront, a re-modelled catalogue and delivery logic that resolves method per line.
-25
%
Platform Running Cost
9
Integrations Re-Pointed
600 → 0
Monthly Mixed-Order Interventions
Client Profile
Baby and Nursery Equipment
~£26m revenue · ~11k orders/m at peak
Own D2C storefront on Adobe Commerce.
Ships to UK.
Single in-house distribution centre handling parcel, oversized parcel and palletised furniture, with large-item home delivery bought from a specialist network.
One order in four contains a large or palletised item, and those orders carry roughly three fifths of revenue
The Challenge
Nothing on the site could be changed without the agency. The compatibility rules governing the highest-value lines, which components fit which main units, had been written into a custom module six years earlier rather than held against the products, so putting a new line, component or colourway on sale meant a development ticket and a slot in someone else’s queue. That was a build decision rather than a platform limitation, but it was where the business had ended up, and range launches were paced by the queue rather than by the buy.
A version upgrade was falling due, and on a build this heavily customised that is a project rather than a task. It would have consumed a substantial share of a year’s change budget, restored technical currency and nothing else, and left the brand on the same licence, the same hosting and the same retainer. The hiring market for those skills had thinned to the point where the retainer was not really optional.
Underneath sat the shipping module. It decided delivery method against the whole basket, so an order combining an in-stock accessory with furniture on a booked slot had the slower, more expensive method applied to everything in it, and the accessory was held until the furniture was ready. Customer service split those orders by hand in the admin, raising a second despatch instruction and correcting the delivery charge, at around 600 orders a month.
Why EQ50 DIGITAL
The remit was to test whether migration was commercially justified before designing anything, then design the catalogue and delivery models, build the storefront, and own every integration through to handover.
Shopify Plus brings the checkout, the infrastructure and the native delivery-group behaviour. The delivery network brings furniture slot availability. The ERP remains the source of truth for stock and price.
EQ50 DIGITAL designs the model those three have to agree on, builds the storefront against it, and owns the seams.
The EQ50 DIGITAL Approach
01
Clarify the business priorities
A session with Ecommerce, Merchandising, Operations, Customer Service and Finance set the order: reduce the cost of running the estate, move range configuration into merchandising, and stop the mixed basket being resolved by hand.
The boundary was drawn in the same session. No warehouse operating-model redesign, no carrier retender, no 3PL transition. The system and procedural changes needed to receive and process a multi-despatch order were in scope, because the delivery design creates them and leaving them out would have handed operations a problem rather than a solution.
02
Diagnose and scope
EQ50 DIGITAL inventoried the estate: every custom module, every integration, and what the shipping module actually did as opposed to what it was documented to do. Three months of order data sized the mixed-basket population and the manual split volume by value band and by category.
Two lighter fixes were tested before migration was recommended. Upgrading in place would have cleared the version position and touched neither the catalogue nor the delivery constraint. Re-modelling the catalogue where it stood would have released merchandising, and it was the closer call, because the platform was never the reason that data sat in code.
Both were rejected on the same arithmetic. Neither touches the licence, the hosting or the retainer, so neither changes the run rate, and the catalogue work has to be done again whenever the estate eventually moves. Set against the migration, the upgrade is not an alternative but a cost avoided, and counting it that way is what brings payback inside two years. That dependency was stated plainly before the recommendation was approved, because without it the numbers do not support the project.
Catalogue analysis set the timeline. Around 2,000 products and 9,000 variants, of which the bundle and compatibility constructs have no direct equivalent in a product-and-variant model and required re-design rather than record-for-record translation.
03
Design the solution
Compatibility moved out of code and into structured product data, so a merchandiser sets up a new line or colourway and puts it on sale the same day. The templates render those relationships automatically.
The warehouse holds three despatch classes: standard parcel, oversized parcel and palletised furniture. The checkout holds two delivery groups, parcel-able and furniture, because the group decides where the platform splits a basket. Three groups would have split baskets the warehouse despatches as one consignment, at the brand’s cost.
The split is native behaviour and was configured rather than built. It also fires on fulfilment date, which matters where furniture runs on lead time. Accelerated wallet checkouts were tested separately, since they do not surface the full multi-shipment experience.
Two things were built. Rates are calculated per delivery group and summed, which overcharges a mixed basket, so a shipping discount function corrects the combined charge. And a booked furniture slot is not a native construct, so availability is surfaced through a checkout extension against the delivery network’s API.
04
Deliver the change
The build ran in dependency order. The catalogue model was locked before templates, because the templates render from it. The order contract between storefront, middleware, ERP and warehouse was frozen before downstream integration began, so the despatch instruction format did not move under the operations team.
Nine integrations were re-pointed in three groups. Commercial first: ERP, warehouse, payment gateway. Customer-facing second: email, reviews, service desk, on-site search. Reporting and slot availability last: analytics, then the delivery network’s API.
Data migration ran as a full test load four weeks out, then a delta at cutover. Passwords cannot be imported, so an account activation journey was scheduled ahead of launch. Redirects were generated from the legacy catalogue and reviewed by hand where bundle pages had no equivalent.
Go-live ran in a low-traffic window, with the old estate held as a fallback and documented reconciliation procedures for the point after which live orders make a return impossible. Teams were trained before launch. Hypercare ran four weeks, then the old estate was decommissioned and the retainer ended.
Key Decisions & Trade-Offs
Re-model the catalogue rather than translate it.
Replicating the legacy structure would have got the range live faster and preserved the same dependency on specialist development. The model was rebuilt instead.
It was the longest task in the programme and required merchandising to validate compatibility data across the full range, which is why the timeline was measured in months rather than weeks.
Configure the platform’s own splitting behaviour rather than build a shipping engine.
A custom engine would have given complete control and recreated the position the brand was leaving, where the logic sat in code only a specialist could change.
Configuring native behaviour means inheriting the platform’s rules: the customer cannot choose how their basket splits, the cheapest combination is selected by default and cannot be overridden in the brand’s favour, and local delivery has to stay switched off because it suppresses the multi-shipment display.
The handling correction also runs as an automatic shipping discount, so it has to be configured against every promotion the brand runs.
The Outcomes
Same Day
A new line, component or colourway goes on sale the day the buy lands, where each one previously waited on a development ticket.
Full Catalogue
Delivery method resolves per line across every product, so a mixed basket no longer forces one method across the whole order.
600 → 0
Manual order splits by customer service ran at roughly 600 a month before the migration. None were required in the first full quarter after launch.
-25%
Contracted platform, application, middleware and external support cost in the first full operating year against the equivalent pre-migration baseline. Payment processing and the one-off migration investment were assessed separately.
The Handover
The client owns the storefront, the catalogue model, the delivery configuration, the middleware and the integration documentation. Compatibility, despatch classification and delivery-rule parameters are merchandising and operations tasks now, not development tickets.
EQ50 DIGITAL handed over the integration contracts and support responsibilities, the configuration guidance for catalogue and delivery, the promotion and shipping-discount dependency, the monitoring runbooks, and the cutover and reconciliation procedures.
A new delivery method or a second market still warrants an impact assessment, and the client now has everything needed to run one without re-engagement.