SafeSwitch™: Zero-Downtime Enterprise Loyalty Platform Migration
Loyalty platform migration with SafeSwitch™
Don't trust the migration. Prove it.
SafeSwitch™ is the cutover methodology Loyalty Methods uses to move enterprise loyalty programs onto ReactorCX, its enterprise loyalty platform, without member-visible downtime or lost data. ReactorCX runs in parallel with the legacy system and advances through four gates, reconciling every balance, tier and transaction before any member moves. A rollback path stays armed until the switch is confirmed.
SafeSwitch™ is patent pending.
Balances · Tiers · Earned · Redeemed · Expiry · Partner balances — matching
Every account checked against production, not a sample
How this is measured
Sum of member records moved from a legacy platform onto ReactorCX in SafeSwitch cutovers; excludes greenfield programs. As of 2026-Q3.
How this is measured
Historical transaction records loaded into ReactorCX and reconciled against legacy outputs during SafeSwitch migrations. As of 2026-Q3.
How this is measured
Number of SafeSwitch production cutovers completed and the number completed with zero member-visible downtime. As of 2026-Q3.
How this is measured
Elapsed time from ThreadSync Vision Alignment kickoff to production cutover across completed enterprise implementations. As of 2026-Q3.
Why is replacing a legacy loyalty platform so risky?
A loyalty program is a ledger of accumulated trust. Members can see their points, their status, and their history, and they notice the instant any of it is wrong. The traditional approach treats migration as a single event: freeze the old system, move the data, open the new one, and hope. A big-bang cutover gives you one attempt and no way back.
The error is also asymmetric. Members forgive a slow page and forget a brief outage. They do not forgive a points balance that fell overnight, a tier they earned and no longer hold, or a reward that vanished. Rip-and-replace does not fail because the data is hard to copy. It fails because correctness is hard to prove, and the traditional approach proves it in production, with real members, after the point of no return.
What a big-bang cutover finds out too late
- A rule configured differently in production than the documented terms, found after members do.
- A balance off across a tier, found at the call center.
- A platform that cannot hold day-one load, found when every location transacts at once.
- Live earning rules, redemption logic and every integration, all tested at once on the first day real members are present.
How does the six-step proof work?
Legacy, parallel run, compare and reconcile until they match, prove, controlled cutover. Rollback stays armed throughout.
1 · Legacy keeps serving
The legacy platform keeps serving members and stays authoritative. Nothing about the member experience changes yet. ReactorCX is stood up alongside it, configured with the program’s full rule set.
2 · Parallel run
Every qualifying transaction that hits the legacy system also flows to ReactorCX, which processes it in shadow with no member exposure. Nothing is simulated: real production traffic from day one.
3 · Compare
Both systems’ outputs are set side by side across the entire member base, not a sample: every balance, every tier state, every earned and redeemed point. Compare and reconcile repeat as many times as it takes.
4 · Reconcile
Where the two systems disagree, the discrepancy is run down to its cause, fixed once and replayed everywhere it applies. Traffic that arrives while the fix goes in is held and replayed afterwards, so ReactorCX catches up without missing a transaction. Replay runs at up to 10× production speed, so it doubles as a load test.
5 · Prove
The gate clears only when a full pass over the member base finds no differences, and ReactorCX keeps matching as new traffic arrives. Readiness is signed off on real output, however many passes it takes to get there.
6 · Cutover
Live traffic is redirected to ReactorCX. It is a routing change, not a rebuild, so members never see it. The legacy system stays synchronized and rollback stays armed until live correctness is confirmed.
See this run on a copy of your own traffic.
See a parallel migrationHow does the SafeSwitch™ four-gate cutover work?
SafeSwitch™ replaces the single event with a sequence. ReactorCX advances through four gates, and traffic does not move until each one is cleared.
Gate 1 · Shadow Run
ReactorCX is stood up alongside the legacy system, configured with the program's full rule set, and connected to the same production event stream the legacy platform receives. Every qualifying transaction that hits the old system also flows to the new one. Nothing is simulated. The new platform processes real production traffic from day one, in shadow, with no member exposure.
Gate 2 · Reconcile
With both systems processing identical traffic, their outputs are compared. Every balance, every tier state, every earned and redeemed point is reconciled against the legacy platform across the entire member base, not a sample. Where the two systems disagree, the discrepancy is run down to its cause. The gate clears only when the new platform produces the same answers as the old one, account by account, and keeps matching as new transactions arrive.
Gate 3 · Cutover
Only now does live traffic move to ReactorCX. Because the platform has already been validated against the full member base and the full production load, the switch is a redirect, not a rebuild. Members never see it. The legacy system stays available the entire time.
Gate 4 · Reversal Ready
The legacy system stays running, current, and synchronized, and the rollback path stays armed until ReactorCX is confirmed correct in live production. If anything does not match what reconciliation predicted, traffic returns to the legacy platform without a restore and without data loss, because the old system never stopped being correct. The rollback is not a recovery plan. It is a system that is still on.
What does reconciliation cover?
Reconciliation runs across the whole program, not a sample and not a subset of data types.
| Reconciled | What is checked | Why it matters |
|---|---|---|
| Member balances | Every currency and sub-balance, per account | A balance that moves overnight is the failure members notice first |
| Tiers and status | Current tier, qualification progress, expiry dates | Status is earned; losing it at cutover is unforgivable |
| Expiry lots | Original earn dates, expiry schedules, warning events | Expiry and breakage behave identically after the switch |
| Historical transactions | Loaded with source tags and lineage, then replayed | Liability and audit history stay complete |
| Partner balances | Partner wallets, funded value, settlement positions | Partner economics cannot drift during a migration |
| Promotions and rules | Rules as documented versus rules as they actually run | Configuration drift is found before it is carried forward |
| Integrations and downstream feeds | Every input and output channel, events and batch feeds | The systems around the program keep working through the move |
Scope per engagement is set in Vision Alignment. Reference flow: parallel run and reconciliation.
What capabilities make each gate trustworthy?
The four gates are the spine. The capabilities that run inside them are what make each gate trustworthy.
Built-in program rule audit
Documented terms and live behavior drift apart over years of operation. SafeSwitch™ replays real transactions through both the rules as documented and the rules as they actually run, then shows where the two diverge.
Replay and reprocessing
When reconciliation finds a difference, affected transactions are replayed through corrected logic and balances are reprocessed at scale. A rule fixed once is applied everywhere it should have applied.
Built-in performance testing
Replay moves at a multiple of live speed, so a year of volume can be processed in a fraction of the time, against the program's own production history, not a synthetic load model.
Real production preview
Every member-facing output the new platform will generate is reviewed from real data before a single member sees it: statements, balances, tier progression and the Member Care Portal surfaces.
Risk moves to before go-live
Every check that normally happens in production, with members watching, happens during reconciliation, with no one exposed.
Zero member-visible downtime
The cutover changes which system answers; it does not pause the program to find out whether the new system can.
How do ThreadSync™ and SafeSwitch™ work together?
ThreadSync™ and SafeSwitch™ are two phases of the same migration. ThreadSync™ is the implementation methodology that builds and validates the program: six workstreams (Enroll, Earn, Burn, Service, Integration, Data) run in parallel from kickoff, each with a "done when" test, reconciled at shared sync points. SafeSwitch™ is the cutover methodology that follows. ThreadSync™ builds and proves the program. SafeSwitch™ proves the switch. Both are preceded by Vision Alignment, a two-to-three-week engagement that maps the as-is, transition and target views before a platform is chosen.
Implementations on ReactorCX have run from 3–18 months from kickoff to go-live; the variable is scope, not effort per week.
Vision Alignment
Phase 01. Produces the map: as-is, transition and target views.
ThreadSync™
Phase 02. Builds against the map in six parallel threads. Hands over a validated configuration.
SafeSwitch™
Phase 03. Runs the four-gate cutover. Hands over a running program.
Operate
Your team runs the program, with the same engineers on call.
What is the SafeSwitch™ track record?
The record is the same across every ReactorCX legacy replacement: zero member-visible downtime.
Gap Inc. Encore
Four brands unified on one program, with the program redesigned mid-flight, and zero member-visible downtime at cutover.
MGM Resorts
Three legacy systems unified into MGM Rewards, with no PII stored in the loyalty platform.
Western Union
The largest Loyalty Methods migration to date, running across dozens of countries with multi-currency support.
7-Eleven
7Rewards across the US and Canada. ReactorCX as system of record since February 2020.
bp Earnify
Five brands unified under one program with dozens of integrated partners.
"There was a time when you could close the stores for a few hours and run a migration overnight. That world is gone. Members shop on their phones all the time, so zero downtime is not the goal, it is the baseline."
Emil Sarkissian, CEO, Loyalty Methods. From the Gap Inc. session at CRMC 2026.
Is SafeSwitch™ built to clear enterprise IT and procurement?
A parallel run means member data lives in two systems during the migration window, which raises the bar on how it is protected. Every cutover runs within the SOC 2 Type II attested ReactorCX platform, under the same controls that govern the program in steady state.
- Role-based and attribute-based access control, scoped and logged
- Encryption in transit (TLS) and at rest (AES-256) with cloud-native key management
- Single sign-on via standard federation (OIDC)
- Full audit trails across access, configuration change and transaction activity
- Two privacy modes: PII inside the platform, or tokenized identifiers with PII held in a client-controlled system
- AWS cloud-native deployment with multi-environment and disaster-recovery patterns
Frequently asked questions
What is SafeSwitch™?
SafeSwitch™ is the cutover methodology Loyalty Methods uses to move enterprise loyalty programs onto ReactorCX without member-visible downtime or lost data. ReactorCX runs in parallel with the legacy system and advances through four gates, reconciling every balance, tier and transaction against the live program before any member moves. A rollback path stays armed until the switch is confirmed correct in production.
What are the four gates?
Shadow Run, Reconcile, Cutover and Reversal Ready. No gate advances unless the prior gate passes.
How long does a SafeSwitch™ shadow run last?
Until the two systems agree account by account and keep agreeing as new traffic arrives. Duration is set by reconciliation results, not by a calendar.
What happens to historical transactions?
They are loaded with original earn dates, expiry, source tags and partner balances, so expiry, burn order and settlement behave identically after cutover. Gap Inc. moved 700M+ Gap Inc. historical transactions migrated this way.
Can we roll back after cutover?
Yes. The legacy system stays synchronized and rollback is a routing change, not a restore, until live correctness is confirmed.
How does replay provide performance testing?
Replay runs faster than production traffic (10× production speed), which evidences that ReactorCX can carry well above normal volume on the program's own history. At 7-Eleven this validated sub-second responses, faster than the previous system, with headroom proven before the switch.
Walk through your cutover with the team that runs them.
A parallel-migration walkthrough shows the four gates on a program like yours. A Migration Readiness Assessment tells you, in writing, what your migration would take.