Shopify Pre-Migration Preparation Checklist

Use this Shopify migration checklist to prepare data and destination decisions.

For each important data area, agree the destination, name an owner and attach evidence that another reviewer can use. Resolve required gaps before testing; counts, column labels and a working connection do not establish readiness.

Define the Source Scope and Shopify Destination

Record the actual Source and intended Shopify destination:

• Store setup: Shopify plan, account model, Markets, languages and locations.
• Implementation context: enabled features, compatible apps, permissions and implementation owners.

Agree migrated records, separate implementation and exclusions. Native capability alone does not establish migration coverage.

Shopify destination structures and decision owners

Preparation area	Decision to record	Owner	Ready evidence
Product structure	Which source records become Products, variants, metafields, metaobjects, tags, or app-owned records	Catalog owner	Approved mapping examples for each major Product family
Catalog organization	Which source Categories become manual or automated collections, navigation links, filters, landing pages, or redirects	Merchandising and content owners	Collection and navigation outline with representative source paths
Customer continuity	Which account, tag, tax, wholesale, loyalty, subscription, or external CRM relationships must remain usable	Customer operations	Customer relationship inventory and account-access communication plan
Order history	Which Order statuses, line details, refunds, notes, and external references staff must retain	Operations and support	Historical Order sample list and field-meaning notes
International structure	Which countries, languages, currencies, domains, subfolders, localized content, and market-specific records matter	International owner	Market and domain matrix
Custom data	Which source custom fields become Shopify metafields, metaobjects, app records, content, or exclusions	Catalog and technical owners	Field inventory with destination owner and continuing consumer

The map defines where each relationship belongs and who will use it; preparation does not require the whole storefront redesign to be finished.

A regional catalog may need separate Market and content decisions. For background, see the Shopify platform overview.

Prepare Access, Source Evidence, and Recovery

Keep dated original exports and media protected. Record coverage, original IDs, changes after capture, recovery location and owner. Collect:

• Records and media: recent reports or exports for Products, Customers, Orders, Categories, content, reviews, discounts and other scoped records; media files when URLs are temporary, protected or unreliable.
• Routes: domains, subdomains, language folders and regional routes.
• Owners: business and system owners for apps/integrations.
• Definitions: custom attributes, option sets, group rules and external IDs.
• Examples: commercially critical or complex examples.

Source access and recoverable evidence

Evidence item	Why it is needed	Ready condition
Source access	Allows the source meaning to be checked against the live administration context	Access works and the required data areas are visible
Shopify access	Allows destination settings and record ownership to be confirmed	Required permissions are available without sharing personal credentials informally
Export archive	Preserves a reference copy of the source state	Files open correctly, include expected records, and carry an export date
Custom-field dictionary	Explains labels that are otherwise ambiguous	Every important field has a purpose, owner, and sample value
External-ID list	Protects ERP, PIM, CRM, WMS, marketplace, or accounting continuity	Each identifier is linked to the correct Product, variant, Customer, or Order level

• Record omitted app records, protected media and undocumented-table gaps. A missing app export does not prove its records are absent.
• Set the snapshot date, permitted changes, their owner and how the migration window will be reconciled.
• Specify what exports, media and backups can recover; hosted exports may not restore the whole store.
• Choose project-specific cutover restrictions and make the package understandable without undocumented staff knowledge.

For setup, see prepare Source and Target access and the Shopify connection requirements. Keep source interpretation and connection access requirements distinct.

Prepare Products, Variants, and Inventory

Classify sellable combinations, descriptive data, buyer inputs, merchandising relationships and external-system values before mapping them.

Illustrative example: engraving text is a purchase input; preserve its storefront and historical Order-line meaning instead of assuming it creates a stock-bearing variant.

Product, variant, and custom-data ownership

Source behavior	Shopify preparation decision	Evidence to attach
Choice creates a distinct SKU or stock unit	Define the intended Product and variant relationship	Source parent/child IDs, option values, SKU, inventory, price, and image examples
Value describes the Product	Define a metafield, metaobject, Product content, or other structured destination	Field purpose, data type, allowed values, and display owner
Customer enters a one-time value	Identify the Product input, app, or line-item relationship that will own it	Storefront example and historical Order-line example
Product is a bundle, subscription, or configurable set	Identify the application or target structure that owns the behavior	Component list, price logic, inventory owner, and sample Orders
Value is used only by an external system	Preserve it at the correct Product or variant level	External-system name, uniqueness rule, and sample lookup

