Latest · today
Switching · Practical guide

Get Your Data Out Before You Switch POS

A salon owner on a UK trade forum wrote the single most useful sentence anyone has written about choosing a till. Asked what to check before committing to a booking and sales system, the answer was: "one important question to ask is can you easily get your data out of the system… when you ask the question two wrong answers are 1) We will get it out for you. 2) Run reports and export them to excel". Both answers sound helpful. Both mean you do not control your own history. This guide is about what to export, when, and how to test it while you still have a choice.

Barbershop counter with a tablet till and an open appointment book, where the shop's client list lives in two places at once
Scope note. Export capabilities differ by product and change with each version, so nothing here is a claim about what any named vendor does today. Treat it as a checklist to run against your own system, and test rather than trust. Data protection duties around a customer list are yours, whichever system holds it.

Why the subscription is the cheap part

Owners compare monthly prices because monthly prices are easy to compare. The expensive part shows up later. A family hardware store weighing up a replacement for an ageing system put the real number on it: "The real cost of upgrading is going to be trying to import 30 years of sales records, thousands of customers information, and tens of thousands of individual sales items (prices, inventory, upc numbers, etc) into the new system. And that's not exactly the kind of thing we can do piecemeal over time."

That is the honest shape of switching costs: not the £29 a month, but the fortnight of evenings, the missing barcodes, and the customer balances nobody can reconstruct. And it is worth noticing what someone in the payments trade replied to him in the same thread — that if your system cannot let you export your sales, customers, stock and prices, that is not an inconvenience, it is a reason to leave.

The two answers that should worry you

Ask a vendor, before signing: can I export my own data, myself, whenever I want, without asking you? Then listen carefully, because the two most common reassuring answers are both refusals in disguise.

"We'll get it out for you." This means the export is a favour, not a feature. Favours depend on goodwill, and goodwill is exactly what disappears the week you tell them you are leaving. It also usually means there is no self-service export at all, so you cannot practise, cannot check the format, and cannot take a backup on an ordinary Tuesday.

"Just run the reports and export them to Excel." This sounds like a yes. It is not. A report is a summary shaped for reading, not a data file shaped for loading into something else: totals by day rather than individual transactions, product names without barcodes, customer names without their balances or contact details. You can prove this to yourself in five minutes — export a report, then try to work out from it what a named customer owes you, or which barcode belongs to which price.

The answer you want is dull and specific: a self-service export, per data type, in CSV, containing rows rather than totals, that you can run yourself as often as you like.

The five things to export, in order of pain

If you export nothing else, export these, and export them before you give notice, not after.

  1. Your customer list, with balances. The hardest thing to rebuild and the most commercially valuable. Names, contact details, and — if you run tabs or credit — what each person currently owes. A list of names without balances is half a list.
  2. Your product file: names, prices, barcodes, tax rates, suppliers. The barcodes matter most, because retyping them is the slowest job in the world and mistyping one creates a pricing error that survives for years.
  3. Current stock levels, with cost prices. Sale prices are on your shelf edges; cost prices usually exist only in the system, and without them your margins go dark on day one of the new system.
  4. Transaction-level sales history, not daily summaries. This is what lets you compare next December against last December, defend a tax position, or answer a chargeback.
  5. Employee records and any timekeeping data, if the system holds them. It is the most commonly forgotten export and the one people need most urgently at year end.

The encoding trap that makes a good export useless

There is a small, deeply annoying failure that turns a perfectly good export into a file you cannot use, and it is almost never mentioned: character encoding. A retail manager described exactly it on a review site — "When I export some reports to Excel, the French words with special characters are not showing up correctly".

If your products, customers or addresses contain accents, ñ, ç, Portuguese tildes, or any non-English alphabet, a CSV can arrive with mangled characters that no import will fix cleanly. Two habits prevent it:

The other end of the same problem: the import that fails

Getting the file out is only half of it. A grocery and wine retailer described the mirror image after choosing a well-known system: "They were unable to import our 2k SKUs, so we entered everything manually." Two thousand products, retyped, by people who had a shop to run.

So the question to the incoming vendor is the counterpart of the one you asked the outgoing one: what exact file format do you accept, will you import my file as it is, and can we test it with my real data before I commit? A vendor who will run a trial import on your actual export, and show you the result, is telling you something real about the switch. One who says "our team will handle it" during the sales conversation has just given you the first wrong answer from the previous section.

