Est. reading time: 9 minutes
Replatforming gets scoped as a design and development project. The timeline covers theme build, data import, payment setup, and QA, with one line near the bottom about reconnecting tracking and email. The store launches, revenue drops, and the drop gets filed under the migration dip everyone warned about.
Some of that dip is structural. Rankings move when URLs move, and paid campaigns lose signal density when conversion data resets. The recoverable portion is larger than most teams expect, and it traces back to a handful of connections that broke at cutover and stayed broken because no one owned them. Redirects that never fired, flows that stopped triggering, and segments reading from data that never arrived.
This checklist is ordered by what each item costs to fix after launch. The redirect map and the customer data decisions are close to unrecoverable once the old store is gone. Tracking and lifecycle can be rebuilt late, at the price of everything you failed to measure in between.
Build the redirect map before the new store exists
The redirect list is usually treated as launch-week cleanup. By launch week the old site is often already down, which means the source of truth for your URL structure is gone. Crawl the existing store while it is still live, export every indexed URL, and rank them by sessions and assisted revenue. A discontinued product page carrying years of backlinks matters more than a category page nobody enters through.
Shopify’s redirect tool has one constraint worth designing around. You can only redirect from broken URLs, meaning the source has to return a 404 before the redirect will fire. If your migration created a live page at a similar path, the redirect sits in the list doing nothing. Verify that each source URL genuinely 404s on the new store before you assume the map is working.
The paths Shopify will not accept as a redirect source
Several prefixes are reserved and cannot be used as a redirect source, including /cart, /carts, /orders, /apps, /application, /services, and /shop, along with Shopify’s fixed paths /products, /collections, and /collections/all. URLs that use collection tag filtering are treated as valid paths and cannot be redirected either. URLs carrying query strings might not behave as expected, which matters if your old platform used parameters for filtering or pagination. Anything ending in .html cannot be redirected to the same URL without the extension, because Shopify treats those as the same address. These constraints apply to the source side of the redirect, and they bite hardest when the old platform used one of those words in its own URL structure.
Redirects import as a CSV from Content > Menus > View URL Redirects, and a standard store supports up to 100,000 of them (stores on Shopify Plus have a far higher ceiling of 20,000,000). One behavior works in your favor. A single redirect applies across your market subfolders, so a store selling into multiple regions does not need a separate entry per locale unless the destination differs by market.
Rebuild tracking inside Shopify’s pixel sandbox
Tracking setups on other platforms tend to accumulate in the theme. A Google Tag Manager container in the header, hardcoded conversion snippets on the order confirmation page, a heatmap tool, a survey widget reading the DOM for the customer’s email address. That inventory does not port over, and the reason is architectural.
Shopify runs app pixels and custom pixels in a sandboxed environment managed in the Customer events section of the admin. The sandbox cannot automatically detect events, metadata, email addresses, phone numbers, or outbound link clicks from DOM scraping, and it cannot capture page scrolling or the mouse movement that heatmap tools depend on. Google Tag Manager can run as a custom pixel, and everything it loads still executes inside the same sandbox under the same limits. Any tool that worked by reading the page needs a different method or a different vendor.
Work the rebuild in a fixed order. Inventory every tag on the old site and sort it into three buckets (app pixels installed through the vendor’s Shopify app, custom pixels a developer writes against the events API, and tools with no remaining path). Prefer the app pixel wherever the vendor offers one. Then rebuild purchase tracking first and verify it end to end with a real transaction before anything else gets attention, because the purchase event is what every campaign optimizes against.
Consent adds a second layer. In markets configured to require consent, usually the European Economic Area and the United Kingdom, pixels fire only after the visitor grants the permissions the pixel is configured for, and new pixels default to requiring Marketing and Analytics permissions. A misconfigured banner at launch will make tracking look broken for reasons that have nothing to do with the pixel code.
Product IDs get reissued, and the catalog follows
The pixel ID carries over. The product identifiers underneath it get reissued, because Shopify assigns its own product and variant IDs at import. The catalog feed regenerates with new IDs, and every dynamic ad, feed rule, and product set that referenced the old identifiers has to be rechecked. Confirm that the IDs your pixel sends on product and purchase events match the IDs in the feed, then work through the catalog diagnostics in each ad platform before scaling spend back up.
What the customer import quietly leaves behind
The customer CSV moves less than the file implies. Two of its columns, Total Spent and Total Orders, are not imported with customer details, and order information cannot come through a customer CSV at all. Shopify counts what a customer has spent and ordered on your Shopify store, so a ten-year customer arrives with zero orders and zero spend on record.
That one fact breaks more than reporting. VIP tiers, loyalty thresholds, win-back windows, and free shipping rules keyed to lifetime value all read from fields that arrive empty. Order history migration is a separate project from customer import, not a checkbox inside it, and it needs to be scoped and budgeted before the launch date is set.
If you migrate order history through a dedicated tool or the API, those segments rebuild themselves once the data lands. If you decide the cost is not justified, carry the value tiers across as tags. The customer CSV includes a Tags column, so a VIP flag or a repeat-buyer flag can travel with each record and become the basis for a segment on the new store even while the underlying numbers sit at zero.
Three import behaviors cost money when they go unnoticed. Duplicate email addresses and phone numbers are skipped, with only the last profile carrying the duplicate making it through, so deduplicate the file before upload. Files cap at 15 MB, which means a large list splits across several uploads and each one needs checking. And customer passwords cannot be migrated, because they were encrypted outside Shopify. Every returning customer has to be invited to create a new password, which is a send you should write and schedule deliberately, since the alternative is a repeat buyer hitting a login failure at the moment they were ready to purchase.
Lifecycle flows stop sending the day you connect Shopify
Email and SMS is where the loss compounds fastest, because flows keep existing while sending nothing. When you connect Shopify, your ESP starts writing to new metrics, and every flow triggered by the old platform’s metric stops queueing anyone. Klaviyo’s own guidance is direct on this point. A flow trigger cannot be changed after the fact, so each flow has to be cloned and pointed at the new metric. Abandoned cart, post-purchase, and browse abandonment sit in the account looking live while nobody enters them.
Segments fail the same way and the failure is quieter. Any segment with a metric condition (purchased in the last 90 days, spent above a threshold, has not ordered in six months) reads the legacy metric and will never see a new order. Clone every metric-based segment and repoint it before launch, because a win-back campaign built on an empty segment simply does not send.
Sequence matters more here than anywhere else in the migration. Klaviyo recommends fully migrating historical purchase data into the new platform before integrating, so reporting stays in one place and segments never have to reference two sets of metrics. Connect early and you inherit a split history you will be working around for years. Two supporting details are easy to miss. Dynamic template tags differ between platforms, so the product blocks inside abandoned cart and post-purchase emails need rebuilding alongside the trigger, and cloned flows should stay in draft or manual status until cutover finishes so nothing sends mid-migration. Onsite tracking for browse and active-on-site events also has to be enabled again on the new store, and signup forms need repointing to the correct list.
A cutover sequence for a Shopify migration
Order of operations decides how much of the above is preventable. The sequence below assumes the new store is built and the launch date is set.
- Crawl the live old store and export every URL with its traffic and revenue, before anything is taken offline.
- Migrate historical orders into Shopify before connecting your ESP, or decide explicitly against it and plan the tag-based workaround.
- Import customers from a deduplicated file with value tiers carried in the Tags column.
- Load the redirect CSV and confirm each source URL returns a 404 on the new store so the redirects can fire.
- Rebuild pixels in Customer events, starting with purchase, and test each event with a live transaction.
- Clone flows and segments onto the new metrics and hold them in draft until launch.
- Crawl the new store for 404s within the first day of launch, and watch Search Console coverage through the first month.
- Send account activation invites as a planned campaign, with subject line and timing treated as a real send.
Most of the revenue lost to a replatform is lost in the two weeks around cutover, and almost all of it is lost to items nobody was assigned. Give the redirect map, the tracking rebuild, the customer data decision, and the flow migration each an owner and a completion date before the launch date gets locked. If you want a second set of eyes on the marketing side of a migration that is already scheduled, we’re glad to walk the plan with you.
