Migrating to a new POS: a four-week plan that does not lose data

Changing point-of-sale systems is not a software installation; it is a data project with a software installation at the end. Here is a plan that reflects that.

Week 1: export and assess

Export everything from the old system before you cancel anything:

• Products with barcodes, cost prices, sell prices and VAT treatment
• Categories and modifiers
• Customers with contact details and any VAT numbers
• Suppliers and open purchase orders
• Sales history for at least the last two years
• The invoice archive, in XML where available

Verify the exports open. A CSV that will not parse is not an export.

Record the last invoice number and hash per device. Seechanging POS without breaking ZATCA.

Get the old vendor's retention terms in writing.

Week 2: clean the catalogue

This is the real work, and it is worth doing properly because you are about to live with the result for years.

• Duplicates. Two rows for the same product, usually from a barcode typed twice.
• Units. Decide, per product, whether you buy and sell in the same unit, and record the conversion where you do not.
• VAT treatment. Per product, confirmed with your accountant — seeVAT basics.
• Cost prices. Missing cost prices mean no gross margin reporting, forever, until someone backfills them. Do it now.
• Dead stock. Products not sold in twelve months: archive rather than import.
• Variants. Fifty separate SKUs that are really one product in five sizes and two colours should become one product with children.

A shop with 3,000 products should expect two to three days on this. It is the highest-return work in the entire migration.

Week 3: configure and pilot

• Import the cleaned catalogue into the new system. Review the import report — what did not match, and why?
• Onboard terminals with ZATCA. Every device. See theonboarding guide.
• Set up users and permissions. Who can discount, refund, void, change prices, see reports.
• Configure printers and the receipt template. Print one and scan the QR.
• Connect integrations — delivery platforms one at a time, accounting export, payment provider.
• Pilot on one terminal at one branch, for real sales, for at least three days.

Compare the pilot terminal's daily report against the old system's for the same period. Differences are findings, not noise.

Week 4: cut over

Choose the boundary. End of a trading day, ideally end of a VAT period, ideally a quiet weekday.

On the day:

1. Old system stops issuing — completely, on that device
2. Count stock, physically, and enter the counted quantities as opening balances
3. Start the new system
4. Issue a test invoice and verify: QR scans, totals correct, accepted by ZATCA
5. Verify one B2B invoice clears
6. Have a manager on the floor for the whole first shift

Order of branches: quietest first, busiest last. If something is wrong, you want to find it where it costs least.

The two weeks after

• Watch the ZATCA acceptance dashboard daily. Early rejections are configuration.
• Reconcile cash daily, and take variances seriously in week one — they are usually process, not theft.
• Check gross margin on your top 20 products against what you expected. A wrong cost price shows up here.
• Keep the old system's archive somewhere you control.
• Collect staff complaints in one place and fix the top three. Small friction compounds.

The five things that go wrong

1. Stock not counted at cutover. Then nobody knows whether a discrepancy is data or loss.
2. Cost prices not imported. Margin reporting is dead until someone backfills.
3. Both systems live on one terminal. Breaks the ZATCA hash chain.
4. Busiest branch first. Maximum pain, minimum learning.
5. Old subscription cancelled before export verified. Sometimes unrecoverable.

How long it really takes

• Single shop, clean catalogue: one week
• Single shop, messy catalogue: three weeks, most of it week 2
• Three to five branches: four to six weeks
• Ten or more branches: plan a branch a week after the first two

Rushing week 2 is the most common and most expensive mistake. Everything else is recoverable.