A twenty-minute test to run before you sign

Do this during the trial, on a laptop, with nobody watching.

Then, whatever you choose, put a recurring monthly reminder in your phone to run those exports and save them somewhere you control. It takes ten minutes and it is the only thing that makes both a switch and a lockout survivable.

What to look for in a till, with this in mind

⭐ Worth a look

digabloPos

✓ Free forever ✓ No forced commission ✓ No lock-in contract

The reason a free, no-contract system matters in an article about leaving is not the price. It is that a system you can leave has to be worth staying with. digabloPos has no forced payment commission and no engagement period to buy your way out of, so the decision to stay is re-made every month rather than enforced for forty-eight of them. Sales are recorded transaction by transaction with the payment method and the employee attached, which is the level of detail that is worth exporting in the first place.

Be clear-eyed about the limit. Export formats and report depth vary by plan and change over time, so do not take our word for it: run the twenty-minute test above on digabloPos exactly as you would on any other candidate, and check what the current plan includes. The base plan is free forever for 2 employees with 30 days of history, and unlimited report history is a paid module — which is directly relevant here, because history you cannot see is history you cannot export.

👍 Strengths

  • No engagement period, so leaving is a decision rather than a negotiation
  • No forced payment commission, and no hardware lease attached to the software
  • Transaction-level records with payment method and employee on each sale
  • Free forever base plan, so you can test the export before committing anything

👎 Notes

  • Free plan keeps 30 days of history; unlimited history is a paid module
  • Check the current export formats yourself rather than assuming
  • Migrating a large legacy catalogue is still work, whichever system you move to

Visit digabloPos →

Run the export test on a free register

Set one up, add a handful of products with barcodes and one customer with an accent in their name, then try to get all of it back out as a file. That is the whole test.

Create my free register

If you have already decided to leave

Order matters, and most people get it backwards by telling the vendor first.

  1. Export everything, twice, on two different days, and open the files to confirm they are readable. Do this before any cancellation conversation.
  2. Reconcile your customer balances on paper with the exported list, so any tab or credit account is agreed before the system goes away.
  3. Check what is contractually separate. Software, card processing and hardware are often three agreements with three end dates. Cancelling one does not end the others.
  4. Only then give notice, in writing, and keep the thread.
  5. Run both systems side by side for a few days if you possibly can. The gap between "the data imported" and "the shop works" is where the surprises live.

Frequently asked questions

What should I export before leaving a POS system?

Five things, before you give notice: your customer list with balances, your product file with names, prices, barcodes, tax rates and suppliers, current stock levels with cost prices, transaction-level sales history rather than daily summaries, and any employee or timekeeping records the system holds. Cost prices and barcodes are the two most commonly forgotten and the two most painful to rebuild.

My vendor says they will export the data for me. Is that good enough?

No. It means the export is a favour rather than a feature, and favours depend on goodwill that tends to evaporate the week you announce you are leaving. It also means you cannot take routine backups or check the format in advance. What you want is a self-service export, per data type, in CSV, that you can run yourself whenever you like.

Isn't exporting reports to Excel the same thing as exporting my data?

Usually not. A report is a summary shaped for reading: totals by day, product names without barcodes, customer names without balances. A data export is rows. The quick way to tell them apart is to take your exported report and try to work out what a named customer owes you, or which barcode goes with which price. If you cannot, it is a report.

Why do accents and special characters break in my CSV export?

It is a character encoding mismatch, and it is common enough that retailers complain about it publicly. The file is usually fine and the spreadsheet is guessing wrong. Open the CSV in a plain text editor to check, and in Excel use Data then From Text/CSV and select UTF-8 rather than double-clicking the file. Always check one record you know contains an accent, while you can still re-run the export.

How long can I access my data after I cancel?

That varies by provider and it is rarely volunteered, so ask before you sign and get the answer in writing in the same email thread as the price. Assume the worst in the meantime: export everything you need, twice, on two different days, and confirm the files open correctly before you start any cancellation conversation.

What if the new system cannot import my file?

It happens, and it is expensive: one retailer described a new system being unable to import two thousand product references, leaving the team to enter everything by hand. Ask the incoming vendor exactly which file format they accept and whether they will run a test import on your real exported file before you commit. A vendor who will show you the result of that test is telling you something real; one who only offers to have their team handle it is not.

Sources

The merchant accounts quoted here come from public forum threads and review pages. Read them in context rather than taking our word for it.