Replatforming
Replatforming, scoped honestly.
Moving platforms is mostly a decision problem wearing a data problem's clothes. Here is when it is worth doing, the sequence that survives contact with a real catalog, and the one thing every migration scope still leaves out.
No login. No credit card.
First: should you replatform at all?
More replatforms are started than finished, and the ones that stall usually failed this question rather than the execution. The honest test is whether you can name the cost of staying. If you cannot put a number on it, you are buying a rebuild and calling it a migration.
Usually worth it
- Your platform's maintenance is consuming engineering time that has nothing to do with selling
- You cannot hire for the stack any more, or you are down to one contractor who knows it
- An end-of-life or forced-upgrade deadline is already costing you either way
- Checkout conversion is losing to a platform-level constraint you cannot fix
Usually is not
- The real problem is the theme, and a redesign would fix it for a fraction of the cost
- One missing feature is driving the decision — price the app or the build first
- The current platform is unloved but stable, and nobody can name the cost of staying
- You are mid-peak-season, or within a quarter of one
The paths, in detail.
Each guide covers what transfers, what has no equivalent on the destination and must be rebuilt, and where that specific path puts your visibility at risk.
Any platform → Shopify
Shopify migration services, honestly scoped.
A Shopify migration service moves catalog, customers and order history onto Shopify, rebuilds the storefront, and maps the old URLs to new ones. The category splits into three groups that are priced very differently and are not interchangeable: self-serve tools that move data and nothing else, specialist migration firms, and full ecommerce agencies who treat the migration as one workstream inside a rebuild.
Magento / Adobe Commerce → Shopify
Magento to Shopify, without the surprises.
Magento gives you a data model that assumes you will extend it. Shopify gives you a data model that assumes you will not.
WooCommerce → Shopify
WooCommerce to Shopify, content included.
WooCommerce migrations have a complication the platform-to-platform guides tend to skip: the store is only half the site. The other half is WordPress — posts, pages, and often years of content that is doing more for your search and AI visibility than the product pages are.
The part nobody scopes
Your citations do not move with your data.
Every migration checklist in this category was written against Googlebot, and most of them are good at it. None of them cover what a cutover does to the citations you hold inside ChatGPT, Perplexity, Gemini and Copilot — because for most of the time these checklists have existed, that was not a place demand came from.
The mechanism is simple enough. Assistants cite specific URLs. Change the URLs and those citations point at pages that are gone. They do not re-read on your launch date — each surface re-crawls on its own cadence — so a redirect map signed off on crawl stats can still leave an assistant quoting a dead page for weeks. Meanwhile the new theme rebuilds your structured data from scratch, because on most platforms markup is theme-level, and nobody diffs it.
None of this is hard to handle. It is just not on the list you were handed.
Before you freeze the old store
Take a citation baseline while the old site is still live. Which assistants name you, for which questions, and which URLs do they cite? After the cutover that record is unrecoverable — the pages those citations point at will not exist, and you will have no way to tell whether you lost ground or never held it.
During the URL map
Redirect maps are usually built for Googlebot and signed off on crawl stats. Assistants resolve citations on their own schedule and do not re-crawl on your launch date, so a 301 that satisfies Search Console can still leave an assistant quoting a page that now bounces. Map the specific URLs you were cited on first, not just the URLs with sessions.
When the new theme ships
Structured data is theme-level on most platforms, so a replatform silently rebuilds it. Product, Offer, availability and price markup that an agent could read on the old store may be absent, partial, or rendered client-side on the new one. Diff the emitted JSON-LD before and after — not the theme's feature list.
After cutover
Re-run the same prompt set you baselined. Recovery is not instant and is not uniform across assistants: each re-reads on its own cadence, so a surface that looks unchanged in week one can move in week six. Hold the measurement open for a quarter before calling it.
The baseline is the step with a deadline attached — it is the only one that becomes impossible after cutover. Our free Citation Rank scan gives you that record, and the agentic readiness scan checks what an agent can currently read from your catalog. How we measure is on the methodology page.
Who should do the work.
We do not migrate stores — we are not a migration tool, vendor or agency, and a page that pretended otherwise would waste your time. What we do sits underneath: whether an agent can read your catalog, whether assistants recommend you, and whether an agent-driven purchase completes.
The migration itself belongs with someone who does it full time. Three groups sell it, and they are not interchangeable: self-serve data tools that move records and stop there, specialist migration firms, and full ecommerce agencies who treat migration as one workstream in a rebuild. Brief all three against the same written scope — including your extension list — and the spread in what comes back will tell you more than the proposals do. The questions worth asking are the same ones we set out in the agency buyer’s guide.
A replatform is the cheapest moment to get the agent layer right, because your catalog structure and templates are already open — doing it later means opening them twice. If you run migrations for clients, that layer is available to deliver on our platform through the partner programme.
Questions
Ecommerce replatforming is moving a store from one commerce platform to another — for example Magento to Shopify, or WooCommerce to Shopify. It covers migrating catalog, customer and order data, rebuilding the storefront on the new platform, mapping every old URL to a new destination, and re-integrating the systems that read from or write to the store. It is usually treated as a data project, but the data is rarely the hard part: the expensive work is replacing platform-specific logic that has no equivalent on the destination.
The variables that actually drive the timeline are the number of integrations writing into your store, the amount of logic sitting in platform-specific extensions, and the size of your indexed URL footprint — not your SKU count. A catalog of a few thousand products with two integrations is a fundamentally different project from the same catalog with fifteen. Ask any vendor to quote the data migration and the storefront rebuild as separate lines; a single blended number usually means the second half has not been scoped.
Some volatility while search engines re-crawl and re-evaluate is normal. How much, and for how long, is decided mostly by the redirect map and by whether the new templates preserve the content and markup the old pages ranked on. The most common cause of permanent loss is not a broken 301 — it is an indexed URL that nobody mapped because it had few sessions, and so never appeared in the analytics export the map was built from. Build the map from a full crawl of indexed URLs instead.
Assistants cite specific URLs. When those URLs change, the citations point at pages that no longer exist, and each assistant re-reads your site on its own schedule rather than on your launch date — so a redirect that satisfies Search Console can still leave an assistant quoting a page that now bounces. Structured data compounds it: on most platforms markup is theme-level, so a replatform rebuilds it from scratch. The practical answer is to baseline which assistants cite you, and on which URLs, while the old store is still live. After cutover that record cannot be reconstructed.
No. We are not a migration vendor, tool or agency, and we do not move stores. We work on the layer underneath — whether an agent can read your catalog, whether assistants recommend you, and whether agent-driven purchases complete. A replatform is the cheapest moment to get that layer right, because the catalog structure and templates are already open, but the migration itself belongs with a partner who does that work.