REPLATFORMING · 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. Most disappointment comes from buying the first and expecting the third.
What transfers
- Products, variants, images and collections
- Customer records, with consent state where the source exposes it
- Historical orders, usually as read-only records
- Basic URL mapping for products and categories
What does not
- Anything living in a source-platform extension — most tools only read core objects
- Discount and promotion logic, which rarely has a Shopify equivalent and is usually rebuilt by hand
- Customer passwords, which never transfer; your users reset on first login
- Subscriptions and stored payment methods, which are a separate gateway-level migration
- Theme-level structured data, rebuilt from scratch by the new theme
The sequence.
Scope and audit
Inventory what exists: SKU count, variant depth, custom fields, extensions in use, and every integration writing into the store. The extension list is where migration quotes go wrong.
Data mapping
Map source fields to Shopify's model. Metafields absorb what does not fit natively — decide this before the trial import, because rework here is expensive.
Trial import
Import into a development store and reconcile counts field by field. A row count that matches is not a clean import; spot-check variant pricing, inventory and image order.
Storefront build
Theme, navigation, templates. Structured data is decided here whether or not anyone discusses it.
URL map and redirects
Every indexed URL gets a destination or an explicit decision to drop it. This is the step that determines whether search traffic survives.
Cutover and hold
DNS switch, then a monitoring window. Plan the measurement before launch day, not after it.
The part nobody scopes
What this move does to your AI visibility.
Migration scopes are written against Google. Ask any vendor what happens to the pages assistants cite you on, and most will hear the question as SEO — because for a decade it was. The gap is not their competence; it is that the category's checklist predates assistants being a meaningful source of demand.
The mechanism is the same on every path. Assistants cite specific URLs; change the URLs and those citations point at pages that are gone. They re-read on their own cadence rather than on your launch date, so a redirect map signed off on crawl stats can still leave an assistant quoting a dead page for weeks — while the new theme rebuilds your structured data from scratch, because markup is theme-level on most platforms.
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.
Only the baseline has a deadline — it is the one step that becomes impossible once the old store is dark. The free Citation Rank scan records it, and Visibility Score is where the measurement lives afterwards. House of Zelena is what that loop looked like end to end.
Who should do this work.
Not us — we do not migrate stores, and we are not a migration tool, vendor or agency. What we do sits underneath the migration: whether an agent can read your catalog, whether assistants recommend you, and whether an agent-driven purchase completes. A replatform is simply the cheapest moment to get that right, because your catalog structure and templates are already open.
For the migration itself, brief specialist firms and full agencies against the same written scope — including your extension list. The agency buyer’s guide covers the questions worth asking and the answers that should end a conversation. If you run migrations for clients, the agent layer is available to deliver on our platform via the partner programme.
How we connect to these platforms
Questions
It depends entirely which of the three groups you are buying from, and any figure quoted without seeing your extension list is a guess. Self-serve data tools price per record and stop at data. Specialist migration firms price the project. Full agencies price a rebuild in which migration is one workstream. Get all three to quote against the same written scope — the spread will tell you more about what each thinks they are selling than their proposals will.
No. We are not a migration vendor 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. If you are mid-migration, that is the cheapest moment to get the agent-readiness layer right, because your catalog structure and templates are already open. The migration itself should go to a partner who does that work.
The data move is rarely the long pole. Extension replacement, promotion logic and the URL map are what stretch timelines, so a catalog of a few thousand SKUs with two integrations is a very different project from the same catalog with fifteen. Insist the quote separates data migration from storefront rebuild — if a vendor gives one blended number, they have not scoped the second half.
Some volatility is normal while search engines re-crawl and re-evaluate the new URLs. How much, and for how long, is mostly decided by the quality of the redirect map and whether the new templates preserve the content and markup the old pages ranked on. The failure mode is not a bad 301 — it is an indexed URL nobody mapped because it had low session counts and was therefore invisible in the analytics export used to build the map.