How to Switch POS Software Without Losing Stock or Sales History

Most shop owners in Bangladesh do not stay on their first POS system. They outgrow it, or the vendor stops answering the phone, or the VAT consultant asks for a Mushak 6.3 register the software cannot produce. And then the switch gets postponed for a year, sometimes two, for one reason: fear. Fear that 8,000 item codes will come out mangled, that the customer dues ledger will vanish, that the shop will open on Saturday morning with a stock report nobody believes.

That fear is reasonable, but it is a planning problem, not a technical one. A POS migration is really three separate jobs: getting clean data out of the old system, deciding what deserves to move at all, and choosing a cutover moment where a mistake costs you an hour instead of a month. This guide walks through all three the way an operator would run them, with a data checklist, a cutover comparison, a stock-count routine for cutover night, first-week checks and a rollback plan you write before you need it.

First decide what actually needs to move

The single biggest cause of failed migrations is trying to move everything. Five years of line-item sales history is enormous, it maps badly between two different systems, and once it is in the new database it is almost never queried. Meanwhile the things that genuinely have to be right on day one (opening stock, supplier dues, customer dues) get rushed at the end.

Split your data into three buckets.

Must move, and must be exact. These control money and stock from the first bill: item master, opening stock quantities with batch and expiry where relevant, supplier list with outstanding payables, customer list with outstanding receivables (bakita), open purchase orders, price lists and promotions, and the opening balances for your ledger and cash accounts.

Should move if it is clean. Loyalty point balances, customer phone numbers and purchase preferences, barcode aliases, supplier lead times, reorder levels. Useful, but the shop can trade for a week without them.

Does not need to move. Historic line-item sales, old journal detail, closed purchase orders, deleted items, ten years of daily Z-reports. Keep these as a read-only export (CSV plus PDF, on two drives and one cloud folder) and keep the old system's server or licence alive for a few months so you can open it if a dispute comes up. VAT-registered businesses have to keep their records for a statutory period (check the current period with your VAT consultant, because it is longer than most owners assume) so treat that archive as a compliance asset rather than a nice-to-have.

Summary sales history (one row per day per outlet, or per month per item) is the sensible middle ground. It is small, it imports cleanly, and it gives the new system enough history to compute reorder levels and show year-on-year comparisons without dragging in a million rows.

The data checklist

Print this and tick it twice: once when the file is exported and cleaned, once when it is verified inside the new system.

Getting your data out of the old vendor

This is where switches stall, so plan for it early. Two weeks before you talk about migration, ask for the export in writing (an email, not a phone call) and be specific.

Ask for: the full item master with barcode, unit, cost, selling price, VAT rate and category; current stock by outlet, with batch and expiry; supplier and customer masters with outstanding balances as at a stated date; open purchase orders; all price lists; loyalty balances; and sales summary by day and by item for the last 24 months. Say the format you want (CSV or Excel, UTF-8, one file per table) and say the date you want it delivered.

Who owns your data

Your transaction data is your business record. The software is the vendor's; the numbers inside it are yours. If your contract does not say this in plain words, that is a gap to fix at your next renewal, not a reason to accept a refusal. Note also that "we will give you a backup" is not the same as an export: a database backup file in the vendor's own format is useless without their software, and some vendors offer exactly that, knowing it holds you in place.

If the vendor stalls

It happens, usually quietly: an unanswered email, then an invoice for an "export fee". Work through the ladder, and start it before you are in a hurry.

