Create awareness, foster engagement, transform experiences, and cultivate loyalty.
Flexible, cutting-edge technology that transforms experiences and drives loyalty.
Loyalty without limits. Powering personalized experiences that build brand love and transform customers into loyal advocates.
Revolutionizing how companies engage with their audiences by sparking participation to drive growth.
Most loyalty teams treat platform migration as a data export problem. It’s closer to four separate problems that can each fail without touching the others. A member who earned points the day before cutover and doesn’t see them in the new system calls support. If your team can’t explain it, you’ve lost the trust the program was built to earn.
Ten test cases have to pass before your new platform goes live, including a split-tender transaction combining partial points and partial cash. It’s rare, but it breaks in ways that are hard to explain to a member standing at a register.
Points survive when four data layers are mapped, reconciled, and validated before the new platform goes live. Left unmapped, points land in the wrong account or pending transactions fall through the space between systems. Loyalty points are a financial liability on your balance sheet and a trust contract with your members. A failed transfer damages both.
Treating a loyalty migration as “export balances to CSV” is how points get lost, members get locked out, and finance teams discover unexplained variances after launch. Every migration must address four data layers, each with its own owner and its own way to break.
The following must travel together or not at all:
Without a stable join key, point balances can’t be reliably matched to the right person. An unstable identity layer means duplicate profiles, failed login access, and members who can’t see their own points on day one.
Consent records carry compliance weight under GDPR, CCPA, and CAN-SPAM. If a member opted out of SMS in the legacy system and that preference doesn’t carry over, the first message you send on the new platform is a violation.
This is the layer most often mixed together, and mixing it up is where member disputes start. Four instruments have to be tracked on their own terms:
Transaction history, covering purchases, earn events, redemptions, returns, and adjustments, is the behavioral foundation for segmentation, targeting, and personalization on the new platform. Members who lose their history become anonymous to the new system.
Incomplete history also undermines any AI-driven or predictive capability the new platform offers, since those models depend on longitudinal member data. Migrate balances without the transaction stream that created them, and you are starting from zero.
Earn rules, tier thresholds, expiration logic, exclusions, and automated campaign triggers must be rebuilt in the new platform, rather than simply imported. Organizations that have run on the same platform for years routinely discover during migration discovery that they don’t fully understand their own rules. A rule configured years ago may still be running with no clear owner. Surface this complexity before cutover. The new platform won’t inherit your legacy logic by default, and every rule must be documented, validated, and reconfigured.
Point balances are a financial obligation to members, and the standard of proof is the same as any other liability class: a signed, documented opening balance before the new platform becomes the system of record.
A reconciled opening balance includes:
The acceptable variance threshold is set by finance and legal. The technology vendor doesn’t get a vote. If your finance team won’t sign off on the opening balance, you are not ready to cut over.
Two levels of reconciliation must both pass: member-level, where individual account balances match, and aggregate, where total liability matches across the entire program. Common variance causes include:
Each variance needs a documented resolution. If the aggregate liability is off and you can’t tie it to specific accounts, that is a finance event, not a CX issue.
There is always a gap between when you export member data and when the new platform goes live, and members keep earning and redeeming during that window. A migration plan must include a mechanism, whether a delta load, event replay, or transaction queue, to capture that activity and apply it before cutover.
Transactions that fall into this gap are the most common source of post-launch member disputes. A member who earned points the day before launch and doesn’t see them in the new system will contact support, and if your team can’t explain what happened, you have lost trust.
A migration is complete when members can access the program, balances are trusted, and the program behaves as designed. “Most scenarios passed” isn’t an acceptable launch gate when member balances or stored value are involved.
Ten test cases must pass before cutover:
Core transactional flows are what members hit on day one. A return that reverses the wrong earn amount or a redemption that doesn’t post generates immediate complaints and increases support volume. Test these flows across every channel the program operates in, not just the primary one.
Every connection must be reviewed and tested against the new platform’s APIs, data model, and transaction requirements. Switching platforms often means rebuilding integrations from scratch, even when the underlying POS or ecommerce system has not changed.
A loyalty program that earns correctly online but fails at the register is a member experience failure on the highest-volume channel.
Duplicate member profiles that must be merged without losing either account’s balance, split-tender transactions, offline store activity that must sync after connectivity is restored, and customer service balance adjustments with complete audit history are lower frequency but high impact when they fail. Your support team needs a documented process to investigate and resolve these cases before launch, not after the first wave of complaints.
Whether members keep their existing login, balance visibility, and authentication depends on the architecture of both platforms, and on what the source system can actually export. Don’t promise seamless continuity until this and mobile app dependencies have been validated. If the new system uses a different identity provider or can’t import hashed passwords, a forced reset is required. Tell members before launch because finding out at the login screen is worse.
Member communication is a pre-launch requirement, not a post-launch task. The message should be honest: the program is being upgraded. Avoid language that implies accounts have been reset or that members need to re-earn their status.
Four moments require communication:
Frontline employees are often the first point of contact when something goes wrong. If a member asks why their balance looks different, the employee needs a clear, confident response ready before the new platform is live.
The support team needs visibility into both the legacy and migrated balance for each member, a documented process for investigating and resolving discrepancies, and authority to issue goodwill adjustments when a variance can’t be fully explained. A member who contacts support and receives a confident, accurate response retains trust. A member who gets a vague answer loses it.
A platform switch is the single best opportunity to clean up years of accumulated program complexity: rules no one owns, segments no one uses, integrations held together with workarounds. Migration forces that debt into the open. The brands that treat migration as a program reset come out with a cleaner, faster, more capable program.
Your legacy platform likely batch-processes member data, meaning loyalty events, including a tier upgrade, a points expiration, or a high-value redemption, trigger marketing responses hours or days later. A modern platform built on real-time data ingestion changes that. A member who crosses a tier threshold receives a congratulatory message and benefit activation immediately, not the next day. That responsiveness is the difference between a program that feels automated and one that feels attentive.
Migration discovery surfaces rules that no one on the current team configured and no one fully understands. This is the natural result of your program evolving over years across multiple team members and business priorities.
Migration is the moment to audit every rule, retire what no longer serves the program, and rebuild what remains with clear ownership and documentation. The program that launches on the new platform should be leaner and better understood than the one that left.
A migration that preserves member balances, maintains earning and redemption continuity, and communicates clearly is a demonstration that the brand honors its commitments to members. Members who trust the program engage more, redeem more, and spend more. A migration that erodes trust through lost points, broken access, or poor communication does the opposite, and the cost of member churn following a bad migration far exceeds the cost of doing it right.
A technology vendor who can import a CSV isn’t the same as a partner who has managed migrations at programs processing billions of transactions. The right partner brings both technical execution and strategic loyalty expertise. Before selecting a migration partner, ask:
Phaedon’s services team operates as an extension of the client’s team, not a vendor relationship. The team has answered these questions at programs of significant scale and complexity, including travel and hospitality brands with complex tier structures, co-brand partnerships, and franchise rule sets, where a failed migration isn’t recoverable with a public apology.
Tier status, including progress toward the next tier, must be explicitly mapped and migrated as part of the member identity layer. If tier data isn’t included in the export and import, members will lose their status on day one.
Pending points, meaning earn events that have been triggered but not yet settled, are one of the most common sources of post-launch balance discrepancies. The migration plan must account for in-flight transactions and include a mechanism to apply them to the new system before or immediately after cutover.
Whether earning and redemption can continue during cutover depends on the migration approach. A big-bang cutover typically requires a brief maintenance window, while a parallel run or phased rollout can maintain continuity. The cutover plan should specify exactly what members can and can’t do during the transition window, and communicate that clearly in advance.
Changing earn rates at the same time as a platform switch compounds complexity and makes it harder to isolate whether post-launch engagement changes are driven by the new platform or the new program economics. Separate the technology change from the program design change wherever possible.
Sign-off on reconciled point balances should involve finance, legal, and the loyalty program owner, not just the technology team. Point balances are a financial liability, and the decision to accept a variance threshold carries accounting implications.
The legacy platform should remain accessible long enough to investigate and resolve any balance discrepancies that surface in the days following launch. Retiring the legacy system too quickly removes the audit trail needed to resolve member disputes.
Whether members need to reset credentials depends on how authentication is handled between the two platforms. If the new platform uses a different identity provider or can’t import hashed passwords, a forced reset is required, and members should be told this before launch, not after they fail to log in.
