How to Migrate From a Legacy Loyalty Programme Without Losing Members or Point Balances
Sign up for our newsletter for trending top content!
You migrate a legacy loyalty programme safely by treating the points ledger as a financial record. Map every balance, tier and identity, load them into the new consumer loyalty platform, and run both systems in parallel until the balances match or every difference is explained, then cut over. Members stay when their balance, tier and expiry dates arrive unchanged and they were told in advance what would look different. Disputes come from unexplained differences, so the control that matters is evidence of reconciliation, not speed.
Why Loyalty Migrations Fail: Balance Disputes and Silent Member Loss
Loyalty migrations fail in two ways, one loud and one quiet, and both occur when the new system holds a different version of the member's position from the one the member remembers.
The loud failure is the balance dispute. Legacy platforms frequently derive the displayed balance from rules, such as expiry batches, pending points and reversed returns, rather than storing it as one figure. An extract of a balance column therefore omits adjustments the member can see, and the first statement from the new system disagrees with the old one.
The quiet failure is silent member loss. A member whose login fails because identities did not match, or whose tier benefit is missing, often does not complain. The member simply transacts less, and the loss appears in dormancy reporting weeks later with no ticket to explain it.
The two figures that define success
A loyalty ledger is a record that stores every earn, redemption, expiry and adjustment against a member, from which the balance is derived. Point liability is the amount a finance team provides for points issued but not yet redeemed, which many organisations report under IFRS 15. A migration must preserve both the member level balance and the programme level liability. The diagnostic question is whether the finance controller can sign the total of migrated balances against the last month end liability report.
One counter argument holds that a goodwill credit resolves any dispute cheaply. It does for small residual differences, but a credit with no recorded cause makes the liability figure wrong and teaches members that disputes are paid. Record each credit as a labelled adjustment, never as a silent correction.
Mapping Legacy Data: Balances, Tiers, History and Identity
Map identity first, then balances by expiry batch, then tier status with dates, then history to the depth that rules and disputes require, because every other record attaches to identity.
Identity
Identity resolution is a process that decides which records across systems belong to the same person. Legacy programmes usually contain duplicates, merged cards and shared household accounts, so agree the survivorship rule before the extract is cut. Keep the legacy member identifier permanently as a cross reference, otherwise the service desk cannot trace a complaint to the old record. The Data Protection Officer should approve the field list, because under GDPR and India's Digital Personal Data Protection Act, 2023, the lawful basis and consent record must travel with the member, and a field with no purpose should not migrate.
Balances by expiry batch
An expiry batch is a group of points earned in one period that expire on the same date. Load each batch as its own entry with its original earn date and expiry date. A single total balance silently extends or shortens the life of old points, and either result becomes a dispute. Decide in advance how pending points and negative balances from returns will be treated.
Historical transactions
The depth of history to migrate is a decision, not a default.
The window must be at least as long as the longest of the tier qualification period, the expiry period and the returns period. Keep the legacy archive readable until the longest dispute window has passed.
Translating Old Tiers Into New Ones Without Demoting Anybody
Translate tiers by the status each member holds and the benefits promised, not by tier names, and ensure the migration itself never lowers a tier or shortens its validity.
A tier is a status level that grants a defined set of benefits in return for qualifying activity over a period. Three approaches exist.
The common failure is threshold drift. The new platform may measure qualifying activity differently, for example gross or net of returns, or by spend rather than by points, so a member who cleared the old threshold falls below the new one. Test for it by running the whole member base through the new rules and listing every member whose tier would be lower. That list should be empty or approved by the programme owner and the finance controller.
A protection period has a real cost and delays commercial change. Demotion at migration is worse, because members attribute the loss to the platform rather than to their own behaviour. The approach fails where a benefit has limited capacity, such as lounge access. There, offer an equivalent benefit and say so in writing.
Handling Members Mid Way Through a Qualification Period
Carry each member's progress, not only status: the accumulated qualifying activity and its dates must arrive so that the period neither resets nor extends.
A qualification period is a window of time during which activity counts towards tier status. In a fixed calendar year, an opening entry of activity to date, dated at the period start, is sufficient. In a rolling window, activity leaves on its own dates, so transaction level dates are required and a summary figure is not.
Rekyndl is a consumer loyalty platform from The Reward Store, built on a real time event engine. It evaluates tier movement in real time, which illustrates the point: when evaluation runs as each event arrives, the dates on loaded entries are what the evaluation reads, so the quality of those dates matters more than the volume of history loaded.
Consider a hypothetical grocery chain with a rolling twelve month tier rule. The team loads each member's twelve month spend as a single opening entry dated at cutover. Nothing appears wrong at launch. One year later every one of those entries leaves the window on the same day, and every member drops a tier together, long after the project team has dispersed. Projecting tier status forward by date during testing would have caught it. The fix is to load monthly summaries dated to their own months.
Points that expire during the migration window
Decide which system owns expiry on each date. Run the expiry job once, never in both systems, and suspend it during any freeze. Members whose points expire inside the window should be listed and checked individually.
The Parallel Run and the Cut Over Checklist
Run both systems on the same events and compare results member by member until differences are zero or explained, then cut over using a fixed checklist.
A parallel run is a period in which both platforms process the same events so that their outputs can be compared before one is retired. The legacy system stays the system of record, and the new consumer loyalty platform runs in shadow, invisible to members. Compare balance, tier and expiry batches per member, and classify each difference as a rule difference, a timing difference or a data defect. A difference that cannot be classified is a defect. Run long enough to include one complete cycle of every scheduled process, including the expiry run, tier evaluation and the finance month end.
The approach is wrong in three cases: the legacy system cannot accept replayed events, the contract end date forbids a long overlap, or the programme has only batch feeds with no event stream. In those cases use a freeze window instead. Pause earning, extract, load, reconcile totals and a sample, then reopen, retaining the legacy archive and agreeing in advance how activity during the freeze will be posted with its original dates. Dual running has a real cost, and a short, well controlled freeze is a legitimate choice.
Cut over checklist
- Freeze changes to rules and reward configuration.
- Take the final extract with a recorded timestamp and record count.
- Reconcile points by expiry batch against the ledger and the finance liability report.
- Reconcile member counts and tier counts against the legacy system.
- Test a defined sample that includes zero balances, negative balances, multiple batches, merged duplicates, imminent expiry and members mid period.
- Replay events from the freeze with original timestamps and unique transaction identifiers. An idempotency key is a unique identifier that makes repeated submission of the same event produce a single result, so a replay cannot post twice.
- Test login, identity matching and balance display in staging using real member records.
- Brief the service desk with a dispute procedure and read access to the legacy archive.
- Agree go or no go with named owners, namely the loyalty programme owner, finance controller, Data Protection Officer and head of customer relationship management, with rollback criteria written beforehand.
- Reconcile again at the end of day one and the end of the first week.
A Member Communication Sequence for a Visible Platform Change
Members stay calm when they are told early what will not change, shown what will, and given a way to check their own balance. Send the messages in this order.
Any change in how personal data is used may require fresh notice or consent under GDPR or the Digital Personal Data Protection Act, 2023, and the Data Protection Officer decides.
Some teams prefer minimal notice to avoid prompting scrutiny. Where the change is invisible, such as a back end swap behind the same app with the same login, a short notice is sufficient. Where login, appearance or terms change, silence fails, because members discover the change through a broken login and assume the worst.
Where Rekyndl Fits in a Loyalty Migration
A consumer loyalty platform is where the migrated balances, tiers and rewards live once cutover is complete, and the checks above apply to whichever one an organisation selects. The Reward Store offers Rekyndl, which is built on a real time event engine. Earning rules respond to any behaviour, including transactional, behavioural, lifecycle, service and custom events. The platform provides points, tiers and multi user wallets, with tier movement evaluated in real time. Customer journeys and broadcasts are triggered by the same event that drives earning. Coupons and gift cards are available as reward types, with rewards fulfilment handled end to end. Marketing teams configure programmes in a no code programme builder. It is used across airlines, hotels, banks, retailers, coalition programmes, hospitality and automotive.
Frequently Asked Questions
How long should a parallel run last for a loyalty migration?
A parallel run should last long enough to include one complete cycle of every scheduled process, namely the expiry run, tier evaluation, statement generation and the finance month end. The duration depends on those cycles rather than on a fixed number of days. If the legacy contract or system prevents a long overlap, use a controlled freeze window with full reconciliation instead.
What happens to points that are due to expire during a loyalty platform migration?
Points due to expire during migration should expire once, in one system only. Decide which platform owns expiry on each date, suspend the expiry job in the other, and list members whose batches fall inside the window for individual checking. Load every batch with its original expiry date so that the migration neither extends nor shortens the life of any points.
How do I stop members being demoted when I move tiers to a new loyalty system?
Run the whole member base through the new tier rules before launch and list every member whose tier would fall. Resolve each case by aligning thresholds or granting a protection period that keeps the old tier until at least the end of its current validity. Have the programme owner and finance controller approve any remaining differences before cutover.
Do I need to migrate the full transaction history to a new loyalty platform?
Not usually. Migrate a rolling window at least as long as the longest of the tier qualification period, the expiry period and the returns period, together with balances by expiry batch. Full history is justified when members see it in statements or when retention obligations require it. Keep the legacy archive readable until the longest dispute window has passed.
What should I tell members before we change loyalty platforms?
Several weeks before the change, tell members the date, the reason in plain terms, and that balances, tier and expiry dates carry over. Keep any required action, such as a new password, in a separate message. On day one, send each member their own balance, tier and next expiry date so that they can compare it with their own records.
How does Rekyndl connect loyalty earning to customer messaging?
Rekyndl triggers customer journeys and broadcasts from the same event that drives earning. Earning rules respond to any behaviour, including transactional, behavioural, lifecycle, service and custom events. Tier movement is evaluated in real time, and coupons and gift cards are available as reward types. The messaging takes the form of customer journeys and broadcasts.
Sign up for our newsletter for trending top content!
