Shopify Customer Data Migration: What to Preserve Before You Replatform

Customer data is usually treated like a migration task. Export the file, import the file, check the row count, move on.

That is too shallow for a serious Shopify replatforming project.

A customer record is not only a name and an email address. It can carry account access, order history, consent, addresses, tags, lifecycle status, loyalty logic, wholesale rules, subscription context, support history, and the signals your team uses to decide what should happen next.

If those signals move badly, the new Shopify store may still launch, but the business loses memory. Customers cannot find what they expect. Marketing rebuilds segments from weak data. Support loses context. Reporting treats old and new customers as if they belong to different businesses.

Before you replatform, the useful question is not "Can we migrate customers?" It is "Which customer context has to remain usable after launch?"

Start with the customer decisions after launch

Shopify's migration guide lists customers and historical orders as data you may want to move, and it warns that import order matters: products first, then customers, then historical orders so records can connect properly.

That technical sequence matters, but it is not the full strategy. The migration plan should start with the customer decisions the team needs to make on day one:

• Can a returning customer recognize their account experience?
• Can support see enough history to solve a real issue?
• Can marketing tell the difference between a first-time buyer, repeat buyer, lapsed customer, VIP, retail customer, and wholesale account?
• Can Klaviyo or another lifecycle platform trust the consent and purchase signals it receives?
• Can analytics compare pre-launch and post-launch behavior without pretending the customer base restarted?

Once those questions are clear, the data map becomes sharper. You are no longer moving every field because it exists. You are preserving the fields that support customer experience, operations, marketing, and reporting.

Separate identity, history, and permissions

Customer data gets messy when every field is treated as one object. It helps to separate it into three layers.

Identity is the profile itself: name, email, phone, default address, billing and shipping details, tax settings, B2B company relationship, and the unique identifiers used by the old platform and connected systems.

History is what the customer has done: orders, returns, exchanges, subscriptions, product categories purchased, retail purchases, support issues, loyalty activity, and important lifecycle events.

Permissions are what the business is allowed to do next: email consent, SMS consent, customer account access, wholesale visibility, market access, loyalty eligibility, privacy requests, and support permissions.

Those layers need different validation. A profile can import cleanly while order history is incomplete. Order history can be available internally while the customer account experience does not show it the way the customer expects. A tag can migrate while the consent behind that tag is not safe to use.

Do not confuse imported customers with usable customer accounts

Shopify customer accounts let customers sign in to view and manage orders, edit profile information, and take actions such as returns or reordering. That experience is different from simply having customer rows in the admin.

This is one of the most common migration surprises. The team sees imported customers and assumes the account journey is preserved. But returning customers care about a different set of details:

• Can they use the expected email address?
• Will they understand the sign-in flow?
• Can they see the orders they expect to see?
• Do saved addresses behave correctly?
• Do returns, subscriptions, warranties, or loyalty tools still recognize them?
• Does support know what to say if something changed?

A good migration plan treats account access as a customer journey, not a backend import. Write the expected experience, test it with real migrated profiles, and decide what communication customers need before launch.

Audit consent before lifecycle systems touch the data

Shopify's customer import documentation supports importing customer CSV files, updating existing profiles with matching email or phone records, and adding tags from the import. That is useful, but it does not remove the need to audit what those tags and fields mean.

Consent should be handled conservatively. If the old platform, email platform, POS, or support tool used different labels for subscribed, unsubscribed, transactional, SMS, wholesale, VIP, or do-not-contact, map those meanings before importing them into Shopify or syncing them into Klaviyo.

This is where migration work becomes operational. A sloppy tag import can make segments look correct while the business logic underneath is wrong. A customer who opted out should not re-enter a campaign because an old field name looked like a purchase tag. A wholesale customer should not receive a retail offer because company status was treated like a note.

Before launch, build a consent and segmentation table with four columns: old field, new Shopify field or tag, connected system, and allowed use. If nobody can explain a field, do not use it for automation yet.

Preserve order history for operations, not nostalgia

Historical orders are useful only when they support a real workflow.

Support may need past orders to answer questions. Marketing may need category purchase history for replenishment, cross-sell, or win-back logic. Merchandising may need old product relationships to understand demand. Analytics may need customer type, order source, and cohort context. Finance may need a separate record of what happened before Shopify became the source of truth.

That does not mean every old order detail has to behave like a native new order. It means the team needs to decide what history should be visible in Shopify, what should live in another system, what should sync to marketing, and what should stay in an archive.

The validation should use real scenarios:

• A repeat customer asks support about a pre-migration order.
• A VIP segment depends on total historical spend.
• A replenishment flow depends on the last purchase date.
• A retail customer later buys online.
• A customer returns after launch through a different channel.

If those scenarios fail, the migration is not ready even if the import report says the rows succeeded.

Test with a small set of real customer profiles

A migration test should not only compare record counts. It should follow customers through the journeys that matter.

Choose a small test set before the full import: a new customer, a repeat customer, a VIP, a lapsed customer, a customer with multiple addresses, a customer with returns, a retail customer, a wholesale or B2B account if relevant, and a customer with suppressed marketing consent.

Then check what each profile becomes in Shopify, Klaviyo, analytics, support, loyalty, subscriptions, and any custom reporting. The goal is not perfection in every system. The goal is to catch the places where the new store would make the team or customer behave from bad information.

Keep customer data migration tied to the replatforming plan

Customer data migration should sit beside the catalog, SEO, checkout, analytics, Klaviyo, POS, and fulfillment workstreams. It should not be a late-stage spreadsheet task.

The reason is simple: customer data affects all of them. Checkout changes account expectations. Klaviyo depends on consent and event quality. POS depends on identity and location behavior. Support depends on history. Analytics depends on continuity. AI workflows depend on trusted customer context before they recommend or act.

Lake House Group treats Shopify replatforming as an operating migration, not only a storefront rebuild. If you are moving to Shopify and need customer data, lifecycle systems, catalog structure, and launch validation to work together, talk to Lake House Group about migrating to Shopify.