Most retailers who hate their POS still keep it, and the reason is rarely loyalty — it's the catalogue. Years of products, barcodes, prices, and departments live inside the old system, and the thought of moving all of it without breaking Saturday's checkout is enough to make "maybe next year" the permanent plan. The fear is reasonable; the paralysis isn't. Catalogue migration is a solved problem if you treat it as a data project with a checklist instead of a leap of faith. Here's the playbook — drawn from a real migration we'll come back to at the end.
Step 1: Get your data out — all of it
Every POS, even the crustiest, has some export: CSV files, a report you can save, or at worst a database backup. Export products, barcodes, prices, departments/categories, and tax settings, and do it on a quiet day so the snapshot is coherent. If your vendor makes exporting hard, that difficulty is itself a lesson about who really owned your data all along — and one more reason to leave for a system that treats exports as your right.
Step 2: Audit before you import — this is where migrations die
Never pour a legacy export straight into a new till. Old catalogues carry years of sediment, and importing sediment gives you a new POS with old problems. Hunt specifically for:
- Duplicate barcodes. The classic killer: two different products sharing one barcode, or the same product entered three times over the years. At the till this becomes "wrong item scanned" — visible to every customer, corrosive to every stock count.
- Missing barcodes. Items that were always rung in by lookup. Decide now which ones deserve labels and codes in the new world.
- Ghost products. Discontinued items, seasonal leftovers, test entries ("ZZZ DO NOT USE"). Migrate the living, bury the dead — a clean 1,500 beats a haunted 4,000.
- Price drift. Items whose till price stopped matching the shelf long ago. You will never have a better moment to reconcile than now.
- Inconsistent units and names. "Flour 2kg", "2KG FLOUR", "Flour lge" — pick a convention and normalise, because search and reporting in the new system will only be as good as the names you feed it.
A migration isn't a copy — it's an amnesty. It's the one day you get to fix every data sin of the last decade at once.
Step 3: Import in dress rehearsal, then verify like an auditor
Load the cleaned catalogue into the new system before cutover day and test it like a hostile customer. Scan real items off the real shelves — especially the weird ones: multipacks, weighed goods, items with two package sizes. Check that departments report correctly and taxes calculate right. Every problem you find in rehearsal is a problem your cashiers and customers never meet.
Step 4: Cut over with a bridge, not a cliff
Plan the switch for your quietest day, keep the old system readable (not selling — readable) for a few weeks as a reference, and brief your cashiers on what to do when something won't scan: a quick add-and-flag flow beats a queue every time. Expect a short tail of stragglers — the last few percent of odd items surface over the first weeks, and that's normal, not failure.
What this looks like when it's real
This playbook isn't theoretical. When a Saint Lucian supermarket moved to SamcoPOS from its legacy EposNow system, the migration meant rebuilding a live catalogue of 1,471 products — deduplicating barcodes (657 of them verified and attached), normalising names, and retiring the ghosts — and the store's checkout has run on it every trading day since, across multiple registers, with the offline-capable till keeping lanes moving regardless of the connection. That's the standard a migration should be held to: not "the data moved," but the shop never missed a Saturday.
If the only thing keeping you on a POS you've outgrown is the catalogue inside it, that's a hostage situation — and a negotiable one. See what's on the other side at SamcoPOS.