1. 1Put the request in writing again, with a deadline and a copy to whoever signs the cheques on both sides. Reference your contract clause if there is one.
2. 2Offer to pay a reasonable fee. Some vendors genuinely have to schedule an engineer. A ৳5,000–15,000 export fee is worth paying to save two weeks.
3. 3Take what you can get from the screen. Almost every POS can print or export its own reports: stock report, item list, customer ledger, supplier ledger, sales summary. Export each one to Excel or PDF from inside the software using your own login. This is often 80 per cent of what you need.
4. 4Use the database directly if it is on your own server. On-premise systems store data on the PC under your counter. Your new vendor's team can usually read a MySQL, PostgreSQL or SQL Server database and extract tables, that machine and its data are yours.
5. 5Rebuild the master, count the stock. Worst case, you type or scan a fresh item master and do a full physical count. For a shop with a few thousand SKUs this is two or three long days, not a catastrophe, and the stock file you end up with is more accurate than the one you were fighting for.
6. 6Keep the old licence running until you have verified everything, even if you have stopped billing on it.

Do not wait until you have given notice to start the export. Get the data first, then give notice.

Clean the export before it goes anywhere near the new system

A dirty import is worse than no import, because the errors hide inside a big correct-looking file. Budget a day or two for cleaning, in a spreadsheet, before anything is loaded.

• De-duplicate items. Sort by barcode and by name; a decade-old system will have "Coca Cola 250ml", "Coke 250 ML" and "coca-cola 250" as three items with stock split across them. Merge before import, not after.
• Fix units. Pcs, pc, piece, PC and blank should become one unit. Same for kg vs KG vs Kilogram.
• Check date formats. Expiry dates are the usual disaster: 03/04/2027 is ambiguous. Force everything to YYYY-MM-DD in the sheet.
• Drop the dead weight. Items with zero stock, zero sales in 12 months and no purchase order are clutter. Archive them, do not import them.
• Reconcile balances before you export them. Customer dues and supplier dues should be agreed with the other party, not just copied. Send statements to your top 20 debtors and your main suppliers, and settle disputes on the old system.
• Decide the VAT rate on every item. Migration is a good moment to fix items with the wrong rate; do it with your consultant, and see our Mushak 6.3 guide.
• Test-import a sample first. Load 50 items, 5 suppliers and 5 customers into the new system, look at them on screen, then load the rest.

Choose your cutover style

There are three realistic ways to make the switch. The right one depends on how many outlets you have, how much staff time you can spare and how much risk you can carry.

A fourth option deserves a mention because it is common and it usually goes wrong: the drifting switch, where the new system is bought, half-configured, and nobody sets a date. Six months later the shop is on neither system properly. Pick a date, write it on the wall, and work backwards from it.

For a single outlet with a Friday lull, weekend cutover is usually right. For a five-branch supershop, new-branch-first or a branch-by-branch weekend cutover beats trying to convert everything at once. For a pharmacy with heavy batch and expiry data, a short parallel run on one counter is worth the pain.

Cutover night: the stock count is the whole job

Whatever the new system says on Saturday morning is what your shop believes for the next year. So the count matters more than the import.

Before closing. Stop receiving goods 24 hours before cutover, or receive them into a clearly marked area you will count separately. Finish all pending transfers between branches. Clear returns and damages on the old system. Print and file the final stock report, customer dues list, supplier dues list and the day's Z-report from the old system, these are your baseline.

The count. Count by aisle or rack, two people per section, one counting and one writing. Use a fresh count sheet with item, batch, expiry and quantity, not the system's printed stock report, or the counters will simply agree with whatever is printed. For a pharmacy, count batch by batch; that is the entire value of the exercise. A shop with 3,000–5,000 SKUs typically needs 4–8 people for one night.

Reconcile before you import. Compare the count with the old system's stock report. Investigate anything with a large gap in value, item by item, before it becomes the opening balance. You are not trying to explain every unit; you are trying to make sure the top 50 items by value are correct. Write down the total variance; it is the honest measure of what the old system was hiding, and it is worth reading alongside our shrinkage guide.

Import and lock. Load opening stock, then have one person do a small test bill on each counter (one cash, one bKash, one card, one credit sale to a regular customer) and check that stock moves, the invoice prints correctly, and the day-end screen shows the tenders separately. Then lock the old system to read-only so nobody bills on it by habit.

Train the counter staff before, not during