• Keep original Product/variant IDs, SKUs, handles, option names/values, field definitions, referenced entries and external keys before approved normalization.
• Merge “Colour,” “Color” and “Finish” only when meanings match; retain retired-value evidence.
• Native Product CSV option changes can replace variant IDs and break references.

Each major Product family needs an agreed sellable structure and mapping examples. Use Shopify data model differences for unresolved representation decisions.

Record stock by variant and location

Keep a separate stock ledger:

• Identity and timing: variant, location and timestamp.
• Controls and authority: tracking/fulfillment settings and authoritative system.

Distinguish available, committed, unavailable, on-hand and incoming quantities: on-hand combines the first three; incoming is separate.

Separate opening stock from pending obligations and historical Orders to prevent duplicate stock effects.

Native Product CSV quantity is limited to single-location stores; it does not establish multi-location readiness. Each required stock pool needs clear identity, state meaning and continuing authority.

Prepare Collections, Content, and Priority URLs

Use the collection model available in the Store: legacy manual/automated collections or the new Product, variant, app and other-collection sources with inclusion/exclusion logic. Keep membership separate from menu hierarchy.

Illustrative example: a campaign Category may need a landing page or retirement decision rather than a permanent collection.

Collections, discovery, and regional routes

Source structure	Preparation question	Ready evidence
Permanent Category	Should it become a manual collection, automated collection, or another destination?	Collection rule or Product-membership example
Menu-only grouping	Does it belong in navigation rather than Catalog classification?	Intended menu hierarchy and destination links
Campaign or seasonal group	Is it a temporary collection, landing page, promotion, or retired route?	Campaign owner and retained/retired decision
Filter value	Should it use Product category, option values, metafields, or app-managed search data?	Controlled value list and filter owner
Regional route	Which Market, domain, language, currency, and localized content relationship applies?	Market and URL matrix

Create one route inventory for Products, collections, CMS Pages, Blog Posts, policies, guides and active campaigns.

Record source URL, destination, content owner, localization and redirect requirement or intentional retirement.

Prioritize:

• Commercial entry points: high-traffic/revenue Product and Category/brand routes, backlinks and paid-media entry points.
• Content: trust, SEO and support content.
• Regional paths.
• Discontinued Products.
• Embedded references: embedded links and referenced files, documents and images.

Every priority route needs a useful destination or retirement decision.

For multilingual stores, record:

• Identity and ownership: languages, locale owners and base-record links.
• Values and routes: translated values, fallback expectations and localized handles/URLs.
• Consumer: the theme/app/platform consumer.

Include Product, Category/collection, page, post, metadata and market-specific relationships.

Prepare language pairs for later testing; stored text does not establish an active locale experience.

Prepare Customers, Accounts, and Historical Orders

Separate Customer identity from account access and connected business rules.

Illustrative example: a wholesale group may remain owned by an external system; copying its label does not recreate that rule.

Record the actual Source-to-Target account decision: verification continuity, SSO or reset/activation/first-login handling, with identity and communication owners.

Native Customer CSV does not migrate passwords; this does not decide every other path.

Customer identity and historical Order evidence

Preparation item	Owner	Required evidence	Ready condition
Customer identity rules	Customer operations	Duplicate-account examples and external IDs	Merge, retain-separate, and guest-handling rules are documented
Account access	Customer experience	Account-model and chosen-path decision, communication draft, and responsible identity team	The intended verification or first-login handling and communication ownership are documented
Customer classifications	B2B, tax, loyalty, or CRM owner	Group/tag examples and related business rule	The destination owner of each classification is defined
Historical Order meaning	Support and finance	Representative Order packet	Lines, adjustments, statuses, refunds, and references are explained
Sensitive data scope	Legal or data owner	Approved field list	Unnecessary or unsupported personal data is excluded

Contain historical-import effects.

