A retail client came to us with a WooCommerce store they had outgrown. The catalogue had expanded, the plugin stack had accumulated, and every fix made the next one harder. Pages were slow, configurable products were a workaround rather than a feature, and every order was re-typed by hand into their ERP.
The client is under NDA, so this write-up covers the engineering rather than the brand.
The problem behind the slow pages
Speed was the complaint, but speed was a symptom. The store had reached the point where each new capability had been solved by installing another plugin, and each plugin brought its own scripts, styles and database queries. No single one was the culprit. Together they made every page heavy.
Two other problems mattered more commercially:
- Configurable products didn't really work. The catalogue had items with several dependent options, and the platform's variant model forced them into combinations that were slow to browse and easy to mis-order.
- Orders were entered twice. Every sale was keyed into the ERP by a person. That is a cost per order, it introduces errors, and it puts a ceiling on volume that has nothing to do with demand.
Why replatform rather than repair
We do not recommend replatforming lightly — it is disruptive and the safer-sounding option is usually to optimise what exists. We audited the store first and concluded the opposite here: the plugin stack was load-bearing, and unpicking it would cost more than a clean build while leaving the variant and ERP problems untouched.
Moving to Shopify meant the checkout, payments, PCI scope and hosting stopped being the client's problem, and our effort went into the parts that actually differentiate the store.
What we built
A custom Liquid theme, built lean. No page builder, no plugin sprawl. Sections and metafields so the client's team can rearrange pages without a developer, and a deliberately small asset budget — scripts loaded only on the templates that need them.
A product configurator in React, embedded in the theme. Dependent options are modelled as rules rather than as a multiplied list of variants, so invalid combinations cannot be selected and the page stays responsive as options change. This is the piece that would have been an awkward compromise on any off-the-shelf app.
An ERP integration over a custom API. Orders flow to the ERP automatically and inventory flows back. Two details did most of the work here: every message carries an operation ID so a retried delivery is recognised rather than duplicated, and failures queue for retry instead of being dropped. An integration that loses an order quietly is worse than no integration.
Migrating without going dark
A store cannot be offline, and it cannot lose its search rankings. We ran the migration in phases with a rollback plan at each step:
- Products, customers, historical orders and content migrated into a staging store, then reconciled against the source rather than assumed correct.
- Every existing URL mapped to its new equivalent, with redirects in place before cutover — this is what protects the SEO value built up over years.
- Payments, taxes, shipping rules and analytics verified against a pre-launch checklist on staging.
- DNS cut over, then close monitoring through the first 48 hours.
The result was a zero-downtime migration: no maintenance window, no lost orders, no period where the store was unreachable.
Results
- 60% faster page load — mostly from what the new theme does not ship.
- 35% increase in conversion rate.
- Zero downtime through the migration.
The conversion figure is worth reading carefully. Some of it is speed, since slow pages lose buyers before they see the product. But a meaningful part is the configurator: when customers can only pick combinations that actually exist, fewer of them abandon the page and fewer orders arrive wrong.
What we would tell the next client
Audit before you replatform. We have talked clients out of migrations where optimising the existing store was the better answer, and we would rather do that than sell a rebuild nobody needed.
Then, if you do move: treat redirects as a launch blocker, not a follow-up task, and make every integration safe to retry from day one. Those two decisions are cheap at the start and expensive to add later.
Planning something similar? Tell us about your store and we'll start with an audit.