You are not choosing a platform. You are choosing who takes responsibility for thousands of URLs, years of order history, a payment integration nobody documented, and one cutover window with revenue running through it. That is a bigger decision than a feature comparison. Here is what actually breaks in a replatforming, roughly in the order it breaks.
Redirects at catalogue scale: the most expensive mistake, and the last one you notice
A catalogue is not a homepage. A mid-sized store has product URLs, category URLs, the filtered and paginated variants of those, blog posts, and a long tail of discontinued SKUs that still hold links. The map is only trustworthy if you build it from four sources at once: the old sitemap, twelve months of server logs, the Search Console page export, and a backlink export. The sitemap alone misses precisely the URLs that matter, such as the dead product page from 2021 that a magazine linked to once.
Then the mechanics. Every redirect returns 301, resolves in one hop, and keeps the query strings your ad platforms append. Chains are where migrations bleed quietly: old URL to new URL to canonical to https. Platform redirect tables cap out on row count and offer no pattern matching, so a rule covering all of /product-category/* to /collections/* belongs in edge middleware or a CDN bulk redirect list, with a static file for the exceptions. Shopify also imposes its own /products/ and /collections/ prefixes and serves a product under both its canonical path and its collection path, so canonical tags matter as much as the redirects.
Measuring is not optional. Crawl the old site before cutover, crawl the same URL list after, diff the status codes. Watch Search Console for a rise in Not found and Page with redirect, and read raw logs for Googlebot hits returning 404. Recovering from a bad map takes weeks, and every one of them costs sessions you do not get back.
Product data, order history, and the things that genuinely will not move
WooCommerce exports fail in a handful of recognisable ways. Encoding is the classic: a database dumped as latin1 and reimported as UTF-8 turns every accented character into mojibake, and you find it in product descriptions after go-live. Serialised PHP arrays in wp_postmeta break the moment somebody runs a naive search and replace on the domain, because the declared string lengths stop matching. Product images are often referenced by absolute URL inside description HTML, so they keep pointing at the old host long after you think you are finished.
Shopify has its own shape. Options per product are capped, variant ceilings are a hard platform limit worth checking against current documentation rather than assumed, handles have to be unique, and metafields end up carrying the data your storefront actually needs. Anything modelled as a custom post type or an ACF field group has no native equivalent, so it needs a decision, not a mapping.
Some things genuinely do not move. Password hashes cannot be transferred between platforms, so every customer resets, and that email belongs in the launch plan rather than in the scramble after it. Review apps export in their own formats, and the verified buyer flag usually depends on order IDs that are about to change. Loyalty balances, gift cards and store credit each need a reconciliation plan agreed before cutover, not discovered during it.
Payments, tax rules, and the integrations nobody wrote down
Payments are where a migration stops being a web project. Stored cards are vaulted with your payment provider under PCI rules, so they can sometimes move between accounts at the same provider through that provider's formal migration process, but they never travel in a CSV. If you are leaving Shopify Payments for your own Stripe account, assume saved cards stay behind and plan the re-collection. Subscriptions are harder: an active contract carries a payment mandate, and in Europe the SCA authentication is bound to it. Migrating a subscriber base is a separate project with its own timeline.
Tax and shipping rules are the second trap. Tax-inclusive display in the EU against tax-exclusive in the US, rounding applied per line or per order, VAT OSS registration, per-jurisdiction US sales tax: these move order totals by amounts small enough to pass review and large enough for your accountant to find. Reconciliation between store and accounting system has to be tested against real historical orders.
Then the integrations nobody documented. You do not find those by asking the client. You find them by reading the current platform's webhook subscriptions, its private app and API key list, and its access logs. That is where the ERP sync, the accounting connector, the automation built by somebody who left, and the Merchant Center feed whose item IDs must not change all surface. Order numbering restarts as well, so anything keyed on order ID needs a legacy ID column before it needs anything else.
Running old and new in parallel, and what a real cutover looks like
The safest cutover happens in slices. A Next.js storefront can sit in front of an existing commerce backend, so you can split by path at the edge: product pages served by the new head, checkout still handled by the platform, everything else untouched. Split by path and never by traffic percentage, because a customer whose cart exists in two systems becomes a support ticket. Cart and session state is the real constraint, and the strongest argument for keeping your current backend and replacing only the storefront.
The cutover itself is a runbook with named owners and checkboxes, not a series of decisions taken live. Lower the DNS TTL a day ahead. Freeze catalogue writes. Sync the delta of orders placed during the freeze. Make rollback a routing change rather than a redeploy, and test it before you need it. Pick the window from the store's own analytics: a French store and one selling to the US west coast have different quiet hours.
Then the days after. Transactional email is the item most often forgotten: a new sending domain needs SPF, DKIM and DMARC alignment plus a warm-up, or order confirmations land in spam and support drowns. Refunds on pre-cutover orders still have to be issued on the old platform, so keep that admin and its gateway alive through the refund window. Re-point webhooks, resubmit the sitemap, validate structured data, check consent mode and the conversion tags on every ad platform, and compare checkout completion against your own pre-migration baseline.
When replatforming is the wrong answer, and when not to hire us
Replatforming is often the wrong answer, and the cases are worth naming.
If your store is slow because of a heavy theme, unoptimised images and six marketing scripts in the head, a performance pass on your current platform costs far less than a rebuild and captures most of the win. Measure before assuming the platform is guilty. If you are on WooCommerce and the real problem is shared hosting, a host with a proper object cache, tuned PHP-FPM and a CDN in front will feel like a new site.
Shopify is genuinely a good product: hosted, PCI compliant, fraud screening, an app for nearly everything, no maintenance on your side. At the time of writing the cost structure is a monthly plan, a per-transaction fee when you use an external payment provider, a charge for built-in tax calculation in some regions, and Plus quoted per contract rather than published. Check the current figures, because they move. At the standard tiers the platform fee is rarely what holds a business back. Standard catalogue, small team, no unusual logic: stay.
Headless takes things away too. You lose the theme editor, so a marketer who reworks the homepage weekly now needs a developer or a CMS, which is one more system to run. Many Shopify apps inject through theme app extensions that do not exist on a custom storefront, so bundles, page builders and some subscription tools have to be replaced.
Do not hire us if nobody on your side will own the code afterwards, if you need scheduled calls, or if you want to migrate in the fourth quarter. Ask us and we will say so if staying put is the better call.
How two people in Dijon run a migration for a client in California
We are two people, working from 9 rue Jean-Jacques Rousseau in Dijon, France, and nowhere else. Robin Monteiro writes the code (Next.js, React, the data work) and Florian Loppion handles marketing and search. No account manager, no delivery layer between you and the work. That is the trade: a small team, and direct access to the people doing it.
Everything happens in writing, by email, with a reply inside 24 business hours. No calls, no video, no scheduled slots, not even as an option. On a migration that is an advantage rather than a constraint. A redirect map is a file. A field mapping is a spreadsheet. A cutover is a runbook with owners and checkboxes. None of them improve by being talked through at an hour that suits one party and wrecks the other. Nobody in California is asked to approve a DNS change at 3am, and nine months later, when someone asks why the product URLs lost the /shop prefix, the answer is sitting in a thread with a date on it.
What that asks of you: send context in one message rather than five, grant read access early (platform admin with a scoped role, DNS registrar, payment provider dashboard, analytics, Search Console, the repository), and write approvals as approvals, because there is no meeting where a nod counts as sign-off. Pricing is on request, there is no mandatory subscription, and the code, the accounts and the domain stay yours throughout. References, all French SMEs: Chouchou Ribeyre, Au Petit Detail, LB Athletic, Mediavocats, Vectosolve.