• Identify reacting customer/staff notifications, shipping/email apps and automations.
• Record suppression/isolation, import expectations, responsible owners and expected live-flow restoration.
• Include payment, stock, subscription, fulfillment and app effects.

An archived Order must not become a second live transaction; prepare later live-flow checks before launch.

Prepare Custom Data, Apps, and Integrations

For each custom field, record:

• Field identity: entity scope, namespace/key and definition.
• Value rules: type, validation and values.
• References: reference targets and metaobject entry IDs.
• Continuing consumer: theme/app/API consumer.

Definitions and entries are distinct; linked variant options also need their supported definition/reference relationship.

Confirm chosen-path coverage: native Product CSV supports Product metafields, not variant metafields.

Keep one register for apps, source extensions, scripts, custom-field groups, automations, webhooks and external systems affecting Product, Customer, Order, pricing, content or fulfillment behavior:

• Purpose and records: business use, created/modified data types and parent records.
• Access and relationships: export/API availability, external IDs and prerequisite data.
• Continuity: data/technical owners, continue/replace/retire treatment, compatible enabled consumers and synchronization responsibility.

Cover the following where used:

• Catalog and storefront: reviews, search/filtering, bundles and customization.
• Customer relationships: subscriptions, loyalty, B2B and consent.
• Transactions and channels: tax, shipping, payments and marketplace listings.
• Connected systems and reporting: ERP, PIM, WMS, CRM, accounting and analytics.

The register is ready when each critical dependency has an accepted treatment and continuing owner; use the import-effects plan for reacting workflows.

Confirm the Environment and Select Test Samples

• Record trial/development restrictions on permissions, plan, API, features and operation, their scope effects and final-environment retest owner.
• Client transfer stores under Partner ownership prohibit real transactions; record permitted apps, custom-app constraints, storage and access conditions.
• App/theme dev stores cannot be transferred to a client.
• Name the intended production Store and transition owner.

Select ordinary and exceptional samples for mapping and environment-dependent feature expectations. This prepares later verification; it does not prove full-volume or production acceptance.

Representative Shopify preparation samples

Sample	Preparation purpose
Simple Product	Establish the ordinary Product, collection, image, and inventory pattern
High-variant Product	Expose option naming, variant identity, images, stock, and external IDs
Structured-content Product	Expose metafield or metaobject requirements
Personalized or app-dependent Product	Expose Customer input or application ownership
Priority collection and URL	Expose grouping, navigation, content, and redirect decisions
Complex Customer	Expose addresses, classifications, external IDs, and account-access planning
Complex historical Order	Expose line details, discounts, fulfillment, refunds, and external references
Localized or market-specific record	Expose language, domain, currency, and regional content scope

Attach one record per sample:

• Source evidence: Source ID, original values, URL where relevant and external IDs.
• Destination decision: business reason, intended Shopify representation/owner and agreed exclusions.
• Review: reviewer and expected result.

Use the coverage below only where it applies.

Reference: ordinary and exceptional records to sample

• Product families: simple and multi-option Products; variant SKU, barcode, price, inventory, weight, image, tax and fulfillment differences; combinations to consolidate, split or retire.
• Purchase behavior: bundles, kits, subscriptions, preorders, warranties; personalization using text, files, dates, measurements or conditional choices.
• Content and consumers:
  • specifications, compatibility tables, size guides, documents and structured references;
  • regional/channel/Customer-specific content or availability;
  • ERP, PIM, warehouse, marketplace and supplier synchronization.
• Customers: registered and guest buyers, multiple addresses, tax treatment, tags/groups, B2B, loyalty, subscriptions, memberships and CRM references.
• Orders: paid, pending, canceled, refunded/partially refunded, partially fulfilled and multi-shipment; discounts, gift cards, store credit, taxes, duties, shipping adjustments and manual changes.
• Order relationships:
  • custom inputs, bundles, subscriptions and app-owned line data;
  • marketplace, ERP, accounting, fulfillment, support and CRM links;
  • priority markets, currencies and storefronts.

Complete the Shopify Migration Checklist

Use the prepared artifacts to decide readiness before scheduling the run.

Shopify preparation readiness

