Shopify Loyalty Platform Migration: What Customer Data to Preserve

A Shopify loyalty platform migration looks simple until the first customer asks where their points went.

The app might install cleanly. The widget might match the theme. The points program might look better than the old one. None of that matters if the customer logs in after launch and sees the wrong balance, the wrong tier, a missing reward, or a discount they can no longer redeem.

That is why loyalty migration needs a different plan from a normal app swap. You are not just moving settings. You are moving customer trust.

Shopify's customer CSV import and export can help with profile fields, tags, marketing preferences, and certain supported customer metafields. Shopify also documents loyalty and rewards as common customer-metafield segment use cases. But the loyalty layer usually contains more than a customer record.

Points balances, tier qualification, referral history, earned rewards, expiry rules, VIP perks, POS behavior, lifecycle segments, and support exceptions may live partly in the loyalty app, partly in Shopify, partly in Klaviyo, and partly in support notes.

Before switching loyalty tools, map that value layer in plain language. What has the customer earned? Where is it stored? Which system shows it to them? Which system uses it for marketing, support, or reporting? Which promises must still be true after cutover?

Start with identity, not points

Most loyalty migration problems start with identity.

If the same customer exists under multiple emails, phone numbers, old accounts, POS profiles, or subscription records, the points balance is only the visible problem. The real problem is that the business does not know which record should own the customer's value.

Start by deciding the matching rule. For many Shopify brands, email is the first match key, but it is not enough on its own. Phone, customer ID, customer account state, POS profile behavior, subscription status, and historical app IDs may matter. Shopify warns that customer CSV imports can skip duplicate email addresses or phone numbers, and that overwriting existing customers can replace data. That makes deduplication a launch requirement, not an admin detail.

Build a test file before the full migration. Include clean customers, duplicate customers, POS customers, subscription customers, high-value members, customers with no account, and customers with old rewards. Then check whether each record lands where the team expects.

Separate profile data from loyalty value

Customer profile data and loyalty value are related, but they are not the same thing.

Profile data answers questions like:

• Who is this customer?
• What contact information and marketing preferences do we have?
• Which tags, metafields, or segments describe them?
• What purchase behavior is visible in Shopify?

Loyalty value answers different questions:

• How many points has the customer earned?
• Which rewards are active, used, expired, or owed?
• What tier are they in, and why?
• Which referrals, VIP perks, birthday rewards, or store-credit promises exist?
• What will the customer see when they log in after launch?

Do not collapse those into one spreadsheet and hope the new platform interprets them correctly. Some fields belong in Shopify. Some belong in the loyalty platform. Some belong in Klaviyo or the support tool only as limited context. The migration plan should say which system owns each field after launch.

Decide what must be preserved exactly

Not every historical field deserves to move. Some fields are noise, old test data, or leftover program logic that the brand should retire.

The fields that affect customer trust need a higher standard:

• Current point balance.
• Pending points from recent orders.
• Active rewards and unused codes.
• Tier status and tier qualification history.
• Expiry dates and grace periods.
• Referral credits.
• Birthday or anniversary rewards.
• Store credit or make-good balances.
• VIP exclusions or manual adjustments.
• Loyalty-related customer tags, metafields, or segments used by Shopify, Klaviyo, POS, or support.

If the new platform cannot represent one of those fields cleanly, decide the customer-facing policy before launch. Do not leave support to invent an answer after customers notice.

Freeze earning and redemption before cutover

The riskiest period is not always the import. It is the overlap between the old program and the new one.

If customers can keep earning in the old system while the new platform is being loaded, the migrated balances can go stale before launch. If rewards can still be redeemed during the cutover window, the new system might show value that no longer exists. If Klaviyo or Shopify Flow continues to trigger loyalty messages during the change, customers can receive instructions that no longer match the live experience.

Create a cutover rule:

1. Last moment customers can earn in the old platform.
2. Last moment customers can redeem old rewards.
3. Time the export is pulled.
4. Time the new platform import starts.
5. QA window for balances, tiers, rewards, and customer-facing messaging.
6. Launch moment for the new loyalty experience.
7. Support policy for missing or disputed rewards.

The rule does not need to be complicated. It needs to be clear enough that marketing, ecommerce, support, retail, and operations can follow the same version.

Check Klaviyo, POS, and support before launch

Loyalty data rarely stays inside the loyalty app.

Klaviyo may use loyalty status for segments, winback logic, replenishment timing, VIP treatment, or post-purchase messaging. Shopify POS customer profiles can include purchase history, marketing preferences, and custom metafields such as loyalty status. Support teams may need enough loyalty context to answer reward questions without asking engineering to inspect exports.

Before launch, list every place where loyalty data affects customer experience:

• Account pages and the onsite loyalty interface.
• Checkout, discount, and redemption behavior.
• Klaviyo flows and segments.
• Shopify customer tags, metafields, and customer segments.
• POS customer lookup and retail staff expectations.
• Support macros, helpdesk fields, and escalation rules.
• Reporting dashboards and retention cohorts.

Then decide which integrations must be live on day one and which can wait. A customer must be able to see and use their value. The marketing team can usually wait for non-critical enrichment if that makes launch safer.

QA the migration with real customer cases

A loyalty migration should not pass QA because a sample import succeeded.

Use real cases:

• A new customer with no points.
• A repeat customer with a simple points balance.
• A VIP member near a tier threshold.
• A customer with an active unused reward.
• A customer with expired rewards.
• A customer with a recent order whose points are pending.
• A customer who shops both online and in store.
• A customer who belongs to a Klaviyo segment because of loyalty status.
• A customer who contacted support about a reward issue.

For each case, compare old system, migration file, new loyalty platform, Shopify customer record, Klaviyo profile, POS visibility if relevant, and support visibility. The answer should match the customer promise, not just the import log.

What to do after the new platform is live

After launch, watch the first loyalty cycle closely.

Look for customers who cannot find rewards, points balances that changed unexpectedly, discount codes that fail, Klaviyo messages with old program language, POS staff confusion, support tickets about missing value, and reporting breaks between old and new cohorts.

Do not judge the migration only by whether the new app is active. Judge it by whether customers can recognize the value they earned and whether the team can explain the program without special-case workarounds.

A clean loyalty migration protects the trust layer. The platform can change. The customer's earned value should not feel like it disappeared.