Moving products and customers is only part of a BigCommerce to Shopify migration. Reviews influence purchase decisions. Loyalty balances represent benefits customers expect to keep. Back-in-stock requests record people waiting for a particular product or variant.
Those records may live in separate apps, each with its own export format and identifiers. Plan their migration alongside the storefront so that a successful product import does not conceal missing customer data or disconnected workflows.
This checklist covers the decisions, mappings, and validation needed before launch. The transfer method depends on your source apps, destination apps, and data. Confirm their current import requirements before choosing a tool or committing to a launch date.
1. Inventory the data and the apps that own it
Create a migration register with one row for each dataset. Record its owner, export method, destination, dependencies, sensitive fields, validation method, and person responsible for approval.
Include:
- Products, variants, SKUs, images, inventory, and product URLs
- Customer profiles, addresses, and marketing preferences
- Historical orders and their customer relationships
- Discounts, gift cards, store credits, and loyalty balances as separate datasets
- Reviews, ratings, review media, and moderation status
- Back-in-stock subscriptions and notification status
- Custom fields used by filters, product finders, search, or product-page content
- Content pages, navigation, and URL redirects
For each app, ask: Can we export the data we need? Can the destination import it? Which fields will be lost, transformed, or held separately? Will an import trigger emails, rewards, or stock alerts?
Shopify’s migration guide describes several transfer approaches, including CSV files, migration apps, and custom API solutions. Choose an approach for each dataset rather than assuming a single import covers the entire store.
2. Build product, variant, and customer mapping tables
Keep a cross-reference between source and destination identifiers. A product title is too easy to change to be your only matching key.
For products and variants, record the BigCommerce IDs, SKU where available, relevant option values, and the corresponding Shopify IDs and handles. Resolve duplicate or missing SKUs before relying on them. A footwear record might need style, color, size, and width to identify the correct variant.
For customers, preserve the source customer ID and its verified destination match. Document how duplicates, changed email addresses, and missing contact details will be handled. Keep the cross-reference access-controlled and limit it to the fields needed for the migration.
Hypothetical example: A stock-alert request belongs to a black shoe in size 8, wide fit. Mapping it only to the parent shoe could notify the customer when an unrelated size returns. The variant relationship is part of the record’s meaning.
Retain an exception queue for records that cannot be matched confidently. Give each exception an owner and resolution before launch.
3. Migrate reviews with their product relationships intact
Export reviews from the system that actually stores them, which may be a separate review application. Obtain the destination app’s current import template and confirm its supported fields.
Your review checklist should cover:
- Source review ID and destination product mapping
- Rating, review text, date, and supported display-name fields
- Published, hidden, or pending status
- Merchant replies and review media, where supported
- Verified-purchase status only when supported by the source evidence and destination import
- Duplicate detection and records that cannot be imported
Import a small, representative sample first. Check a product with several reviews, a product with none, a review with media, and a record containing special characters. Compare source and destination counts and inspect the actual storefront.
Preserve what the reviewer wrote. Do not upgrade verification status or change dates to make imported reviews appear newer. If a field cannot be represented, document the limitation and agree on its treatment rather than silently discarding it.
4. Reconcile loyalty points before enabling earning and redemption
Treat loyalty migration as both a balance-transfer exercise and a rules review. A balance can be numerically correct while the new redemption rules give it a different value.
Confirm the source and destination handling of:
- Customer identity and current points balance
- Pending points, expiration dates, and tier status
- Previously issued rewards or discount codes
- Earn and redeem rules, including rounding
- Adjustments for returns or canceled orders
- Transaction history, if it is required and supported
Agree on a cutover point. Record the final source balances and account for any earning, redemption, or refunds that occur after the initial export. Test the import without allowing historical activity to award points a second time.
Validate both the total balance and individual accounts. Include zero-balance customers, high balances, recently redeemed rewards, and any supported negative or expired balances. Test a controlled earning-and-redemption journey before enabling the program for customers.
Keep store credit, gift cards, and loyalty points distinct. They can represent different customer entitlements and may need different migration methods.
5. Move back-in-stock requests without sending unintended alerts
A waiting list needs a relationship between the customer, the exact product or variant, and the notification workflow.
Confirm which fields the source provides and the destination accepts:
- Customer contact detail and the requested notification channel
- Source product and variant identifiers
- Request date and supported preference or consent records
- Pending, notified, canceled, or unsubscribed status
- Destination product and variant mapping
A request for a stock notification does not automatically establish permission for unrelated marketing. Preserve the available preference records and have the appropriate owner review how the destination workflow will use them.
Ask the app provider how imports interact with current stock levels. Keep live notifications paused during testing where the tools support it, and use controlled test contacts. Reconcile pending-request counts and investigate duplicates before enabling alerts.
Then test an out-of-stock variant becoming available. Confirm the correct recipient, variant link, availability state, and notification behavior. Also check the product page: the purchase and notification controls should correspond to the selected variant.
6. Map custom fields to the correct Shopify metafields
Custom fields often power more than visible product descriptions. A filter, finder, or search integration may depend on a specific value and data type.
For every field, document:
- Its purpose and owning system
- Whether it belongs to a product, variant, customer, or another resource
- Destination namespace and key
- Data type, allowed values, and validation rules
- The theme or app that reads it
Shopify metafield definitions specify the resource and permitted type of data. Review the parts of a metafield definition. A list, reference, number, and text value need different handling; renaming a column does not complete the mapping.
Where migrated values are unstructured, Shopify provides a process for adding definitions and checking validity. Avoid changing app-owned fields without confirming the app’s requirements. Shopify’s metafield migration guidance
Validate the storefront behavior that depends on the data. A successfully imported “width” value is incomplete work if the corresponding footwear filter or finder cannot use it.
7. Plan customer access and communications for the chosen account experience
Decide how customers will sign in before drafting migration messages. Shopify’s current customer accounts support passwordless sign-in with an emailed one-time code. Existing customer profiles can use their associated email address to access their accounts. Current customer-account guidance
Shopify’s customer CSV does not migrate passwords from another online store or import order history. Historical orders require a separate, suitable migration method. Customer CSV considerations
If your implementation uses a different supported account experience, verify its current invitation or activation process. Test customer access, order visibility, and loyalty access using representative test accounts. Do not send a password-reset or activation message that does not match the configured sign-in flow.
Prepare customer-facing instructions that explain what changes, how to sign in, where to find rewards, and how to get help. Obtain the appropriate review before sending them.
8. Use a launch checklist with evidence and owners
Before switching the live storefront, confirm:
- Exports are retained securely and the final synchronization plan is agreed
- Record counts reconcile, with every exclusion or mismatch explained
- Products, variants, customers, and dependent app records map correctly
- Review presentation and moderation states are verified
- Loyalty balances and controlled earn/redeem tests are signed off
- Stock alerts target the correct variant and are enabled only when ready
- Metafields work in filters, finders, search, and product content
- Customer sign-in and relevant order history are tested
- Key old URLs reach the correct new pages and broken links are reviewed
- Checkout, payment, shipping, and order-notification test journeys pass
- The team knows who can pause a workflow and what would delay launch
Shopify recommends verifying imported products and placing test orders as part of its migration process. Add app-specific checks to those store-level tests.
After launch, reconcile new orders and customer activity with the agreed cutover record. Watch for failed imports, duplicate rewards, incorrect stock alerts, and account-access issues. Keep source exports and access available for the agreed verification period before retiring old systems.
What the Healthy Feet Store project illustrates
In Bliss Web Solution’s Healthy Feet Store migration, the documented work included a move from BigCommerce to Shopify Plus and the transfer of products, customers, orders, and coupon codes.
The project also addressed three separate app datasets: product reviews were prepared and mapped for Judge.me, customer reward points were imported into Smile.io, and back-in-stock requests were mapped to products and variants for a Shopify app. Custom-field data required transformation for Shopify metafields used in filtering, a Shoe Finder, and search-related functionality.
The case study also describes customer activation work for that implementation. Its account workflow and app choices are project-specific; your migration should use the capabilities and requirements of the systems selected today.
The practical lesson is to include customer-facing app data and the features that depend on it in the original migration scope. Product and customer counts alone cannot verify the whole shopping experience.
Discuss your BigCommerce to Shopify migration
Before choosing a migration tool, assemble your app inventory, a representative data sample, and a list of the workflows customers rely on. Those inputs make it easier to identify dependencies and agree on acceptance checks.
Explore Bliss Web Solution’s Shopify development services to discuss your migration scope, app integrations, and storefront requirements.