Switching channel loyalty platforms without losing your members
Migrations fail in the field, not in the database. The technical work of moving members and balances is a few weeks; the risk is that thirty thousand tradesmen experience a week of confusion, conclude the programme has been cancelled, and stop scanning. Almost everything below is designed around that single failure mode.
Key takeaways
- Members forgive a new app. They do not forgive a balance that changed or a payout that stopped.
- Extract five things: member master, full ledger history, unredeemed liability, code databases and 194R aggregates per PAN.
- Run both platforms in parallel for at least one full payout cycle. Never cut over on a scheme boundary or a festive window.
- Communicate before, during and after in the member's language, with the balance visible at every step.
Before you sign anything: what you must be able to extract
This is the moment of maximum leverage, and it is usually squandered. Get exit terms in writing from the outgoing vendor — or, if you are still selecting, from the incoming one — covering five assets:
- Member master: identity, mobile, KYC status, PAN where collected, trade, geography, enrolment date, tier.
- Full ledger history: every credit, redemption, reversal and deduction with timestamps. Not a summary — the transaction log.
- Unredeemed liability: current balances per member, reconciled to what finance carries.
- Code databases: issued codes, claimed status, batch mapping. Without this you cannot honour a code printed last year on stock still in the channel.
- Section 194R aggregates per PAN for the current financial year, plus certificates already issued.
That fourth item is the one people forget and the one that causes the worst incidents. Product printed eighteen months ago is still sitting in a distributor's godown, and when a plumber scans it next March it has to work.
The migration sequence
| Phase | Duration | What happens |
|---|---|---|
| Extract and reconcile | 2–3 weeks | Pull all five assets; reconcile balances against finance to the rupee before anything moves |
| Load and verify | 2 weeks | Load into the new platform; spot-check 200 members across tiers and geographies by hand |
| Parallel run | 4–6 weeks | Both platforms live; new scans in the new system, redemptions honoured in both |
| Field communication | Throughout | Three waves in-language: notice, switch, confirmation |
| Cutover | 1 day | Old platform read-only, not switched off |
| Read-only tail | 6 months | Old system retained for disputes and audit |
The four rules that decide whether members stay
- The balance must never change. Not by a rupee, not for a day. A member who opens the new app and sees a smaller number will tell forty people the brand stole his points, and that story does not get corrected.
- Payouts must not pause. Not even for a weekend. If there has to be a gap, pre-announce it precisely and pay a small goodwill credit when it ends.
- Old codes must keep working. Stock printed under the previous platform stays in the channel for a year or more.
- Support must know both systems for the whole tail period. A member who calls about a six-month-old transaction should get an answer, not an explanation about a migration.
Communication that actually lands
Three waves, on WhatsApp, in the member's own language, each with his balance shown:
- Two weeks before: what is changing, what is not, and the explicit reassurance that his points are safe. Show the balance.
- On switch day: what to do now, in one instruction. Show the balance again, identical to before.
- One week after: confirmation that everything transferred, plus a small reactivation incentive for anyone who has not scanned since.
Assisted re-onboarding at the counter is worth the field cost. The same tactic that triples initial enrolment works during a migration, and the dealer explaining it in person defuses far more suspicion than any message. See app adoption for low-literacy users.
When not to switch
- Mid-scheme. Finish the quarter and the scheme first.
- In a festive window, when volume and expectations are both peaking.
- Within two months of financial year end, because 194R aggregation and certificate issuance are hard enough without a system change in the middle.
- When the real problem is scheme design. A new platform will not fix rates nobody finds worth scanning for — read reviving a failing loyalty programme before you blame the software.
The question to ask both vendors
Ask the incoming vendor how many live migrations they have completed, and ask to speak to a brand that went through one. Ask the outgoing vendor, in writing, for the five assets above with a delivery date. The gap between how those two conversations go is usually the clearest signal you will get about whether the move is a good idea at all.
About this comparison
This page is published by Unotag, so treat it as a vendor's point of view rather than an independent review. Everything stated about other companies comes from their own public material and from published press as of August 2026; products change, so verify current capability directly with each vendor. Where we do not know something — pricing in particular is rarely published by anyone in this category — we say so instead of guessing. If you find anything here inaccurate, tell us at support@unomok.com and we will correct it.
Frequently asked questions
What do I need to extract when switching loyalty platforms?
Five things: the member master including PAN where collected, the full ledger transaction history rather than a summary, unredeemed liability reconciled to finance, the code databases with issued and claimed status, and Section 194R aggregates per PAN for the current financial year plus certificates already issued.
Why do loyalty platform migrations fail?
In the field rather than the database. The technical move takes weeks, but if thirty thousand members experience a week of confusion, a changed balance or a paused payout, they conclude the programme has been cancelled and stop scanning. Almost every migration control exists to prevent that specific outcome.
How long should a loyalty migration take?
Roughly three months: two to three weeks to extract and reconcile, two weeks to load and hand-verify a sample of about 200 members, four to six weeks of parallel running with both platforms live, a one-day cutover to read-only, and a six-month read-only tail for disputes and audit.
What happens to codes printed under the old platform?
They must keep working, which is why the code databases are a required extraction. Product printed eighteen months ago sits in distributor godowns and will be scanned next year, so the new platform needs the issued codes, their claimed status and batch mapping loaded before cutover.
How should members be told about a platform change?
Three WhatsApp waves in the member's own language, each showing his balance: two weeks before explaining what changes and reassuring that points are safe, on switch day with a single instruction and an identical balance, and one week after confirming the transfer with a reactivation incentive for anyone who has not scanned.
When should I not switch loyalty platforms?
Mid-scheme, during a festive window, within two months of financial year end when Section 194R aggregation and certificates are due, or when the real problem is scheme design rather than software. A new platform will not fix reward rates that members do not find worth scanning for.