Crawl and inventory
Every indexed URL on the existing site, plus what ranks and what has links pointing at it. This is the document the whole project is built around.
Most migration horror stories are the same story: the store moved, the URLs changed, nobody mapped the redirects, and organic traffic fell off a cliff. That part is preventable, and it’s the part we treat as the actual project.
Products, customers and order history can be exported and imported by anyone with a spreadsheet and patience. That is not where migrations go wrong.
They go wrong at the URL layer. Shopify enforces its own URL structure — /products/, /collections/, /pages/ — which almost never matches what WooCommerce or Magento was using. Every page that changes address and isn’t redirected loses whatever ranking and links it had, permanently.
On a store with a few hundred products and years of blog content, that’s thousands of URLs. Miss them and you don’t notice for weeks, by which point the traffic is gone and the recovery is slow.
What we do differently: the redirect map is built and reviewed before launch, not after. We crawl the existing site, export every indexed URL, map each one to its new address, and verify the redirects resolve on the day of the switch.
| From | Main challenge | What needs care |
|---|---|---|
| WooCommerce | Wildly variable data structure depending on plugins used | Custom fields, variable products, and permalink structures that differ per install |
| Magento | Complex catalogue and attribute models | Configurable products, customer groups, tiered pricing, and layered navigation URLs |
| BigCommerce | Closest structural match, fewest surprises | App equivalents and any custom checkout logic |
| WordPress (content) | Blog and content architecture | Categories and tags mapping to Shopify’s flatter blog model without orphaning posts |
| Wix / Squarespace | Limited export tooling | Often needs content rebuilt rather than migrated; be sceptical of anyone quoting this as a pure data job |
Every indexed URL on the existing site, plus what ranks and what has links pointing at it. This is the document the whole project is built around.
Products, variants, customers, orders, content — and what won’t transfer cleanly. You see this list before committing.
Theme and templates built to match or improve on the existing design, not a generic theme with your logo dropped in.
Every old URL mapped to a new one, reviewed by you, loaded before launch.
Imported, then spot-checked against the source — not assumed correct because the importer said ‘done’.
Redirects verified live, Search Console watched daily for the first weeks, and anything that surfaces fixed immediately.
Some short-term fluctuation is normal on any platform change — Google has to recrawl and reassess. Permanent loss is not normal, and it’s almost always caused by unmapped URLs. That’s why the redirect map is built before launch rather than after.
Order history yes, as records. Customer accounts transfer, but passwords cannot — no platform exports them in a usable form. Customers set a new password on first login, and that email needs planning into the launch.
Driven by catalogue size and how messy the source data is, not by our build speed. A clean 200-product store is a different project from a 5,000-SKU Magento install with custom attributes.
No. The Shopify store is built and tested in full while the old site stays live. The switch is a DNS change once you’ve approved everything.
We map each one to a Shopify equivalent during the audit, and flag any with no good match early — because occasionally that’s a reason not to migrate yet.
It’s cheaper to do both at once, but it makes diagnosis harder if traffic moves afterwards, because you can’t tell whether it was the platform or the design. If organic traffic is important to you, migrate first, redesign after.
Send us the current store URL. We’ll crawl it and tell you what the migration actually involves — including whether you should do it at all right now.