Switching loyalty providers without losing your data

Owners stay on bad loyalty providers for years because the migration feels scarier than the status quo. The fear is overblown if you do it in the right order. A 5-step migration plan that protects member relationships through the cutover — and the one piece of data you should be willing to lose to make the move easier.

Step 1 — Export everything you can, even if it's a mess

Before signing any new contract, get your data out of the old system. Most providers, including the legacy paper-card-tracker apps, have a CSV export buried in settings. If they don't, ask their support — be polite, mention you're "consolidating systems," and you'll usually get an export within a week.

Minimum data to extract:

• Member name + phone number (the unique key)
• Email if available
• Birthday if collected
• Current points balance OR current punch count
• Last visit date
• Total visits / total spend (if available)

What you don't need: full transaction history. Tempting but practically impossible to migrate cleanly across systems with different schemas. Walk away from it; the value's in the relationship, not the receipts.

Step 2 — Decide what to do with current balances

This is the decision most owners agonise over. Three options:

1. Honour them 1:1. Import every member with their existing balance/punches. Members feel respected. Migration takes a day longer.
2. Honour with a multiplier. "We're switching to a new system — your balance carries over with a 20% bonus to thank you for sticking with us." Costs you a small amount; signals upgrade rather than replacement.
3. Reset and announce a fresh start. Tempting but kills goodwill. A loyal customer with 7/9 stamps who sees the program reset to 0/9 will quietly leave.

Use option 1 or 2. Option 3 is the false economy — you'd save 30 minutes of import work and lose the ten months of habit you built.

Step 3 — Run both systems for two weeks

Don't cut over on a Friday at 6pm. Run both side by side for 14 days:

• The old system stays open for queries and edge cases.
• The new system goes live on a specific Monday — every new sign-up and every new transaction goes into it.
• Old-system members who walk in get migrated by the cashier on first visit (one-line script: "We've got a new system, let me move your card over").

Two weeks is enough that 80–90% of active members get migrated organically without any bulk import drama. The bulk import handles the long tail at day 14.

Step 4 — Keep the rewards structure identical for 30 days

Don't combine the migration with a program redesign. If you've been running 9-buy/10th-free, keep it 9-buy/10th-free for the first 30 days on the new system. Members shouldn't have to re-learn what they're earning during the cutover.

After 30 days of stable operation, then experiment. Change the threshold, add tiers, layer a referral program. By that point, members are habituated to the new system and any tweak feels like an evolution rather than a disruption.

Step 5 — Send the announcement, twice

Two messages, sent through whatever channel your members prefer (SMS for most PH SMBs):

1. One week before launch: "Heads up — we're moving to a new loyalty system on [Monday]. Your stamps/points carry over. Same rewards. We'll text you a link to your new account."
2. Day of launch: "It's live. Here's your new sign-in: [link]. Reply if anything's wrong, we'll fix it."

Don't send a third "reminder." Two messages is the right amount. Members who care will engage; members who don't will get migrated by the cashier on their next visit.

What to look for in the new provider

Three questions to ask before signing:

1. Can I export my member list back out? If the answer is "you'd have to ask support," walk. You're back in the same trap.
2. Can I import a CSV at sign-up time? If only the support team can run an import, expect a delay every time you need one.
3. Does the migration cost extra? "Migration services" is a way of charging twice for setup. The right answer is "yes, you can self-serve via the dashboard import."

The actual cost of switching is one weekend of import work and two weeks of dual operation. The cost of staying on a bad provider is the slow erosion of every metric the program is supposed to improve. Do the math, do the migration, then leave the program alone for a quarter.