Loyalty platform migration: how to switch without losing balances or history
Resources · Guide
A loyalty platform migration moves a live loyalty program —its members, balances, point batches, tiers and history— to a new system without members losing anything. It's done in stages: reconciled opening balances, account claiming, a parallel run and a planned cutover.
- InventoryMembers, balances, lots
- OpeningBalances loaded
- ReconciliationDifferences report
The members
- ClaimAccount via OTP
- Parallel runBoth systems compared
- HistoryTiers and movements
- Stage 1Opening balances
- Stage 2Parallel run
- CutoverLegacy system off
- 18MMembers on QurableTotal the platform manages today
- < 50 msMember recognized at checkoutp95, measured server-side
- 1–3Months to go liveWith your current program or from scratch
- 99.5%AvailabilityMonthly SLA · ISO 27001
Key takeaways
- Each migration stage ends with something verifiable, from an inventory to cutover with the old system switched off.
- Most migration problems show up before cutover, if you look for them.
- With Qurable, the pilot goes live in 1 to 3 months; the full migration depends on scope.
Two ways to migrate
A one-day cutover or a staged migration.
Switching off the old system on Friday and turning on the new one on Monday looks faster. In a loyalty program with millions of balances, the weeks you save come back as complaints, manual adjustments and lost trust.
| One-day cutover (big bang) | Staged migration | |
|---|---|---|
| Balances | Loaded once and checked when complaints arrive | Loaded as opening balances with a reconciliation report |
| Validation | You find out in production whether the rules calculate the same | Both systems run in parallel and are compared before cutover |
| Members | Get a new username and password, or lose access | Claim their account with a one-time passcode (OTP) |
| Risk | The whole program exposed on the same day | Contained by stage, channel or country |
| Rollback | Hard: the old system is already out of date | Possible while the parallel run lasts |
The plan
A migration in four stages.
Each stage ends with something you can verify: an inventory, a reconciliation report, a parallel comparison and a cutover with the old system switched off.
Data inventory
Members, balances, batches with their expiration, tiers, active coupons and history: what exists and where.
Rules map
Every earning, redemption, expiration and tier rule in the old system, written down and validated.
Integration map
POS, ecommerce, app, CRM, partners and reports that talk to the old system today.
Acceptance criteria
Which balance differences are tolerated, who signs off and what triggers a rollback.
Opening balances
Each member comes in with their balance as an opening entry, not as an edited number.
Reconciliation report
The migrated total is compared with the old system's, member by member and in aggregate.
History
What moves to the new system and what stays archived, searchable for support and audit.
Both systems at once
The same transactions go through both, and the points each one calculates are compared.
Every difference explained
Each gap has a cause: a mis-mapped rule, a rounding issue or missing data.
Account claiming
Members activate their account in the new channel with a one-time passcode.
Date and window
A planned cutover outside sales peaks, with the team on call.
Closing the old system
A final reconciled balance and an opening liability agreed with finance.
Extra support
Customer service with the member view and a script for the first weeks.
Risks
What can go wrong and how to prevent it.
Most migration problems are visible before cutover if you look for them. These are the most common in large points programs.
| Risk | How to prevent it |
|---|---|
| A member sees fewer points than before | Opening balances with a per-member reconciliation report, and every difference explained before cutover. |
| Liability doesn't match the books | Reconcile the opening loyalty points liability with finance before switching off the old system. |
| Points expire earlier or later than promised | Migrate each batch with its expiration date, not just the total balance. |
| Expiration rules change | New rules shouldn't affect points already issued, and members should hear about any change well in advance. |
| Duplicate members or missing contact data | Clean the base before migrating and decide which identifier wins (phone, email or ID). |
| Account takeover during the switch | Account claiming with a one-time passcode sent to the contact already on file. |
| Support can't answer about older transactions | Decide which history migrates and keep the rest archived and searchable. |
| A partner keeps sending transactions to the old system | A cutover schedule per partner and per integration, tested during the parallel run. |
| A POS stops earning points | The sale should never be blocked, and earning should queue if the service doesn't respond. |
| The program runs on COBOL or a legacy system with no API | Extract through files, document the rules buried in the code and validate them in the parallel run. |
| Nobody knows every rule | Rebuild them from real transactions: if the parallel run calculates the same, the rule is right. |
Requirements
What to ask the new vendor.
A migration is decided in the contract and the plan, not on cutover day. Ask these before you sign.
A reconciliation report
Member by member and in aggregate, in a form your finance team can audit.
A parallel run
How long it lasts, what gets compared and who approves the cutover.
How members claim their account
No new passwords by email: a one-time passcode sent to the contact on file.
Batches with their expiration
The new system should honor each batch's date, not just the balance.
A staged plan with milestones
What works at the end of each stage and which criteria define cutover.
Your future exit
How you export members, balances and transactions if you ever switch again.
With Qurable
How Qurable migrates a live program.
Qurable starts with one program: it migrates members and balances, runs in parallel before cutover and gets the pilot into production in 1 to 3 months. Full migration depends on scope.
Reconciled opening balances
Members and balances come in as opening balances on a double-entry ledger, with a reconciliation report.
See the points ledgerAccount claiming with OTP
Each member claims their account with a one-time passcode, on a single record with all their identifiers.
See the Customer Data PlatformParallel run
The program runs in parallel before cutover, and bulk adjustments reconcile to the point, never applied twice.
See the migration questionsIntegrations already connected
Napse (TOTVS), VTEX, Shopify, Salesforce, Microsoft Dynamics and more, already live at customers, with an API, webhooks and file exports.
See the platform
FAQ
What people ask about migrating a loyalty program.
For loyalty, technology and finance teams about to switch platforms.
It's moving a live loyalty program to a new system, with its members, balances, point batches, tiers, coupons and history. The goal is that members lose nothing and finance can reconcile the points liability before and after the switch.
It's the entry that brings each member into the new system with the balance they had in the old one. It's recorded as a ledger entry, not an edited number, and comes with a reconciliation report comparing the migrated total with the source system's.
Because it's the only way to prove the new system calculates the same as the old one with real transactions. During the parallel run, the same purchases go through both systems, points are compared and every difference is explained before the old one is switched off.
It depends on scope: the number of members, rules, integrations and partners, and the state of the old system. A staged plan gets a first part into production sooner and migrates the rest by channel, country or partner.
Yes. The usual approach is to extract members, balances and transactions through files, document the rules buried in the code and validate them in a parallel run with real transactions. The biggest risk isn't the technology but the rules nobody wrote down.
It can, if expiration rules or how batches are consumed change, or if members lose access to their accounts. Migrating each batch with its date and keeping account claiming simple limits the effect. This isn't accounting advice: your accounting team and auditor decide how to treat it under IFRS 15.
Qurable migrates members and balances as opening balances with a reconciliation report; each member claims their account with a one-time passcode (OTP), and the program can run in parallel before cutover. The pilot reaches production in 1 to 3 months; full migration depends on scope.
Last reviewed
Further reading
Keep reading before you switch platforms.
Pages that help you choose the new system and protect balances.
- ResourceLoyalty RFI, RFP and RFQ checklist
The questions to evaluate platforms, migration included.
- ModulePoints ledger
Batches, expirations, reconciliation and the liability of every point.
- ConceptLoyalty points liability
What it is, how it's calculated and how to control it.
- ResourceEnterprise loyalty platform for Latin America
What it takes to run one program across countries.
- PlatformThe loyalty and engagement platform
Five modules that share the same profile, rules and ledger.
About to switch platforms?
In a 45-minute technical session we show you how your program would migrate to Qurable, with a case like yours.