Replatforming to Shopify is mostly an inventory problem wearing a project plan. The stores that launch cleanly are the ones that knew, before signing anything, how many URLs they had, which ones mattered, which features would not survive a CSV export, and who would own each answer. This preflight is that inventory.

In short

  • 21 checks across four groups: URL inventory, search preservation, commerce features, and cutover.
  • The public source storefront answers about half of them before anyone is given a login.
  • Customer passwords, subscriptions, stored payment methods and loyalty balances never move by export.
  • This is discovery. It is not a quote, a timeline, a catalog count, or a delivery plan.

What this preflight is and is not

Shopify publishes an operational migration checklist that covers store setup, importing data, and configuring payments and shipping. It is good and you should use it. What it assumes is that you already know the shape of what you are moving. This document sits before that one: it is about finding out.

Each check is tagged by the kind of evidence needed to answer it. The public tags matter in a migration context because they can be completed before the merchant hands over any access, which is usually when a scope conversation is most useful.

Public response

Visible in the storefront’s public HTML, headers, robots.txt or sitemap.

Browser needed

Needs a real browser session, device conditions, or field data.

Admin or theme access

Needs Shopify admin, theme code, or a vendor account to confirm.

Know what you have: the URL inventory

  1. Check 1: Confirm the source platform and how customized it is

    Public response

    Platform signatures in the HTML, asset paths, cookies and headers usually identify the source platform with high confidence. What they hint at, and cannot confirm, is customization depth: a stock theme migrates differently from a platform buried under five years of agency work. Record the platform, the confidence, and the evidence, and treat customization as an open question for the admin walkthrough.

  2. Check 2: Count the sitemap by content type

    Public response

    Fetch the sitemap index and each child sitemap, then group URLs by pattern: products, categories, content pages, blog, and everything else. Large sitemaps are often sampled rather than read completely in a first pass, so state the sample size. The point is the order of magnitude and the mix, not a precise catalog count, which only the source admin can give.

  3. Check 3: Map each URL pattern to its Shopify equivalent

    Public response

    Shopify has fixed URL structures: /products/handle, /collections/handle, /pages/handle, /blogs/blog-handle/post-handle. Every source pattern that does not map to one of those becomes a redirect rule, a design decision, or both. Nested categories, dated blog paths and localized slugs are the usual sources of surprise.

  4. Check 4: Identify the pages that earn traffic and links

    Admin or theme access

    Export the last twelve months of landing pages from analytics and Search Console, and the top linked pages from a backlink tool. Any URL on those lists needs a one-to-one redirect and a manual check on launch day. Everything else can be handled by pattern.

  5. Check 5: Find the parameter, facet and pagination URLs

    Public response

    Look at how the source site paginates categories and exposes filters in the URL. If filtered category pages are indexed and ranking today, decide deliberately whether Shopify collections and their filter parameters will reproduce them or whether that traffic is being consciously consolidated.

Migration Check reads the public homepage and a capped sample of the sitemap to report the detected platform, confidence, sitemap surface and locale signals before discovery starts.

Run Migration Check

Preserve what search engines already know

A migration that loses organic traffic almost never does so because Shopify is slower or worse. It does so because URLs changed without a complete redirect map, canonicals pointed somewhere unexpected, or a staging store was indexed. All three are preventable with work that happens before launch.

  1. Check 6: Build the redirect map as a table, one row per old URL

    Admin or theme access

    Old URL, new URL, content type, traffic tier, owner, verified yes or no. Shopify accepts redirect imports as CSV, and its redirects only fire for paths that do not otherwise resolve, which means a redirect to a path that also exists as a page will be silently ignored. Google’s site-move guidance covers the sequencing and is worth reading in full once.

  2. Check 7: Record what the source site currently treats as canonical

    Public response

    Pull the canonical tag from a sample of products, categories and content pages. Sites frequently canonicalize products to a category-nested URL, or paginated pages to page one. The redirect map should send old URLs to the new canonical, not to whichever URL the export happened to contain.

  3. Check 8: Document the locale and hreflang structure

    Public response

    Subdomains, subfolders, separate domains, or a parameter? Which locales carry hreflang and are they reciprocal? Shopify Markets supports subfolders and domains and generates hreflang for configured markets, but the mapping from the source structure to that model is a decision, not a default.

  4. Check 9: Inventory the structured data being emitted today

    Public response

    Product, Offer, Review, BreadcrumbList, Organization. Note which types exist, which produce rich results today, and which come from a plugin the new theme will not have. Shopify themes emit Product data by default; review and breadcrumb data depend on the theme and apps chosen.

  5. Check 10: Plan robots and noindex for staging and launch

    Public response

    The development store should be password protected the entire time and should never be linked from anything public. On launch day someone owns removing the password, confirming the live homepage is not noindex, and checking /robots.txt and /sitemap.xml on the production domain within the first hour.

