Cannabis loyalty data — without losing a single point

Most cannabis-POS loyalty implementations store points as a single counter on the customer row. When you migrate, you SELECT the counter, INSERT into the new system, and trust the math. That works exactly until: (a) one POS computes points slightly differently than the other, (b) tier-history isn’t exported, (c) the sign-up-date field is named differently, or (d) a sync hiccup mid-migration leaves rows inconsistent. Then the customer notices. Then the budtender apologizes. Then operator-side trust erodes one customer at a time.

• Counter-only storage — single integer on the customer row. No history. Reconstruction impossible once a discrepancy is reported.
• Tier-history flat-discarded — Gold tier earned in 2022 turns into Silver after migration because nobody exported the tier-history table.
• Sign-up date overwritten — new POS uses createdAt for the customer record itself, not the original loyalty-enrollment date. 4-year customers look like new signups.
• Mid-flight sync breaks — POS-A is dual-running with POS-B for a week, points earn in both, neither knows about the other. Reconciliation is manual.

Instead of a counter, store every loyalty event as a row: earn / redeem / adjust / migrate-in. The customer’s current balance is computed from the ledger, not stored on the customer row. Reconstruction is always possible because the history is the source of truth.

The trick to a clean migration is treating the legacy points balance as a single migrate-in row, not a counter copied verbatim. That makes the cutover reversible (we can re-run the migrate-in if it fails) and auditable (every customer’s ledger has a clear pre-migration boundary).

1. 1Export legacy balances as CSV with customer_email + current_points + tier + signup_date + last_earn_at. One row per customer.
2. 2Validate the export — total points across all customers should match the legacy POS’s aggregate report. If not, find the discrepancy before cutover.
3. 3Insert one migrate-in ledger row per customer — points = legacy balance, source_system = 'dutchie' (or whatever), migration_batch_id = ISO date. The customer’s computed balance now matches.
4. 4Migrate tier-history as separate tier_history table with achieved_at timestamps preserved. Customer tier is derived from history; sign-up date stays original.
5. 5Run a reconciliation report the day after cutover — total points should match within ±5 per customer (rounding tolerance). Anything beyond requires investigation.
6. 6Hold the legacy export read-only for 90 days post-cutover. If a customer disputes a balance, the legacy export is the source of truth for the pre-migration value. After 90 days the dispute window closes.

• Points balance discrepancy — they always notice. Most-frequent dispute on any migration. Solved by accurate migrate-in + reconciliation.
• Tier loss — they notice if tier was earned + carried perks. Solved by migrating tier_history table separately.
• Sign-up date — they notice on anniversary milestones (5-year, 10-year). Solved by preserving original signup_date as a separate field.
• Last-purchase date — they don’t notice this directly, but the operator-side reorder math depends on it. Migrate as a side-table.
• Earn rate / multiplier history — they don’t notice unless the new POS computes earn differently. If the new system is 1pt/$1 and the legacy was 2pt/$1, that’s a re-anchor moment requiring customer communication, not silent migration.

• WSLCB advertising rules (WAC 314-55-155) — the section carries no loyalty-programme provision and no naming rule. What binds the copy is (2)(a), the content rules that apply to ALL advertising by a licensee: nothing false or misleading, no appeal to under-21s, no curative or therapeutic claim. Auto-generated emails / SMS clear the same bar. Ledger structure doesn’t change this; the customer-facing surfacing does.
• Industry discount + loyalty interaction — industry-discounted purchases may or may not earn loyalty points depending on operator policy. No state rule decides this for you, which is exactly why it has to be written into code and not just the SOP. Audit-log every variance from your own rule.
• Heroes / first-visit / birthday discounts — these stack with loyalty in customer-readable ways. Make sure the ledger captures the discount line-item separately so the customer’s effective earn rate is reconstructable.
• Federal banking + cash-only operations — points-redemption-as-store-credit is a tax-accounting nuance (280E-adjacent). The ledger documenting the redemption is what your CPA needs at year-end; if the redemption was made in cash, capture both the points-out and the cash-equivalent value.