Data Migration for Ecommerce: Products, Customers, Orders

Data migration is the most technically demanding phase of any ecommerce replatforming project. It is also the phase most likely to be underestimated. Moving products, customers, and orders between platforms involves more than exporting a CSV and importing it elsewhere. Data structures differ between platforms. Field mappings do not align. Historical records contain inconsistencies that were invisible until you tried to move them.

This guide covers the practical reality of ecommerce data migration — what moves cleanly, what requires transformation, and where the risks lie. We have migrated stores from Magento, WooCommerce, OpenCart, PrestaShop, Visualsoft, BigCommerce, and bespoke platforms to Shopify. The patterns and pitfalls are remarkably consistent regardless of source or destination.

Understanding your data landscape

Before touching any migration tools, you need a complete inventory of your data. This sounds obvious, but most brands significantly underestimate the scope of data they have accumulated. A store that has been running for five years on a self-hosted platform typically has:

• Product data: Products, variants, images, categories, tags, descriptions, SEO metadata, pricing, inventory levels, and custom attributes.
• Customer data: Customer accounts, addresses (billing and shipping), contact preferences, loyalty tiers, and custom fields.
• Order data: Historical orders, line items, payment records, shipping information, refunds, and fulfilment status.
• Content data: CMS pages, blog posts, banners, navigation menus, and static content blocks.
• Configuration data: Tax rules, shipping zones and rates, discount codes, payment gateway settings, and email templates.
• Third-party data: Product reviews, loyalty points, subscription records, gift card balances, and wishlist contents.
• URL structure: Every URL on the current site that needs a redirect on the new platform.

Not all of this data needs to migrate — but all of it needs to be accounted for. The migration plan should explicitly document what is being migrated, what is being recreated from scratch, and what is being intentionally discarded.

Product data migration

Product migration is typically the most complex data type because of the structural differences between platforms. What one platform calls a "category" another calls a "collection." What one stores as product attributes, another handles through variants or metafields.

Core product fields

The basics — title, description, price, SKU, barcode, weight — transfer straightforwardly between platforms. These are universal fields present in every ecommerce system. The transformation required is usually formatting: character encoding, HTML markup differences, and field length limits.

Variants

Variant structures vary significantly between platforms. Shopify allows three variant options (e.g., Size, Colour, Material) with up to 100 variants per product. Platforms like Magento support configurable products with unlimited attributes. If your source platform has products with more than three varying attributes or more than 100 combinations, these need restructuring before import.

Practical example: a furniture store might have a sofa with options for Size (3), Fabric (20), Colour (15), and Leg Style (4). That is 3,600 combinations — far exceeding Shopify's 100-variant limit. The solution is to restructure: make Fabric+Colour a single combined option, or split the product into multiple Shopify products grouped under a collection.

Images

Product images are typically the largest data set by file size and the most time-consuming to migrate. Each image needs to be downloaded from the source platform, verified for quality and resolution, and uploaded to the destination platform. Image URLs change during migration, so any hardcoded image references in descriptions or custom content need updating.

Common issues: broken image links in the source data, inconsistent image dimensions, images stored in formats not optimised for web (BMP, TIFF), and duplicate images across colour variants.

Categories and taxonomy

Source platform categories rarely map one-to-one to destination platform collections. Most migrations require taxonomy restructuring — which is actually an opportunity. Take the time to build a clean, logical collection structure that reflects how customers browse your store, not how your source platform organised products internally.

For detailed guidance on structuring Shopify collections and categories, see our Visualsoft to Shopify migration guide which covers taxonomy mapping in depth.

Custom attributes and metadata

This is where migrations become genuinely complex. Custom product attributes — fabric composition, dimensions, certifications, ingredient lists — are stored differently on every platform. On Shopify, these map to metafields, which need to be defined before data import. Each custom attribute in your source platform needs a corresponding metafield definition in Shopify with the correct type, validation, and namespace.

Customer data migration

Customer data migration is simpler in structure but more sensitive in execution. You are handling personal data subject to GDPR and the UK Data Protection Act, which adds compliance requirements to the technical work.

What transfers

Customer records typically include first name, last name, email address, phone number, default billing address, default shipping address, additional addresses, marketing consent status, account creation date, and custom tags or segments.

What does not transfer

Passwords. This is the most commonly asked question and the answer is always the same: passwords cannot be migrated. Every modern platform stores passwords as one-way cryptographic hashes. These hashes are algorithm-specific and cannot be decrypted or converted between systems. Customers will need to create new passwords on the new platform.

The practical approach is to import customer accounts without passwords, then send a bulk password reset invitation via email. Shopify provides this functionality natively through the customer admin. Timing matters — send the invitation close to launch, not weeks before, or customers will forget by the time the new store goes live.

Marketing consent