Commerce features that do not move by CSV

Products, customers and orders export and import. The features around them do not, and each one is a workstream with its own vendor, its own data rules and its own launch-day risk. Public evidence can show that several of them exist; only the admin and the vendors can show how deep they go.

  1. Check 11: Customer accounts and passwords

    Admin or theme access

    Customer records import. Passwords do not; they are hashed on the source platform and cannot be transferred, so every customer will need to activate an account on Shopify. Plan the invitation flow, the email copy and the timing, and decide whether the store will use classic or new customer accounts before the invitations go out.

  2. Check 12: Subscriptions and stored payment methods

    Admin or theme access

    Active subscription contracts need a subscription app on Shopify that supports importing them, and the stored payment methods behind them depend on what the current and future payment processors will transfer between each other. This is the workstream most likely to move a launch date. Start it first, with the vendors in the room.

  3. Check 13: Bookings, appointments and reservations

    Public response

    Calendar widgets, time-slot pickers and booking confirmation pages are visible in the public storefront and signal a feature Shopify does not provide natively. Note the vendor, then confirm in the admin how bookings connect to inventory, staff and payments today.

  4. Check 14: Search, filtering and merchandising rules

    Public response

    Faceted search, synonyms, boosted products and rule-based collections are often years of accumulated merchant knowledge stored in a platform-specific way. The public site shows the facets; the admin shows the rules. Both need to be written down before choosing between Shopify’s Search & Discovery app and a third-party search vendor.

  5. Check 15: Reviews and user-generated content

    Admin or theme access

    Who owns the review data, can it be exported with dates and verified-purchase flags, and will the new reviews vendor import it? Reviews visible in the public storefront tell you a vendor exists; the contract tells you whether the content is portable.

  6. Check 16: Gift cards, store credit and loyalty balances

    Admin or theme access

    Outstanding gift card balances and loyalty points are liabilities with customers attached. Export them with identifiers that will survive the customer import, and decide how balances are honored during any gap between systems.

Tracking, integrations and the go-live week

  1. Check 17: Analytics, pixels and consent

    Admin or theme access

    Inventory every tag on the source site, including what the tag manager loads, and decide for each whether it is re-implemented through Shopify’s customer events, a native integration, or the theme. Confirm the consent tool covers the new set before launch, not after.

  2. Check 18: Email and SMS flows

    Admin or theme access

    Abandoned cart, welcome, post-purchase and win-back flows depend on events the source platform emits. Map each flow to its Shopify trigger and test it with a real order on the development store before the switch.

  3. Check 19: Orders, inventory and fulfillment integrations

    Admin or theme access

    ERP, warehouse, marketplace and accounting connections each have a Shopify equivalent with its own field mapping. The question to settle early is which system is the source of truth for inventory on day one, because two systems claiming that role produces oversells within hours.

  4. Check 20: The cutover sequence, written down and rehearsed

    Admin or theme access

    Domain connection, DNS change, TLS issuance, redirect import, password removal, sitemap submission, and the first manual checks, in order, with a name next to each. Rehearse it on a subdomain if the stakes justify it. The same document is the rollback plan read backwards.

  5. Check 21: A monitoring plan for the first month

    Public response

    After launch, the public storefront is the earliest warning system you have. Check the homepage status, canonical and indexability, the sitemap on the new domain, the top redirects, and the script footprint daily for the first week and weekly after that. The monitoring guide covers what to watch and why uptime alone is not enough.

Scope honesty

Nothing in this preflight produces a price or a date. It produces a list of workstreams, each with an evidence level and an owner. That list is what a fair quote is built on. Anyone quoting a migration without it is quoting the export, not the store.

What Migration Check covers

Migration Check reads the public homepage of a storefront and a capped sample of its sitemap. It reports the detected source platform with a confidence level, the sitemap surface it observed, locale and structured data signals, and public signals for customer accounts, subscriptions, bookings, search and reviews. From those it lists the migration workstreams the evidence suggests and a bounded complexity indicator, with the evidence behind each line.

It does not log in to the source platform, crawl the full catalog, read integrations, or produce a quote, a timeline or a delivery plan. It is explicit about which signals are observed and which are inferred, and it is versioned so results remain comparable over time. Its job is to make the first scoping conversation start from evidence instead of from a form.