Case Study Summary
This loyalty platform migration case study documents how approximately 60 participating Your CBD Store franchise locations moved roughly 100,000 existing loyalty member enrollment records from Fivestars and TapMango environments into Preferred Patron™ during a coordinated 2019 rollout.
The project was designed around customer continuity. Existing members were not required to re-enroll. Available member data and point balances were transferred electronically, production cutovers were performed after the close of business, and the new Preferred Patron environment was available before the next business day. The planned store cutovers created no customer-facing loyalty downtime.
SunFlora corporate provided program guidance and helped coordinate participating franchises, while GPP Mobile served as a program support and communications agency for the rollout. Preferred Patron support advisors worked with source exports, store configurations, campaign definitions, reward rules and POS environments to create a repeatable migration process that could be applied store by store.
No member re-enrollment was required, sandbox dry-runs were completed before production migration, and final store exports were taken after close and imported before the start of the next business day.
At a Glance: Loyalty Platform Migration
| Migration Detail | Implementation |
|---|---|
| Client environment | Participating Your CBD Store franchise-owned locations in a SunFlora-coordinated rollout |
| Locations migrated | Approximately 60 |
| Loyalty population | Approximately 100,000 existing member enrollment records across participating stores |
| Typical store enrollment | Approximately 800 to 2,500 members per location |
| Previous loyalty platforms | Fivestars and TapMango |
| New loyalty platform | Preferred Patron™ |
| POS environments | Square POS, Vend (now Lightspeed Retail X-Series), and standalone/kiosk workflows |
| Franchise ownership structure | Single-store owners and multi-store owner groups, generally ranging from one to five stores |
| Overall rollout | Approximately three months |
| Typical prepared-store migration | Approximately three business days from migration work through go-live |
| Final production cutover | Source export after close of business; import and validation before the next business day |
| Customer re-enrollment | Not required |
| Customer-facing downtime | None during planned store cutovers |
| Pre-production testing | Dry-run testing in a sandbox environment |
| Point liability | Maintained separately for the applicable franchise owner group |
| Corporate visibility | Corporate umbrella access across participating franchise programs, with owner-level data boundaries |
The Loyalty Platform Migration Challenge
A loyalty program migration can look simple when described as moving a customer CSV from one system to another. This project required substantially more.
The participating franchisees were independently operated, did not all use the same incumbent loyalty platform, and did not all use the same POS environment. Some franchise owners operated one location, while others controlled multiple stores. Corporate needed a broader customer and marketing view, but the economic liability for loyalty points belonged to the individual franchise owner groups rather than to corporate.
The loyalty platform migration therefore had to preserve several forms of continuity at the same time:
Point balances
Communication preferences
Birthday data
Campaign strategy
Reward definitions
POS workflows
Owner-level point liability
Corporate-level visibility
The resulting architecture allowed the organization to operate a recognizable brand-wide loyalty experience without treating independently owned franchises as if they were one financial entity.
Loyalty Platform Migration Data from Fivestars and TapMango
Participating stores obtained available data files and reports from their existing Fivestars and TapMango programs. Preferred Patron support advisors worked with those exports to review field availability, normalize source values, identify duplicate or incomplete records, and map the supported fields into the Preferred Patron customer structure.
Data Elements Mapped
Depending on what was present in each source export, the supported migration included:
- member first name;
- member last name;
- mobile number;
- full birthdate, where available;
- partial birthday month/day, where available;
- SMS opt-in preference;
- email opt-in preference;
- last visit date;
- point balance at the time of export; and
- customer notes.
Available values for these supported fields were mapped into Preferred Patron. The migration process also included data normalization and duplicate review rather than treating every row in a source file as an unquestioned new customer record.
Preserving Loyalty Membership Without Requiring Re-Enrollment
Existing member enrollment records were transferred electronically. Customers did not need to complete a new loyalty enrollment simply because the participating store changed loyalty platforms.
Mobile number served as an important customer-recognition key. Once a participating customer was recognized within the loyalty environment, that identity could be reused at other participating stores according to the chain and owner-group rules described below.
Separating Loyalty Membership, Communication Consent and Age Eligibility
The client required loyalty participation and marketing eligibility to be treated as separate concepts. Imported members could continue participating in loyalty, earning points and redeeming rewards, while SMS eligibility depended on the communication preference and client-defined age rules associated with the customer record.
Only source records identified as SMS opted-in were carried forward with that SMS preference. Email preferences were mapped separately where supplied.
Birthdate data also required careful handling. Some source systems provided a complete birthdate, some records contained only a birthday month and day, and some had no usable birthday information.
Partial Birthday Available
Where month and day were available but the year was not, that information could still support birthday-campaign timing. The record remained distinguishable from a fully completed date of birth.
Birthday Missing or Incomplete
Incomplete data could be flagged for later completion. Where communication eligibility and store workflow permitted, the program could request or capture a complete birthdate during a later customer interaction.
This allowed the migration to preserve useful birthday information without treating partial data as a fully verified date of birth. It also allowed customer loyalty participation to continue while messaging eligibility followed the client’s separate rules.
Mapping Existing Campaign Strategy Instead of Starting Over
The migration included the existing marketing strategy, not just member records. SunFlora provided campaign guidance for the rollout and approved using the established campaign structure as the initial template, with flexibility to refine campaigns after deployment.
Historical source configurations included acquisition, first-visit, growth, at-risk, lapsed, lost-customer, birthday and points-reward strategies. Preferred Patron created corresponding campaign definitions so the business concepts behind the incumbent programs could continue on the new platform.
| Historical Campaign Concept | Preferred Patron™ Mapping | Purpose Preserved |
|---|---|---|
| Acquisition / new-member incentive | New Member / Welcome strategy | Convert a newly identified customer into a return visitor |
| First-visit follow-up | Thank You / Next Visit strategy | Encourage the second purchase after initial activity |
| Customer growth / appreciation | Best Member / Growth strategy | Recognize repeat activity and reinforce continued engagement |
| At-risk customer | Miss You / Come Back strategy | Reach customers after an early inactivity threshold |
| Lapsed customer | Miss You / Come Back strategy with longer inactivity window | Recover customers who had been absent longer |
| Long-term lost customer | Miss You / extended inactivity strategy | Attempt reactivation after prolonged inactivity |
| Birthday | Birthday strategy | Deliver an appropriately timed birthday incentive |
| Points and reward thresholds | Preferred Patron Rewards Program and reward table | Continue earning and redemption logic using configurable point thresholds |
The goal was not to claim that two software platforms were identical. It was to preserve the customer’s established retention logic and recreate the applicable program behavior in Preferred Patron, while allowing corporate or individual owner groups to adjust offer values, thresholds and rules where desired.
Standardized Franchise Templates with Local Flexibility
Once the baseline campaign and reward configuration was approved, Preferred Patron templated the store setup so the same core program could be cloned across participating locations.
This reduced repetitive configuration work and helped stores launch with a consistent starting point. At the same time, an individual owner group or location could deviate from the default campaign setup when its business needs required a different rule, offer or schedule.
Corporate could establish a repeatable program baseline while independently owned stores retained controlled flexibility within their own loyalty environment.
POS Integration Across Square, Vend and Standalone Stores
The participating locations did not operate one standardized checkout platform. Store environments included Square POS, Vend (now Lightspeed Retail X-Series), and standalone or kiosk-based loyalty workflows.
Where applicable, Preferred Patron was deployed with bidirectional POS integration so customer and loyalty activity could move between the loyalty platform and the store’s transactional environment.
Multi-Store Vend Environments
Some multi-location franchise owners operated separate Vend databases that were not otherwise functioning as one shared customer database. Preferred Patron provided a common loyalty layer across those systems for the franchise owner.
Customer-profile information could synchronize bidirectionally between Preferred Patron and the connected Vend environments. When the same customer record changed in different systems, record currency could be resolved using the most recently updated information. Redemption workflows were also integrated into the Vend environment.
Square and Standalone Deployments
Square-connected implementations were deployed where applicable, while locations that did not require an integrated POS workflow could operate Preferred Patron through standalone or kiosk configurations. The migration therefore did not depend on every franchise replacing its existing transaction environment.
For more information about integration approaches, see Preferred Patron loyalty program integrations and API capabilities.
One Customer Identity Across the Chain, Separate Point Liability by Franchise Owner
One of the most important design requirements involved the difference between customer identity and financial liability.
SunFlora corporate needed an umbrella view across participating franchise programs and the ability to communicate with eligible participating members at the corporate level. Customer enrollment and communication preferences also needed to remain consistent when a customer visited different participating stores.
At the same time, corporate was not sponsoring every point earned throughout the franchise network. Outstanding point liability belonged to the applicable franchise owner group.
Shared Customer Identity
- A participating customer could enroll once rather than re-enrolling at each store.
- Mobile number could be used to recognize the customer when visiting another participating location.
- Applicable communication preference changes could propagate through the participating loyalty environment and connected POS systems.
- Corporate could work with the participating member population at an umbrella level.
Owner-Level Loyalty Liability
- Franchise owners accessed loyalty data appropriate to their own customer relationships.
- A customer visiting stores owned by different franchise groups could maintain separate point balances by owner group.
- Stores within the same owner group could share the applicable balance where configured.
- One owner’s reward liability was not automatically transferred to an unrelated franchise owner.
This architecture allowed a customer to be recognized as the same person across the participating network without incorrectly turning independently funded franchise point programs into one unrestricted chain-wide liability pool.
Loyalty Platform Migration Testing: Sandbox, Overnight Cutover and No Re-Enrollment
The migration process was validated in advance rather than being tested for the first time against live customer data.
Dry-run migrations were completed in a sandbox environment so field mappings, data normalization, campaign configuration and applicable integration behavior could be reviewed before production go-live.
Prepare & Dry Run
Review source files, mappings, duplicate conditions, campaign rules and integration setup in a sandbox.
Final Export
Take the production source export after the participating store closes for the day.
Import & Validate
Apply tested mapping rules, import member records and balances, configure the store and validate production behavior.
Open on Preferred Patron
The store begins the next business day on the new loyalty environment without requiring existing members to enroll again.
Lifecycle and transactional communications were controlled during data loading so imported historical records did not unintentionally behave like newly enrolled customers.
An individual prepared store typically moved through the broader migration and go-live process in approximately three business days. The final production cutover itself was structured as an overnight transition: export after close, import and validation before the next business day.
A Controlled Three-Month Franchise Rollout
The approximately three-month timeline reflected the coordinated rollout across dozens of independently operated stores, not a three-month outage or three-month migration window for each individual franchise.
The agreed 2019 deployment plan began with a beta location, maintained a controlled deployment during the initial month with only a small number of stores, and then expanded to broader store groups as the tested process was repeated.
This phased approach allowed the implementation team to validate the migration mechanics, store workflow and campaign setup before scaling the same process across the participating franchise network.
The enterprise rollout took approximately three months; a prepared individual store typically migrated in about three business days, with its final production cutover completed overnight.
Loyalty Platform Migration Results
- Approximately 60 participating franchise locations were transitioned into the Preferred Patron loyalty environment.
- Approximately 100,000 existing loyalty member enrollment records were included across participating store migrations.
- No existing members were required to re-enroll.
- Existing enrollment records and supported loyalty data were transferred electronically.
- No customer-facing loyalty downtime occurred during the planned store cutovers.
- Final source exports could be taken after store close and imported before the next business day.
- Migration procedures were dry-run and validated in a sandbox before production rollout.
- Available first name, last name, mobile number, birthdate information, communication preferences, last visit date, point balance and customer notes were mapped from source exports.
- Existing retention concepts were recreated through corresponding Preferred Patron campaign and reward definitions.
- A standardized configuration template accelerated rollout while allowing owner-group or store-level variation.
- Customer identity and applicable communication preferences could operate across participating franchise locations.
- Point liability remained associated with the applicable franchise owner group.
- Square, Vend/Lightspeed and standalone loyalty operating models could coexist within the broader program architecture.
- Multi-store franchise groups using separate Vend databases could use Preferred Patron as a common customer-loyalty layer.
What This Loyalty Platform Migration Demonstrates
This implementation shows why evaluating a replacement loyalty platform requires more than asking whether it can import a customer list.
| Migration Requirement | What the Your CBD Store Rollout Demonstrated |
|---|---|
| Customer continuity | Existing enrollment records were transferred electronically and customers were not required to re-enroll. |
| Value continuity | Available point balances at the time of export could be mapped into the replacement loyalty environment. |
| Program continuity | Acquisition, first-visit, growth, inactivity, birthday and reward concepts were recreated as Preferred Patron strategies. |
| Consent continuity | SMS and email preferences were treated as customer attributes rather than inferred from loyalty membership. |
| Integration continuity | Square, Vend/Lightspeed and standalone environments could be supported without requiring one universal POS replacement. |
| Franchise financial controls | Customer identity could span participating locations while point liability remained segregated by franchise owner group. |
| Enterprise governance | Corporate could establish a common program and broader customer view while franchisees retained appropriate data boundaries and configurable local rules. |
| Operational continuity | Sandbox testing and overnight production cutovers avoided customer-facing loyalty downtime during the planned transitions. |
Loyalty Program Migration FAQ
Did existing Your CBD Store loyalty members have to re-enroll after the migration?
No. Existing member enrollment records were transferred electronically into Preferred Patron, so participating stores did not require existing members to complete a new enrollment simply because the loyalty platform changed.
Was there customer-facing downtime during the store migrations?
No customer-facing loyalty downtime occurred during the planned store cutovers. The final source export was taken after the store closed, and the Preferred Patron import and production validation were completed before the next business day.
How long did the loyalty platform migration take?
The coordinated rollout across approximately 60 participating franchise locations took about three months. An individual prepared store typically moved through its migration and go-live cycle in approximately three business days, with the final production cutover completed overnight.
What customer data was migrated from Fivestars and TapMango?
Depending on what was available in the source export, supported fields included first name, last name, mobile number, full or partial birthday information, SMS preference, email preference, last visit date, point balance at export and customer notes.
Could incomplete birthday data still be used?
Yes. Where month and day were available but the birth year was not, the birthday timing could still be retained for birthday-campaign purposes while the record remained identifiable as incomplete. Missing or incomplete birthdate information could later be completed according to the client’s messaging and store-workflow rules.
Could the existing POS remain in place?
Yes, depending on the location. Participating environments included Square POS, Vend (now Lightspeed Retail X-Series), and standalone or kiosk workflows. Preferred Patron was configured around the applicable store environment rather than requiring every franchise to adopt one POS.
How did Preferred Patron handle customers who visited stores owned by different franchisees?
The customer could be recognized within the broader participating network while point balances remained associated with the appropriate franchise owner group. This supported chain-level customer identity without shifting one owner’s point liability to an unrelated franchise owner.
Planning a Loyalty Platform Migration?
Businesses switching loyalty platforms may already have years of customer identities, point balances, lifecycle campaigns, communication preferences and integration logic invested in their current program. Those assets should be reviewed before a replacement program is designed.
Preferred Patron™ works with businesses to evaluate available exports, map supported customer and loyalty data, recreate applicable program rules, test the conversion, configure integrations and plan production cutover.
Explore the Preferred Patron Switch Loyalty Platforms resource center
If you are specifically evaluating a move from an incumbent platform, see the Fivestars alternative and migration guide and TapMango alternative and migration guide.
About Preferred Patron™
Preferred Patron™ is a customer loyalty, retention and marketing platform supporting points and rewards, digital stamp programs, customer segmentation, automated campaigns, SMS and email marketing, gift cards, multi-location loyalty, POS integrations, APIs and enterprise loyalty deployments.
The platform supports both standardized multi-location programs and structures in which corporate, regional, franchise-owner and store-level users require different visibility, balances, rules or marketing capabilities.
Case Study Methodology and Historical Context
This case study describes a historical 2019 implementation and is based on Preferred Patron implementation records, migration specifications, campaign configuration records and contemporaneous project correspondence supplied during the rollout.
The location and member figures are approximate. The approximately 100,000 figure refers to existing loyalty member enrollment records across participating store migrations and is not presented as an independently audited count of 100,000 unique individuals. Customers could have relationships with more than one franchise owner group.
The campaign examples describe historical program concepts and do not represent current Your CBD Store offers. Product names, company names and trademarks belonging to third parties are used only to identify the systems and organizations involved in the historical migration. This case study does not imply a current vendor relationship, sponsorship or endorsement by any third party.
Trademark and comparison note: Fivestars, TapMango, Square, Vend, Lightspeed, Your CBD Store, SunFlora and GPP Mobile names and marks are the property of their respective owners. Preferred Patron is not affiliated with Fivestars or TapMango. References to those platforms are descriptive of the historical source systems used in this migration.