Under GDPR, you can only migrate marketing consent if the original consent was given in a way that is compatible with the new platform's processing. In practice, this means: if the customer opted in to email marketing on your current platform, you can mark them as opted in on Shopify. If their consent status is unclear or was obtained through pre-ticked boxes, you should treat them as not consented and seek fresh consent.

Document your consent migration logic and keep records. This is an area where regulators have been active and penalties are significant.

Customer segmentation

Customer tags, segments, and loyalty tiers from your source platform need mapping to Shopify's customer tagging system. Shopify does not have built-in loyalty tiers, so these are typically mapped to customer tags (e.g., "VIP", "Trade", "Wholesale") or managed through a loyalty app. Plan this mapping before import to ensure your email marketing segmentation works from day one on the new platform.

Order history: what to bring and what to leave

Order history migration is the most debated aspect of ecommerce data migration. There are strong opinions on both sides, and the right answer depends on your specific business requirements.

Arguments for migrating order history

• Customer service continuity: When a customer contacts your team about a previous order, your staff can access the record without switching between systems.
• Return and warranty processing: If you need to verify purchase dates or order contents for returns or warranty claims, having the data in one system is operationally simpler.
• Customer lifetime value analysis: Imported orders contribute to customer order count and spend totals, enabling LTV-based segmentation and marketing.

Arguments for leaving order history behind

• Complexity and cost: Order migration is technically complex and time-consuming, particularly for stores with tens or hundreds of thousands of historical orders.
• Limited functionality: Imported orders on Shopify are read-only records. They cannot be fulfilled, refunded, or modified. They are reference data, not operational data.
• Reporting discontinuity: Imported orders can skew Shopify analytics and reports. Most brands maintain access to their legacy platform's reporting for historical data analysis anyway.

Our recommendation

Migrate the last 12-24 months of orders. This covers the active customer service window and warranty period for most products. Maintain read-only access to your legacy platform for older historical data. This balances operational needs against migration complexity and cost.

For a broader view of migration planning, our ecommerce migration checklist covers every phase from planning through post-launch monitoring.

URL redirects and SEO preservation

URL redirect mapping is the single most important task in the entire migration from an SEO perspective. Every URL on your current site that receives traffic, has inbound links, or ranks in search results needs a 301 redirect to the equivalent page on the new platform. Missing redirects mean 404 errors, which mean lost traffic, lost rankings, and lost revenue.

Building the redirect map

Start with your analytics data and Google Search Console. Identify every URL that has received organic traffic or impressions in the last 12 months. Cross-reference with your backlink profile (using Ahrefs, Semrush, or similar) to capture URLs with external links that may not appear in your traffic data.

For each URL, map it to the corresponding URL on the new platform:

# Redirect map example
/category/mens-shoes       → /collections/mens-shoes
/product/leather-boot-123  → /products/leather-boot
/blog/2024/01/winter-sale  → /blogs/news/winter-sale
/about-us                  → /pages/about
/contact-us                → /pages/contact

URL structures differ between platforms. Shopify uses /products/, /collections/, /pages/, and /blogs/ prefixes. Your source platform likely uses different patterns. Every product, collection, page, and blog post needs a redirect entry.

Testing redirects

Test every redirect before go-live. Automated testing tools can crawl your redirect map and verify each one resolves correctly. Pay particular attention to:

• Redirect chains: A redirects to B which redirects to C. These slow down crawling and dilute link equity. Every redirect should go directly to the final destination.
• Case sensitivity: Some platforms generate uppercase URLs that need redirecting to lowercase equivalents.
• Trailing slashes: Ensure consistency — either all URLs have trailing slashes or none do.
• Query parameters: URLs with parameters (?page=2, ?sort=price) may need special handling.

We cover SEO preservation in detail in our OpenCart to Shopify migration guide and our PrestaShop to Shopify migration guide.

Content, blogs, and pages

Content migration is often treated as an afterthought, but it can be substantial. A store with five years of blog content, landing pages, FAQ sections, and policy pages may have hundreds of content items to migrate.

Blog content

Blog posts migrate reasonably cleanly — title, body, author, date, featured image. The main challenges are internal links within blog content (which need updating to new URL structures), embedded images (which need re-hosting), and formatting differences between the source CMS and Shopify's blog editor.

CMS pages

Static pages — About, Contact, FAQ, Shipping, Returns — are typically rebuilt rather than migrated. The content may transfer, but the layouts, templates, and functionality usually need redesigning for the new platform. This is another opportunity for improvement rather than a like-for-like copy.

Navigation menus

Navigation structures need rebuilding on the new platform. Use this as an opportunity to review and simplify your navigation based on current analytics data — which categories get the most clicks, which pages drive the most revenue, and which menu items nobody uses.

Third-party data: reviews, loyalty, and subscriptions