Readiness question	Required evidence	Ready condition
Is required access available?	Access log and responsible contacts	Required source and Shopify areas are accessible; trial/development restrictions and the intended production transition owner are recorded where applicable
Are Product families classified?	Product-family matrix	Each important Product pattern has a destination owner
Are collection and URL decisions complete?	Route inventory and collection outline	Priority routes have destinations or retirement decisions; required language/base-record links, locale consumers, and localized route expectations are recorded
Are Customer and Order samples explained?	Customer and Order evidence packet	Historical and account relationships are documented; historical-import suppression or isolation, expected behavior, and live-flow restoration owners are recorded
Are apps and external systems inventoried?	Dependency register	Every important dependency has a continuing owner
Are source backups and exports current?	Dated archive and checksum or file list	Source evidence can be recovered independently of the live Store
Are representative migration samples selected?	Sample ledger	The set covers ordinary and exceptional records
Are unresolved items owned?	Decision log	Required gaps are resolved, excluded by agreement, or held; accepted noncritical exceptions have owners and recorded scope effects

Resolve required gaps, exclude them by agreement or hold the affected scope. An owner and future deadline alone cannot make a critical gap ready.

No essential Product, Customer, Order, URL or integration decision should depend on undocumented assumptions.

Conclusion

A practical Shopify data migration starts with recoverable Source evidence, accepted destination decisions and testable sample expectations. Once preparation is ready, use Shopify migration validation to prove delivery and live readiness.

Common Questions

Which Shopify preparation document should be created first?

Start with the destination decision map for Products, collections, Customers, Orders, content, Markets, apps and external systems. It identifies the exports, samples and owners the preparation package needs.

How many Products should be selected for representative migration test preparation?

Use the smallest set covering ordinary and exceptional behavior: simple, variant-heavy, structured, personalized, bundled/subscription, localized and externally synchronized Products. Coverage matters more than a fixed number.

Should all source custom fields become Shopify metafields?

No. Classify purpose and continuing consumer first. Values may belong in metafields, metaobjects, Product content, variants, apps, external systems or an agreed exclusion.

What Customer account information needs special preparation?

Prepare identity and duplicate-account rules, address examples, classifications, external IDs and returning-Customer communications. Source login credentials must not be assumed reusable.

What should be included in the Shopify URL inventory?

Include priority Product, collection-equivalent, CMS Page, Blog Post, policy, campaign, localized and externally linked routes. Each needs a destination or explicit retirement decision.

When is the Shopify preparation gate complete?

When access/evidence are recoverable, relationships have accepted owners and enabled prerequisites, and samples carry Source expectations.

Required gaps must be resolved, excluded by agreement or held; ownership alone cannot replace missing critical evidence.

Can a Shopify trial or development store be treated as the final migration target?

Only when the environment supplies the access and capabilities the migration path needs. It is not automatically production-equivalent.

Record whether it can become the production Store or a separate Store is needed; app/theme dev stores cannot be transferred to a client.

Verify domains, apps, permissions, notifications and identity-dependent configuration in the final environment before launch.

How should notifications be handled when importing historical Customers and Orders into Shopify?

Prevent historical imports from appearing as new live commerce.

Identify reacting notifications, apps and automations; record suppression/isolation, owners and expected restoration. Include payment, stock, subscription and fulfillment effects, then validate the intended live flows before launch.

What multilingual evidence should be prepared before migrating to Shopify?

Record language-specific Product, content, attribute, URL and navigation values, their storage, base-record links, fallbacks and localization consumer. Prepare language pairs and expected relationships; duplicate text alone does not establish a usable locale experience.

Which inventory evidence is needed beyond the Product catalog?

Record variant/location IDs, timestamp, tracking/fulfillment settings, authority and quantity-state meanings.

Available, committed, unavailable, on-hand and incoming are distinct.

Separate opening stock from pending obligations and history; native Product CSV single-location quantity does not prove multi-location readiness.

What makes metafields and metaobjects ready for migration?

Document definitions, entity scope, namespace/key, type, validation, values, reference targets, entry IDs and active consumer; confirm chosen-path coverage.

Native Product CSV supports Product metafields, not variant metafields, so it cannot alone prove variant-field or referenced-metaobject readiness.