Guide 55 · Technology
Loyalty platform migration: what breaks and how to plan it
A loyalty migration is a change to a promise, not just a data move. What breaks most often is the value of members' points and their tier status, followed by refunds and partner activity that straddle the cutover. Plan it by deciding first whether balances move at the same value or are settled before the switch, then run the old and new ledgers side by side until they reconcile, and tell members early.
A loyalty platform migration, moving a program from one system to another, looks like an IT project. For members it is something else: their points, their status and the rules they signed up to all pass through the switch. Most migration problems come from treating the program’s promises as data fields. This guide sets out what tends to break and how to plan around it.
What breaks
What actually breaks in a loyalty migration?
The common failures fall into six groups:
- Point value. A balance that moves at a different earning or redemption ratio is worth something different, even if the number looks the same.
- Tier status. The new system recalculates tiers from incomplete history, and members are demoted or promoted by mistake.
- Transactions across the cutover. A purchase made on the old system and refunded on the new one has no original earn record to reverse. Pending partner points land in a system that does not expect them.
- Identity. Duplicate or merged member records split one balance into two, or join two members into one.
- Expiry dates. If points expire by age, each batch of points has its own earn date. Loading a single balance with a new date resets every clock; dropping the dates can expire points early. See should loyalty points expire.
- History. Members and service agents lose the transaction history they use to resolve disputes.
Each of these is a member-facing problem, not just a technical one, and each needs an owner in the plan.
Move or settle
Should you move balances or settle them first?
This is the first decision, and it shapes everything else. Apply a simple test: a member holds 1,000 points the night before the switch. The morning after, can they redeem those 1,000 points for exactly the same value, with no new terms to accept, no conversion and no call to support? If the answer is yes for every balance, you can move balances.
| Approach | How it works | When it fits | Main risk |
|---|---|---|---|
| Move balances at the same value | Balances, history and tiers transfer unchanged | Same program, new platform | Data errors in the transfer |
| Convert at a new ratio | Balances transfer but buy something different | Program redesign at the same time | It is a devaluation and must be handled as one |
| Settle, then restart | Earning stops, members get a window to redeem, the remainder is paid out as vouchers or credit | The old program is ending, or a new operator takes over | Cost of paying down the liability at once |
If the new platform is run by a different company, make sure the contract says who owes members the value of their existing points. A converted ratio is a points devaluation, whatever the project calls it, and needs notice and a clear explanation.
Protect the liability
How do you protect the points liability through the move?
Outstanding points are a points liability on the balance sheet. The total on the new platform must match the total on the old one, member by member, before and after the switch. Ask finance to define the reconciliation: which totals must agree, the tolerance for differences, and who signs off.
Audit the old ledger before you copy it. Legacy systems often contain balances that do not match their transaction history, dormant accounts nobody has reviewed and manual adjustments without reasons. Copying those problems into a new system makes them harder to find. Sample dormant accounts, check that each balance equals the sum of its history, and fix or document every exception.
Run in parallel
How long should the old and new systems run side by side?
Long enough that the daily reconciliation is consistently clean. During a parallel run, every transaction goes to both systems and the results are compared each day: balances, points earned, redemptions and tier changes. Each difference is traced to a cause and fixed, with a named owner.
The parallel run is expensive. In a hypothetical program that issues 36 million points a month, even a 2% mismatch means 720,000 points to investigate every month, plus engineering time to fix the causes. That cost is still far lower than correcting a live system after members find the errors. Do not set the final cutover date until the mismatch rate has been near zero for a sustained period.
Also check whether the old ledger can be frozen for a short window around the cutover without harming members. If it cannot, plan how transactions during that window will be captured and replayed.
Move tier status
How do you move tier status without surprise demotions?
Run a shadow calculation. Feed several months of settled transactions through the new tier logic and compare the result with each member’s current tier. Explain every difference before cutover. A difference usually means the new system is missing history, applies a rule differently or reads a different qualification period.
Where the history cannot be rebuilt, carry members’ current tiers over as they are until the next qualification date, so no one loses status because of the migration itself. If you also plan to change tier rules, do it later as a separate step, with its own notice.
Tell members
What should members be told, and when?
Tell them before anything changes. A good notice explains what will stay the same (balances, status, the value of points), what will change (a new app, a new login, a new card number), when it happens and what members need to do, if anything. If any rule or value changes, it may count as a material change under your terms, with a required notice period.
Expect a short spike in contacts after the switch. Brief service agents in advance, give them access to the old history for a while, and publish a simple FAQ.
The checklist
What does a migration checklist look like?
- Decide whether balances move at the same value, convert or are settled first.
- Write the event contract for the new ledger: earn, adjustment, reversal, redemption, expiry and tier change, each with a unique ID.
- Audit and clean the old ledger, including dormant accounts, duplicate members and point expiry dates.
- Plan transactions that straddle the cutover: refunds, pending partner points and open redemptions.
- Run old and new ledgers in parallel and reconcile daily until clean.
- Shadow the tier calculation and explain every difference.
- Agree the reconciliation and sign-off with finance.
- Agree rollback criteria in advance: the errors that would send you back to the old system, and who decides.
- Notify members, brief service teams and keep the old history accessible.
- Change program rules only after the migration is stable.
If you are still choosing the new platform, put balance export and history import in the requirements now. See build or buy a loyalty platform and headless or suite.
More answers
Frequently asked questions
How long does a loyalty platform migration take?
It depends on the number of channels, partners and members, but the parallel run is often the longest part. Plan for several months of running the old and new ledgers side by side, and do not fix the cutover date until reconciliation is clean.
Do members keep their points when a program changes platforms?
They should, at the same value, unless the program settles balances before the switch. Converting points at a new ratio is a devaluation, even if it happens inside a technical project, and should be treated and communicated as one.
Do points keep their expiry dates after a migration?
They should. If points expire by age, the new platform needs each batch of points with its original earn date, not just a total balance. Loading one balance with a new date quietly extends every member's points, while losing the dates altogether can expire points early.
What happens to refunds for purchases made before the migration?
The new platform needs the original earn records, or a reliable link to them, so a refund can reverse the right points. Without that history, staff end up posting manual deductions that members dispute.
Should we change program rules at the same time as the platform?
It is safer not to. Migrate the existing rules first, confirm balances and tiers match, then change rules in a separate, announced step. Combining both makes every difference hard to explain.
Who should approve the cutover?
Finance as well as the program and technology teams. The points liability must match on both sides, so finance should sign off on the reconciliation before the old system is switched off.