Some of the most valuable data in your ecommerce ecosystem lives in third-party services rather than your platform itself.

Product reviews

Reviews are one of your most valuable data assets. They provide social proof, contain customer-generated keywords that aid SEO, and directly influence purchase decisions. Most review platforms (Judge.me, Yotpo, Stamped, Trustpilot) support data migration between their own systems. If you are switching review platforms as part of the migration, export your reviews in a structured format (CSV with product identifier, rating, title, body, author, date) and import them into the new system.

Loyalty and rewards

Loyalty point balances represent a liability on your balance sheet and a value proposition for your customers. If you are changing loyalty platforms, you need to migrate point balances accurately. Most loyalty apps support CSV import of customer balances. Communicate the migration clearly to customers — nothing damages trust faster than disappearing loyalty points.

Subscriptions

Active subscriptions are the most complex third-party data to migrate because they involve ongoing payment obligations. The subscription platform (Recharge, Bold, Loop) manages the billing relationship. Migrating subscriptions typically involves working directly with the subscription provider to transfer active subscriptions to the new store. This requires coordination and testing to ensure no payments are missed or double-charged.

Gift cards

Outstanding gift card balances are a financial liability. Shopify supports gift card import with original balances, enabling customers to redeem existing gift cards on the new store. Every gift card code and remaining balance must be imported accurately.

Data cleanup: the migration opportunity

Migration is the single best opportunity you will ever have to clean up your product data. You are already touching every record. You already have a team focused on data quality. The incremental cost of cleanup during migration is a fraction of doing it as a standalone project.

What to clean up

• Discontinued products: Remove products you no longer sell. There is no value in migrating dead stock to a new platform. If they have SEO value, set up redirects to relevant alternatives.
• Inconsistent titles: Standardise your naming convention. "Mens Leather Boot - Black" vs "Men's Black Leather Boot" vs "BLACK LEATHER BOOT (MEN)" — pick a format and apply it to everything.
• Poor descriptions: Rewrite product descriptions that are thin, duplicated, or manufacturer-supplied. This improves both conversion and SEO.
• Image quality: Replace low-resolution images, inconsistent backgrounds, and poorly cropped photos. Use the migration as a deadline for a product photography refresh.
• Missing data: Fill in blank fields — weights (essential for shipping calculations), barcodes, SEO titles, and meta descriptions.
• Duplicate records: Identify and merge duplicate customers, products with multiple entries, and variant structures that should be consolidated.

Testing and validation

Never migrate production data without testing. The testing process should follow this sequence:

1. Sample migration

Migrate a small subset of data — 50-100 products, 100 customers, 50 orders — and manually verify every record. Check field mappings, image quality, variant structures, pricing, and metafield values. This identifies systematic issues before they affect your entire database.

2. Full test migration

Run the complete migration against a development or staging store. Verify record counts match expectations. Spot-check random records across all data types. Test edge cases: products with maximum variants, customers with multiple addresses, orders with refunds and partial fulfilments.

3. Automated validation

Build automated checks that verify: product count matches, all images resolve correctly, all redirects work, pricing is correct across all variants, and inventory levels are accurate. These checks should run after every migration attempt, including the final production migration.

4. User acceptance testing

Have your operations team use the staging store for a full day of simulated work: processing orders, answering customer queries, updating products, running reports. They will find issues that automated testing misses — workflow differences, missing data they rely on daily, and features they assumed would work the same way.

Cutover strategy and timing

The cutover is the moment you switch from the old platform to the new one. How you manage this transition determines whether data is lost, duplicated, or out of sync.

Delta migration

Most data can be migrated days or weeks before go-live. The cutover itself only needs to handle the "delta" — new orders, new customers, and inventory changes that occurred between the initial migration and the switch. This minimises downtime and reduces risk.

Timing

Choose your cutover window carefully. Avoid peak trading periods, promotional events, and marketing campaign launches. Early morning on a Tuesday or Wednesday is typical — low traffic, full working day to resolve issues, and time to recover before weekend trading.

Rollback plan

Have a documented rollback procedure in case the migration fails. This means keeping your old platform running (read-only) until the new platform is confirmed stable. Define clear criteria for what constitutes a "failed" migration versus a "migration with issues to resolve." Not every problem justifies a rollback — some can be fixed on the live store.

For realistic timelines on the full migration process, see our guide on how long ecommerce migrations take.

---

Data migration is the technical backbone of any ecommerce replatforming project. It demands meticulous planning, thorough testing, and experienced execution. The brands that get it right launch their new store with clean, accurate, complete data and minimal disruption. The brands that rush it launch with missing products, broken redirects, and angry customers.

If you are planning a migration and want to understand how your specific data requirements translate into a practical migration plan, get in touch. We will assess your data landscape and give you a realistic scope and timeline.