Cutover fails at the counter far more often than in the database. The cashier who has used one screen for four years will be slower on any new one, and Saturday morning is not the time to learn.

Run a one-hour session a week before, on the real system with your real items, and make everyone actually do the tasks rather than watch: normal sale, sale with discount, sale on credit to a known customer, return and exchange, bKash and Nagad payments, holding a bill while a customer fetches something, and closing the shift. Print a one-page cheat sheet in Bangla and tape it to the side of the monitor. Name one person per shift as the go-to for the first fortnight (usually the fastest learner rather than the most senior) and make sure they have the support number.

Expect billing to be 20–30 per cent slower for the first two or three days. Roster one extra person for that period. It is the cheapest insurance in the whole project.

The first week: seven checks

Do these every day for the first week, then weekly for a month.

1. 1Day-end tender reconciliation. Cash counted in the drawer, bKash and Nagad statements, card settlement, do they match the day-end report? Chase any difference the same day.
2. 2Stock on the top 20 items. Physically check twenty fast-moving items against the system. If they drift, the cause is usually a mis-set unit or a missing conversion factor.
3. 3Negative stock report. Any item showing negative quantity means something was sold that was never received. Fix the receipt, not the count.
4. 4Margins on ten items. Wrong cost price shows up as an absurd margin. Better to catch it in week one than in the annual accounts.
5. 5VAT output. Print a Mushak 6.3 invoice and the day's VAT summary, and have your consultant look at the first week before you file anything.
6. 6Customer dues. Pick your ten biggest credit customers and confirm the balance in the new system matches the statement they agreed.
7. 7Backup. Confirm a backup actually ran and, once, that it can be restored. A backup nobody has restored is a rumour.

Have a rollback plan you can actually use

Write this down before cutover night and give a copy to whoever will be in the shop.

Define the trigger in advance: for example, "if we cannot bill reliably by 11am on day one, or the day-one stock variance on our top 100 items is above an agreed threshold, we roll back." Deciding in the moment, with a queue at the counter, produces bad calls.

The rollback itself is simple if you prepared: the old system is still installed and still licensed, its data is untouched because you locked it to read-only, and its last stock report is printed and filed. You revert to billing on it, key in the handful of new-system bills, and reschedule. What makes rollback impossible is not technology; it is cancelling the old licence too early, or letting staff delete the old install to free up disk space. Keep both alive for at least 30 days, and keep the archive export forever.

What to put in your contract

You are switching once. Write the terms now that make the next switch, whenever it comes, undramatic. Ask your new vendor to put these in the agreement, in writing:

• Data ownership. Your master and transaction data belongs to you, during the contract and after it ends.
• Export on demand. You can export your full data in a standard, readable format (CSV or Excel, not just a proprietary backup) at any time, and at least once at termination, within a stated number of days and at a stated fee, if any.
• What migration includes. Which tables are migrated, who cleans the data, how many rounds of test imports are included, and what counts as an extra charge. MondayPOS includes data migration in setup, and a typical single-outlet setup runs 2–4 weeks.
• Cutover support. Whether someone will be on your premises or on the phone on cutover night and on day one, and until what hour.
• Data at termination. How long your data is retained after you leave, and how it is deleted.
• Where the data lives. Server location, backup frequency and who else can see it.

Two questions worth asking at any demo: "Import 200 of my real items, with batches, while I watch," and "Export everything you just imported, and show me the file." A vendor who can do both in a demo will not be a problem to leave.

The bottom line

Switching POS software loses stock and sales history only when nobody decided in advance what had to survive. Move the master data and the balances exactly, archive the old detail as a read-only export, count the stock honestly on cutover night, train the counter a week early, check seven things every day for a week, and keep the old system alive and locked for a month. Done that way, the switch costs one hard weekend and buys years of better numbers.

If you want to see what your own data looks like inside a new system before you commit, book a demo with a sample of your item file, or see pricing first.