Migration playbook
POS migration: a 4-week playbook for cannabis dispensaries
Switching POS in a dispensary is the kind of project that goes either really clean or really sideways. The difference is almost always in the planning — what you back up, what you test, who owns which surface, and what you do when day-one inevitably surfaces a small surprise. Here is how it goes when an operator commits.
First, the scope
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.
- A walkthrough on the surfaces you actually run — your workflows named, not a generic feature tour
- A cutover date that respects your busiest day
- Fixed scope: every integration, every report, every staff role written down before anything starts
- Owner-side homework list: who from your team owns which surface, with names
Your data, exported and checked
The first stretch is paperwork and exports: customers, products, vendors, transactions and inventory snapshots out of your current POS, checked against a snapshot of your traceability state so any drift shows up before cutover rather than after. We provide the checklist; you provide the exports and a list of every third-party tool that touches your POS today, so we can agree which ones get re-wired and which ones you sunset.
Configured to your store, then a dry run
Next the new platform starts looking like your store: tax rates per location, product catalog re-categorized the way your team actually merchandises, staff roles, register hardware. It ends with a full dry run — a test sale goes from cart to receipt to the traceability hand-off, and every system reports the same number.
Training, then a day running both
Training comes after configuration so staff aren’t learning a system that’s still moving. Budtenders, managers and admins each get a short live walkthrough and hands-on practice. Then one register runs the new platform beside one on the old for part of a day, and cash and transactions are reconciled at close.
Cutover on your slowest day
Cutover day is the calmest day in the whole project, by design. Every system is ready, every staff member has practiced, 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 the next morning with zero in-flight transactions to migrate, a full overnight to reconcile, and a manager on the floor for the first hour.
After cutover
The first couple of weeks after cutover are mostly polish — small things that show up only when real customers and real staff use the system in real conditions. We treat post-cutover support as part of the migration, not a separate engagement: close contact at first, tapering to a regular check-in on which features your team is actually using, and a review whenever your state regulator changes a rule.
Takeaways
- The scope comes first — fixed scope, named owner per surface, cutover date agreed
- Data and exports, then configuration and a dry run, then training and a day running both, then cutover.
- Cutover at end-of-day Monday so Tuesday opens clean — no in-flight transactions to migrate, full overnight to reconcile
- Loyalty data is the messiest export — reconcile field-by-field so no customer loses a point on day one
- Post-cutover support is part of the migration, close at first and tapering to a regular check-in.
Frequently asked
- When should we schedule the actual cutover so we don't lose transactions?
- Run cutover at end-of-day on a slow weekday, typically a Monday close, so the new system opens Tuesday morning with zero in-flight transactions to migrate. Cannabis retail traffic dips lowest on Monday afternoons in most markets, which means no in-flight transactions, a full overnight to reconcile, and a light-traffic Tuesday that can absorb minor friction. It is meant to be the calmest day in the whole project.
- What about our loyalty program data during the switch - will customers lose their points?
- Loyalty data tends to be the messiest export, including points balances, tier history, and sign-up dates. It gets mapped field-by-field with a reconciliation report run so no customer loses a single point on cutover day. Loyalty is the surface customers will notice first if it is handled wrong.
- Who is responsible for what during the migration - us or you?
- CannAgent owns the data migration, the regulatory mapping, and the platform configuration. The operator owns staff training scheduling, customer communication, and the call to the traceability vendor about the integration switch. Both lists get written down on day one so there are no surprises in week 4.
Related guides
Ready to talk through your migration?
30-minute demo. We end by quoting the cutover from your current setup — fixed scope, no hourly games.