Migrating to Shopify is rarely a clean technical operation. It is a redistribution of risk across systems that previously worked together by accident. This checklist walks through the decisions that compound, from URL strategy and tracking foundations to attribution, email migration, and the post-launch audit that most teams declare too early.
Migrating an established store to Shopify is rarely a clean technical operation. It is a redistribution of risk across systems that previously worked together by accident. The CMS knew the URL structure, the ad platform knew the product IDs, the analytics tool knew the funnel, and the email automation knew the customer lifecycle. None of those agreements survive a platform change without deliberate effort, and most migration failures happen because teams treat Shopify as a destination rather than a different operating model.
This checklist walks through the decisions that compound. Get the URL strategy wrong and your organic traffic suffers for six months. Skip the tracking foundation and your paid campaigns optimize against ghosts. Forget the customer data migration sequence and your email flows trigger on the wrong cohort. The goal here is not to list every Shopify feature, but to surface the considerations that are easy to underestimate until they cost real revenue.
1. Audit Your Current Stack Before You Touch Anything
The most expensive migrations are the ones that begin with theme selection. Before any visual or structural decision, build a complete inventory of what currently works. List every URL pattern in production, every active redirect rule, every server-side tag, every custom field used in product or customer records, and every third-party integration with API access to your store. This inventory becomes the contract that the new Shopify environment must honor.
Pay particular attention to dependencies that are invisible until they break. Loyalty programs that read customer tags. Email flows that fire on metafield changes. Subscription apps that store customer payment tokens externally. Recommendation engines trained on six months of behavioral data tied to specific product IDs. These integrations rarely have documented migration paths because each was configured for the previous platform’s data model.
A useful exercise at this stage is to map every customer-facing journey from acquisition to repeat purchase, and annotate which system owns which step. The result is usually surprising. Most stores discover they have three or four shadow systems holding logic that nobody remembers configuring, and these systems will silently fail the moment the underlying data structure shifts. Document them now or rediscover them in production.
The audit should also cover content that lives outside the storefront. Help center articles linked from product pages, PDF guides hosted on subdomains, embedded widgets from comparison engines, and structured data fragments injected by SEO tools. Each of these has its own migration path, and treating them as afterthoughts is how brands lose 20 percent of their long-tail organic traffic in the first quarter post-launch.
A specific category worth flagging is the data your previous platform held that has no obvious owner inside your team. Customer notes added by support staff over the years. Internal tags used to flag VIP customers, high-risk orders, or fraud patterns. Custom fields on products that drive merchandising rules nobody documented. This data often holds significant operational value, and it lives in fields that standard exports do not capture. Before you begin the migration, sit with each functional team and ask what they look at every day that the rest of the company does not see. The answers reveal the migration risks that no technical audit can find on its own.
Performance baselines also belong in the audit. Capture your current Core Web Vitals scores, time to first byte, conversion rate by device, and checkout completion rate by traffic source. These numbers become your validation targets for the new environment. Without them, you cannot tell whether a post-launch dip in conversion rate is a tracking problem, a UX problem, or a normal migration adjustment period. Establishing the baseline is what makes the launch measurable in the first place.
2. URL Strategy and the 301 Redirect Map
Shopify enforces a fixed URL structure for products, collections, and pages. Products live under /products/handle, collections under /collections/handle, and there is no negotiation on this. If your previous platform used a different convention, every existing URL needs a 301 redirect to its Shopify equivalent. This is not a nice-to-have. It is the difference between preserving link equity and starting your domain authority from a partial reset.
The redirect map should be generated programmatically from your old database, not assembled by hand. Export every URL with traffic in the last twelve months from Google Search Console, cross-reference with your analytics platform for any URLs that have inbound links but no organic traffic, and build a spreadsheet that maps each old URL to its Shopify destination. URLs without a clear destination should redirect to the closest semantic match, not to the homepage. Bulk redirects to root are a known signal that Google interprets as a soft 404 pattern.
Pay close attention to faceted navigation URLs. If your previous platform created indexable URLs for every filter combination, you may have thousands of pages ranking for long-tail queries. Shopify handles filters through query parameters by default, which means those URLs will not exist in the new structure. You have two options. Either accept the loss and redirect filter URLs to the parent collection, or invest in a collection page builder that creates indexable filtered collection pages. The second option preserves traffic but adds ongoing maintenance.
Trailing slashes, capitalization, and parameter handling deserve explicit decisions. Shopify’s default behavior may differ from your previous setup in subtle ways that confuse Google for weeks. Use the robots.txt.liquid file and canonical tags consistently, and validate the entire redirect map in a staging environment before launch. The cost of a broken redirect map is measured in months of recovered rankings.
Internationalization adds another layer to URL planning. Stores that previously used subdirectory structures for different languages or regions need to align their hreflang strategy with Shopify’s Markets feature. The implementation differs from most CMS platforms, and getting this wrong creates duplicate content issues that suppress rankings across all language versions. Before launch, generate a full sitemap that includes hreflang annotations and validate it against the international SEO standards documented in the Google Search Central documentation on managing multi-regional and multilingual sites. Validation tools will catch missing reciprocal annotations that humans miss.
The redirect strategy also needs to account for the long tail of obscure URLs. Old campaign landing pages, deprecated category structures, archived blog posts, and resource pages from partnerships that no longer exist. Many of these still receive traffic from external links you do not control, and a thoughtful 404 page with internal search and category recommendations can recover a meaningful percentage of traffic that would otherwise bounce. The 404 page is not just an error handler, it is the last opportunity to keep a visitor engaged when something has gone wrong.
3. Product Catalog Migration and the Variant Problem
Shopify’s product model has hard limits that older platforms often do not. A product can have a maximum of three option types, 100 variants, and a fixed set of standard fields. If your existing catalog uses four-dimensional variant structures, custom attribute systems, or dynamic pricing rules, the migration is not a simple data export and import. It is a model translation.
Before migrating, run an audit on variant count and option dimensions across your full catalog. Products that exceed Shopify’s limits need to be restructured, either by collapsing variants into separate products or by using metafields to preserve attribute data that no longer fits the variant model. Both approaches have downstream consequences. Separate products fragment your reviews and analytics. Metafield-based attributes require theme customization to surface in the storefront and may not be readable by third-party apps that expect standard variant data.
Image migration is its own subproject. Shopify generates derivative images at multiple sizes for performance, and the CDN URL structure is fixed. If your previous platform’s image URLs are referenced anywhere outside the product database, in email templates, in syndicated feeds, in third-party catalogs, those references will break. Plan for a global find-and-replace operation across every system that consumes product imagery, and verify that your new image URLs propagate correctly to Google Merchant Center, Meta Catalog, and any marketplace integrations.
Inventory and SKU integrity is the part most teams underestimate. The SKU is not just an internal identifier, it is the join key between your storefront, your warehouse, your accounting system, and your supplier feeds. If the migration introduces SKU changes, every downstream system needs to be updated in coordination. A single mismatched SKU between Shopify and your fulfillment platform creates inventory drift that takes weeks to reconcile and damages customer trust through cancellations.
4. Customer and Order Data Migration Sequence
Customer records are deceptively complex. Email addresses are easy to migrate. Customer tags, segments, lifetime value calculations, marketing consent status, and historical order data are not. Shopify’s import tools handle a subset of customer fields, but anything custom needs to be mapped to metafields or rebuilt in apps that support customer-level data.
The marketing consent field deserves explicit attention. Customers who previously opted in to marketing communication may have their consent state recorded in formats that do not directly map to Shopify’s accepts marketing flag. Importing without verifying consent state can put you in violation of email marketing regulations the day you launch. Worse, mailbox providers detect sudden volume from a new sending domain and may classify your launch campaign as spam, damaging deliverability for months.
Order history migration is rarely complete in a strict sense. Shopify can import historical orders for reference, but those orders cannot be used for refunds, cannot be modified, and do not link cleanly to the original payment processor. For most stores, the right approach is to migrate the last twelve months of orders for customer service continuity and archive older data in a read-only format outside Shopify. Trying to migrate everything creates more problems than it solves.
Customer passwords cannot be migrated. Shopify hashes passwords with a different algorithm than most platforms, so customers will be required to reset their passwords on first login. This is a critical communication moment. Send a clear, branded email explaining the migration and including the password reset link, and set up a customer service playbook for the inevitable confusion. Stores that skip this communication see a measurable drop in repeat purchase rate in the first month.
5. Tracking Foundation: GA4, Meta Pixel, and Server-Side
Tracking on Shopify is a different problem than tracking on most other platforms because Shopify enforces a specific architecture for customer events. The Customer Events API is the official integration point, and it runs in a sandboxed environment that limits what client-side code can do. Cookie banner integrations, custom event listeners, and direct DOM manipulation that worked on your previous platform may not function inside this sandbox.
The default Meta Pixel installation through Shopify’s Facebook and Instagram channel is consent-gated. This is the correct privacy posture, but it has a consequence that catches teams off guard. Customers who do not actively grant consent through the cookie banner will not generate browser pixel events, which means a significant percentage of real conversions become invisible to Meta’s optimization algorithm. The solution is a hybrid model. Keep the consent-gated browser pixel for users who opt in, and run a server-side Conversions API stream that operates independently of the browser consent layer. This is fully supported by Meta and aligns with privacy regulations because server-side data is processed under a separate legal basis with appropriate user data hashing.
For implementation, the cleanest path is a server-side Google Tag Manager container hosted on a subdomain of your store. Managed server-side GTM hosting providers offer prebuilt connectors for Shopify, Meta, and Google Ads, which dramatically reduces setup complexity. The server container receives events from the web container, enriches them with first-party data, and forwards them to ad platforms with proper deduplication keys. Browser events and server events share an event ID, and the ad platform deduplicates them automatically. The result is significantly higher event match quality and conversion coverage without violating consent.
GA4 setup follows a similar pattern. The standard GA4 installation through Shopify’s Google channel works for basic measurement, but enhanced ecommerce events benefit from custom GTM configuration that aligns with your specific product taxonomy. Pay particular attention to the items array structure, because Google Ads basket data and Merchant Center matching depend on item IDs being formatted to match your product feed. A mismatch here breaks dynamic remarketing and shopping campaign optimization, and the failure mode is silent.
A subtle consideration that catches even experienced teams is how Shopify’s checkout extensibility constrains tracking. The post-purchase page where the order confirmation event traditionally fires runs in a different context than the rest of the storefront, and not all client-side tracking code is permitted there. The official path is to use Customer Events for thank-you page tracking, and to verify that your purchase event is actually firing in production by completing test orders and inspecting the events as they arrive at the destination platforms. The number of stores running with broken purchase tracking they did not realize was broken is significant, and the optimization damage compounds daily.
Consent management deserves explicit architectural thought rather than an off-the-shelf decision. The cookie banner, the consent state propagation to ad platforms, and the server-side processing layer all need to agree about what each user has authorized. A user who declines cookies should not have their browser pixel events fire, but server-side events can still flow under a different legal basis with proper data minimization.
Document this architecture in your privacy policy, because the legal foundation for hybrid tracking depends on transparent disclosure to users about what data flows where. The technical implementation and the legal disclosure must align. Meta’s official guidance on this hybrid approach is documented in the Conversions API best practices, which is worth reviewing before finalizing your tracking architecture.
6. Attribution, Reporting, and the Multi-Source Truth Problem
Once tracking is in place, the next consideration is how you reconcile data across sources. Shopify Analytics, GA4, Meta Ads Manager, and Google Ads will report different numbers for the same time period, and none of them are wrong. They are measuring different things with different attribution windows and different definitions of conversion.
Shopify Analytics reports orders as they happen, attributed to the last click that brought the customer to the site. Meta Ads Manager reports conversions attributed to any ad click within a configurable window, which is typically seven days. Google Ads reports conversions on a similar window with its own attribution model. The same purchase can appear in all four reports with different revenue figures, and the gaps widen as your campaigns become more sophisticated.
The right framing for stakeholders is that Shopify holds the truth about what happened, while ad platforms hold the truth about what they contributed. Reconciling these views requires understanding each system’s attribution logic rather than treating one as authoritative. For most stores, the practical approach is to use Shopify revenue as the financial ground truth, GA4 channel grouping for marketing mix analysis, and platform-native reporting for campaign optimization within each ad system.
A specific failure mode to watch for is the None or Direct traffic source in Shopify Analytics. When this category exceeds 30 percent of revenue, the cause is usually a combination of missing UTM parameters on paid traffic and iOS Safari users who do not send referrer headers. The fix is twofold. Audit every paid traffic source and ensure UTM parameters are appended consistently, and accept that a residual portion of None traffic will persist due to browser-level privacy controls that no platform-side fix can address. GA4 handles this category better than Shopify because it can identify Google and Meta clicks through gclid and fbclid parameters even when UTMs are missing.
Attribution windows are a recurring source of stakeholder confusion that deserves a clear internal narrative. A seven-day click attribution window means that a user who clicked a Meta ad on Monday and purchased on Sunday is credited to that ad campaign, even if they returned to the site through direct traffic on Sunday. Shopify sees only Sunday’s direct visit and credits direct. Both reports are correct within their own logic. The mistake is treating one as the truth and the other as wrong. The right framing is that ad platforms measure their own influence on outcomes that may have multiple touchpoints, while Shopify measures the immediate session that contained the purchase. Combining the views requires marketing mix modeling or media mix analysis tools, which become valuable once monthly ad spend justifies the analytical overhead.
Cross-domain tracking is another hidden complexity. If your store accepts traffic from external landing pages, partner sites, or paid affiliate networks, the session continuity between those domains and your Shopify checkout depends on proper UTM hand-off and, increasingly, on click ID propagation. Without this, a user who clicks a paid ad on a partner site, lands on the partner page, then clicks through to your store appears as a referral from the partner rather than as paid traffic. Auditing the click ID and UTM flow across every domain in your funnel is unglamorous work that compounds in attribution accuracy.
7. Email, Automation, and Lifecycle Migration
Email is where migration projects most often miss their deadlines. Every email flow tied to your previous platform was triggered by events specific to that system, and those events do not exist in Shopify. Welcome series, abandoned cart, post-purchase, win-back, and replenishment flows all need to be rebuilt against Shopify’s event model, even if you are using the same email service provider.
The migration sequence matters. Pause all active flows in your ESP before customer data migrates, because importing thousands of customer records can trigger inappropriate flow entries. A welcome series should not fire for customers who have been buying from you for three years, but a naive import will look like new customer creation to most automation platforms. After import, re-enable flows in a controlled sequence and verify that segmentation logic is still valid against the new data structure.
Abandoned cart specifically deserves careful handling. Shopify’s checkout structure differs from most platforms, and the cart abandonment events fire at different stages of the funnel. If your existing flow was tuned to fire 30 minutes after a specific abandonment event, that timing logic may not translate cleanly. Run the new flow in test mode for at least a week before sending to your full list, because a misconfigured abandoned cart sequence can hammer customers with repeated emails and damage brand trust quickly.
Deliverability deserves a section of its own. Sending domain reputation is built over months of consistent volume from a stable IP. A platform migration often coincides with a sender domain change or a new ESP, both of which reset reputation. Plan for a domain warming period, segment your initial sends to your most engaged subscribers, and monitor inbox placement actively for the first 30 days. Stores that ignore this typically see open rates drop 30 percent in the first two weeks, and recovering from that drop is harder than preventing it.
8. Payment, Shipping, and Tax Configuration
Shopify Payments is the default payment processor and integrates deeply with Shopify’s order management. Switching to Shopify Payments at the time of migration is operationally simpler, but it requires a fresh approval process, new payout schedules, and reconciliation of any in-flight transactions from the previous processor. If your previous payment flow involved subscription billing, store credit, or gift card balances, those data structures need explicit migration paths that are rarely supported by default exports.
Shipping configuration in Shopify uses a zone-based model that is more rigid than some custom platforms. Carrier-calculated rates require Shopify Plus or specific apps, and complex shipping rules involving product weight bands, dimensional weight, or destination-specific surcharges may need third-party apps to replicate. Build the shipping configuration in a sandbox first and run a full set of test orders covering edge cases. Shipping mistakes are visible immediately at checkout and erode customer trust faster than almost any other migration error.
Tax setup has changed substantially in the last few years. Shopify Tax provides automated tax calculation in many jurisdictions, but the configuration depends on accurate product categorization and nexus settings. If your previous platform used a third-party tax service, you may have product-level tax codes that need to be mapped to Shopify’s product tax categories. Errors in this mapping typically surface as customer complaints about incorrect tax charges, which trigger refunds and accounting reconciliation work for months after launch.
A consideration that often gets missed is the post-purchase upsell and order edit flow. Apps that offered one-click upsells, post-purchase modifications, or order editing functionality on your previous platform may not have direct Shopify equivalents. The Shop Pay one-page checkout has specific extensibility constraints, and apps that worked on a multi-page checkout may need to be rebuilt or replaced entirely. Inventory the apps that interact with the checkout flow and validate each one against Shopify’s checkout extensibility model.
9. App Stack Selection and Subscription Migration
The Shopify app ecosystem is one of its strongest assets and one of its biggest risks. There is an app for nearly every problem, but app quality varies enormously, and the cost of a poorly chosen app compounds through performance issues, data lock-in, and integration failures. Resist the temptation to install apps as a first response to missing functionality. Many features that seem to require an app can be built into the theme or handled through metafields with less ongoing complexity.
For each app you are considering, evaluate four dimensions. First, what data does it own and can you export it cleanly. Second, how does it interact with your theme, because some apps inject scripts that degrade page performance measurably. Third, does it have a public API or webhook system that lets you integrate with your other systems, or is it a black box. Fourth, what happens to your store if the app provider goes out of business or changes their pricing model. The fewer apps you depend on for core functionality, the more resilient your store is to ecosystem changes.
Subscription migration is a particularly challenging category. Subscription apps store customer payment tokens, billing schedules, and subscription state in formats that are platform-specific. Migrating an active subscription customer base from one app to another requires explicit cooperation between both vendors and a customer communication plan. Some customers will need to re-enter payment information, which always causes a percentage of churn. Plan for this churn, communicate transparently with subscribers, and time the migration to minimize disruption to billing cycles.
The relationship between apps and theme code is an underappreciated source of fragility. Many apps modify theme files during installation, and uninstalling them does not always remove the modifications cleanly. Over time, an actively maintained store accumulates theme code that no longer maps to any installed app, and this orphaned code can cause unpredictable behavior. Schedule a theme audit at least annually, and consider migrating to a clean theme installation when the cost of code drift exceeds the cost of rebuilding customizations.
Theme architecture itself deserves a strategic decision rather than a default choice. Online Store 2.0 themes use a section-based architecture that allows merchandisers to build pages without developer involvement, which is a significant operational advantage for stores that update layouts frequently. Older themes built before this architecture was introduced can technically be migrated, but the rebuild cost is often justified by the long-term maintenance savings. The performance implications also differ. The newer theme architecture loads more efficiently on mobile and produces better Core Web Vitals scores, which matters for both organic ranking and conversion rate. The Shopify performance documentation details specific patterns to follow and antipatterns to avoid, and this document is worth reading before any theme decision is finalized.
App selection benefits from a structured shortlist process rather than ad-hoc evaluation. For each functional area, identify the two or three highest-rated apps in the Shopify App Store, then look beyond ratings to changelog activity, support response time on review responses, and the depth of the developer’s integration ecosystem. Apps that are actively maintained and that interoperate with the rest of your stack are worth more than apps with marginally better feature lists but no clear development trajectory. The hidden cost of an abandoned app is often higher than the visible cost of a more expensive but better-maintained alternative.
10. Launch Sequence and the Post-Migration Audit
A Shopify launch is not an event, it is a sequence. The instinct to flip a single switch on launch day is almost always wrong because too many systems need to update simultaneously, and the window for catching errors before customer impact is too narrow. The right approach is a phased cutover with clear validation gates at each stage.
A useful sequence looks like this. First, point a non-customer-facing test domain at the new Shopify store and run end-to-end purchase flows for every product type, payment method, and shipping zone. Second, migrate customer data into the new store and validate segmentation against the previous platform.
Third, switch DNS for the primary domain during a low-traffic window with all redirects pre-validated and monitoring in place. Fourth, monitor every critical metric, including conversion rate, page load time, error rates, and email deliverability, for the first 72 hours and have a rollback plan documented. Fifth, run a full audit of search console, ad platform diagnostics, and analytics setup at the one week mark to catch issues that only surface under real traffic.
The post-migration audit is where most teams declare victory too early. The first month is when subtle issues emerge. Search rankings may drift as Google reprocesses redirects. Ad platform optimization may degrade as algorithms adjust to new conversion signal patterns. Email engagement may dip as deliverability metrics rebuild. Customer service ticket volume often spikes for the first two weeks before returning to baseline. None of these are migration failures by themselves, but they require attention and patience to navigate.
The metric that deserves particular focus in the post-migration window is conversion rate by traffic source. A drop in overall conversion rate is expected during the first weeks, but a disproportionate drop in a specific source indicates a tracking or attribution problem that needs investigation. Compare your new Shopify checkout completion rate against your previous platform’s rate cohort by cohort, and if there is a significant gap, audit the checkout flow for friction points that may be specific to the new theme or app stack.
Closing Considerations
Migration projects are bounded by what you can rebuild, not by what you can copy. The platforms differ in fundamental ways, and treating Shopify as a feature-equivalent destination guarantees disappointment. The teams that migrate successfully are the ones that approach the project as an opportunity to redesign systems that have accumulated complexity, not as a translation of the old setup into a new container.
The single most consequential decision in a Shopify migration is whether you treat tracking and attribution as a foundational concern or as a post-launch task. Stores that build a server-side tracking architecture before launch typically recover their previous revenue baseline within 60 days. Stores that defer tracking work until after launch often spend six months reconstructing data that was lost during the cutover. The cost difference between the two paths is significant, and the technical work required to do it correctly is well documented and repeatable.
The second most consequential decision is how you communicate the migration to customers. Every system change is invisible to customers until it inconveniences them, and inconvenience without context damages trust. A clear migration narrative, delivered through email and on-site messaging in the days surrounding launch, converts a confusing experience into a sign of operational maturity. This is one of the cheapest interventions in a migration plan and one of the most underutilized.
Treat the migration as a forcing function for the operational hygiene you have been deferring. Document the data model. Reduce the app dependency footprint. Rebuild the email flows with current best practices instead of porting legacy logic. Validate every integration against current API standards. The migration window is the rare moment when all of this work is justified by an external deadline, and the next window may not come for years.
A final consideration that gets too little attention is the human side of the migration. The team responsible for executing the migration is rarely the same team that will operate the store afterward. Customer service representatives need training on the new admin interface. Merchandisers need to learn the new theme editor. Marketing operators need to understand how the new tracking architecture changes the reports they look at every morning. Without this knowledge transfer, the operational quality of the store degrades after launch even when the technical migration was successful. Build training into the project timeline rather than treating it as a post-launch responsibility.
The store you launch on Shopify is not the final state, it is the starting point for a different operating model. Shopify rewards stores that lean into its strengths, which include rapid theme iteration, deep app integration, and a tightly integrated checkout. Stores that try to replicate the exact experience of their previous platform often miss what the new platform makes possible. After the launch dust settles, schedule a quarterly review of how your operations are using the platform, and look for the patterns where Shopify’s native capabilities can replace custom workarounds you carried over from the migration. This is where the long-term value of the migration is realized, and it does not happen automatically.
The stores that come out of a migration stronger than they went in are the ones that treat the project as a deliberate redesign of their commerce stack. The ones that struggle are the ones that approach it as a like-for-like port. The difference is not technical capability or budget, it is the willingness to question which parts of the old setup were actually serving the business and which parts were just inertia. A migration is an expensive event regardless, and the marginal cost of doing it thoughtfully is small compared to the marginal cost of doing it twice.
