POS migration: a 4-week playbook for cannabis dispensaries

The commit conversation is the demo where you stop comparing and start scoping. We end every demo by writing a fixed-scope quote and a cutover date that fits your store, not ours. If we can’t do that on the call, we’re not ready and you’re not ready.

• Sandbox built from a snapshot of your real data (anonymized as needed) — not a generic demo store
• Cutover date that respects your busiest day (typically a Monday or Tuesday for most retail dispensaries)
• Fixed scope: every integration, every report, every staff role mapped before week 1
• Owner-side homework list: who from your team owns which surface, with names

The first week is paperwork and exports. The goal is that by Friday, every byte of customer + transaction + inventory data from your current POS is in our hands and verified.

1. 1Run a full export of customers, products, vendors, transactions, and inventory snapshots from current POS — we provide a checklist
2. 2Snapshot your traceability state from your tracker (METRC / BioTrack) — match-up against POS exports immediately surfaces drift
3. 3Provision platform access: admin accounts for owner + GM, draft accounts for staff (no logins yet)
4. 4Vendor integration audit: list every third-party tool that touches your POS today (analytics, loyalty, online menu, e-comm) — flag which ones we re-wire and which ones you sunset

Week 2 is when the new platform actually starts looking like your store. Tax rates, product taxonomy, vendor list, staff roles, register layouts — every operator-specific configuration gets locked in. The week ends with a full dry-run: a fake transaction goes from cart-to-receipt-to-traceability-handoff, and every system reports the same number.

• Tax stack configured per store (state excise + sales + local-option per municipality)
• Product catalog imported and re-categorized to match how your team actually merchandises
• Staff roles mapped to platform RBAC — admin, GM, manager, lead, budtender, inventory, purchasing
• Register hardware configured (printers, scanners, customer display, scales if applicable)
• Dry-run: full sale through a test register, traceability event fires, audit log row written

Training comes after configuration so staff aren’t learning a system that’s still moving. We run training in three layers: budtender, manager, and admin. Each layer is 30-45 minutes of live walkthrough plus 30 minutes of hands-on practice on the sandbox.

• Budtender training: register operations, age-verify lane, customer lookup, loyalty redemption
• Manager training: till open/close, cash variance handling, refund + void flow, end-of-day report
• Admin training: user management, vendor onboarding, audit log access, payroll periods
• Parallel-run day: one register on the new platform, one on the old, run both for 4-6 hours, reconcile cash + transactions at close

Cutover day is the calmest day in the whole project, by design. Every system is ready, every staff member has been on the sandbox, every integration has been tested. We run cutover at end-of-day on a slow weekday — typically a Monday close — so the new system opens on a Tuesday morning with zero in-flight transactions to migrate.

1. 1Final exports from old POS at close (transactions, inventory, customers — last delta)
2. 2Reconciliation: every export matches the previous export plus today’s sales — no drift
3. 3Platform goes live: registers boot to new system, old POS read-only
4. 4Tuesday morning: open with a manager + admin both on-floor, monitor the first hour live
5. 5Day-one debrief: what worked, what didn’t, what we’re fixing this week

The first two weeks after cutover are mostly polish — small things that show up only when real customers + real staff use the system in real conditions. We treat post-cutover support as part of the migration, not a separate engagement. The standing meeting cadence drops from daily (week 1) to weekly (week 2) to monthly (steady state).

• Daily standup for 7 days post-cutover (15 min, what’s working, what’s blocking)
• Weekly check-in for the next 3 weeks
• Monthly review thereafter — focused on which features your team is actually using vs which are sitting dormant
• Quarterly: jurisdiction-rule review (if your state regulator updates rules, we update the platform)