Most Kenyan retailers know their current POS is holding them back long before they do anything about it. The reports are unreliable, M-Pesa still gets confirmed by hand, and nobody trusts the stock count. But switching feels risky — and the fear of losing a day of trading, or worse, losing years of sales history, keeps businesses on software they have already outgrown.
That fear is understandable but usually misplaced. A migration done carelessly is genuinely disruptive. A migration done with a plan is boring, which is exactly what you want. Here is the plan.
Before you start: two decisions that shape everything
What are you actually taking with you?
You do not need to migrate everything. Be deliberate about this, because it determines most of the work.
Take: your product catalogue with prices and barcodes, current stock levels, supplier records, and customer records with contact details and outstanding balances.
Leave behind, but archive: years of individual transaction history. Almost no business queries three-year-old line items in a POS. Export it to CSV, store it somewhere safe, and start the new system clean. Trying to import full transaction history is where migrations become month-long projects for no practical benefit.
Verify before taking: your stock levels. Migrating a stock count you do not trust means starting the new system with the old system's errors baked in. Do a physical count instead — the migration is the natural moment for it.
When will you cut over?
Pick your quietest trading period. For most Kenyan retail that is a weekday morning early in the month, after the end-of-month rush and before the weekend. Avoid: month-end, the days after payday, and anything close to Christmas or Ramadan trading peaks.
Give yourself a full week from first import to cutover. It will probably take less, but a deadline with no slack is how mistakes happen.
Week-by-week migration checklist
Days 1–2: export and clean
Export from your old system: products, prices, barcodes, stock levels, suppliers, customers. CSV is the format you want. If your current system cannot export — worth noting as a lesson for the next choice — you may have to rebuild the catalogue by hand, which makes the cleanup below mandatory rather than optional.
Then clean the data before it goes anywhere near the new system. This is the highest-value hour of the whole migration:
- Delete discontinued products. Most catalogues carry 20–40% dead lines. Do not import them.
- Fix inconsistent naming. "Coca Cola 500ml", "Coke 500ML" and "coca-cola 500 ml" are one product. Merge them.
- Check for duplicate barcodes. Two products sharing a barcode will break scanning on day one.
- Verify prices. Migration is a good excuse to review pricing you have not looked at in a year.
- Standardise units. Decide whether you sell by piece, pack or kilo, and be consistent.
A clean import is the difference between a migration that takes two days and one that generates problems for two months.
Day 3: import and verify
Import into the new system. On sell.ke this is a CSV upload under Products → Import, and the support team will do the first pass with you over WhatsApp if you send them the file.
Then verify — do not assume. Check specifically:
- Total product count matches what you imported
- Spot-check 20 products across different categories for correct price and barcode
- Confirm your ten best-sellers are present and correct
- Scan five physical items and confirm the right product comes up
- Check that special characters and Swahili product names imported cleanly
Day 4: configure, don't just import
Data is only half of it. Configure the system to match how you actually operate:
- Connect M-Pesa. Enter your till number or paybill and Daraja credentials. Test with one real low-value payment — not a sandbox transaction — and confirm it appears against the sale automatically.
- Connect KRA eTIMS. Link your KRA PIN, confirm the certificate is configured, and generate one test receipt. Check the QR code scans and resolves.
- Set up staff accounts and roles. Every cashier gets their own login. Nobody shares. Restrict voids, discounts, price overrides and stock adjustments to managers.
- Configure your receipt. Business name, KRA PIN, till number, return policy, and your online store URL — a receipt is free advertising.
- Set reorder levels on your fast-moving lines so low-stock alerts start working immediately.
- Pair your hardware. Receipt printer, barcode scanner, cash drawer. Test each.
Day 5: train the people who will use it
Train your cashiers on the new system before cutover, not during it. Thirty to sixty minutes each is usually enough for a well-designed POS. Cover the ten things they do every day:
- Start a shift and open the till
- Ring up a sale by scanning and by search
- Take an M-Pesa payment and confirm it landed
- Take cash and give change
- Split a payment between M-Pesa and cash
- Apply a discount, and know when they are allowed to
- Void a line and void a sale, and know who must approve it
- Process a return or refund
- Sell while offline, and know what changes
- Close the shift and reconcile
Have each cashier complete a full practice sale of each type. If someone is struggling, better to know now than at 11am on cutover day.
Day 6: parallel run
Run both systems for one trading day. Every sale goes through the new POS, and gets recorded in the old one too.
This is extra work for a day and it is worth it. At close, compare the two: total sales, transaction count, M-Pesa total, cash total. If the numbers match, you are ready. If they do not, you have found a configuration problem while you still have a working fallback — which is precisely the point.
Day 7: cut over
Switch fully to the new system. Keep the old one installed but unused for at least 30 days — not as a fallback to trade on, but as a reference if you need to check something historical.
On cutover day:
- Do a physical stock count first thing and enter the verified numbers as opening stock. This is the single most important step in the whole migration. Everything the new system tells you about inventory depends on starting from a true count.
- Be on site. Whoever ran the migration should be present for the first few hours.
- Watch the first ten sales end to end. M-Pesa confirming automatically? eTIMS receipt generating? Stock deducting?
- Reconcile at close and compare against the same day last week.
What usually goes wrong
Nobody did a physical count. The most common and most damaging mistake. You import last system's stock numbers, they were already 8% off, and now the new system's reports are wrong from day one — and you blame the new system.
M-Pesa was tested in sandbox only. Sandbox payments succeed when production credentials are wrong. Always test with one real shilling amount before cutover.
Staff were trained the morning of the switch. Training during a live queue is not training. It is chaos with customers watching.
Cutover was scheduled at month-end. Your busiest trading and your reporting deadline in the same week as a system change. Do not.
Barcodes were not tested with the actual scanner. Data can import perfectly and still fail at the till if the scanner appends a character or the barcode format differs. Scan real items.
The old system was cancelled immediately. Keep read access for 30 days. It costs one more month of subscription and removes an entire category of panic.
Migrating multiple branches
Never switch every branch on the same day. Migrate one branch first — ideally a mid-sized one, not your busiest and not your quietest — and run it for a full week.
That week teaches you things no plan anticipates: which parts of the training were unclear, which configuration you got wrong, which reports your managers actually want. Fix those, then roll out to the remaining branches one at a time, a few days apart.
The whole process for a three-branch operation is typically two to three weeks. Trying to do it in one weekend is how businesses end up trading blind on a Monday. See the multi-branch operations guide for how the branches then work together.
What sell.ke does to help
Migration support is included on paid plans rather than sold as a service:
- CSV import for products, prices, barcodes, stock levels, suppliers and customers
- The onboarding team will review your export file and flag duplicate barcodes, inconsistent naming and pricing anomalies before import
- M-Pesa and KRA eTIMS setup walked through over WhatsApp, including the Daraja production switch
- Staff training sessions for your cashiers
- Someone reachable on WhatsApp during your cutover day
If you are evaluating systems rather than committing yet, the buyer's framework covers what to check first, and the comparison criteria give you a scoring sheet.
Frequently asked questions
How long does a POS migration take in Kenya? For a single shop with a few hundred products, about a week from first export to cutover, with only one day of parallel running. Multi-branch operations should plan two to three weeks, migrating one branch at a time.
Will I lose my sales history? Not if you export it first. Export your full transaction history to CSV and archive it. Most businesses do not import old line items into the new system because they never query them — but keeping the archive costs nothing.
Can I migrate without closing the shop? Yes. Nothing in this checklist requires closing. The parallel-run day is extra work for your cashiers but you keep trading normally, and cutover happens between customers.
What if the new system does not work out? Keep the old system installed and readable for 30 days. Confirm before you commit that the new system lets you export your data yourself — if it does not, that is a reason to choose differently.
Do I need to physically count stock before switching? Yes, and it is the step most likely to be skipped. Importing an unverified stock figure means the new system starts with the old system's errors and every report inherits them.
Ready to move? Start free at sell.ke — the onboarding team will look at your export file before you import anything.