POS Data Migration Guide

Introduction

Changing POS touches the moment of sale and the records used to control products, stock, cash, customers and taxes. Migration risk is not limited to whether a CSV imports. A product can load under the wrong barcode, an opening stock total can match while branch quantities are wrong, or a customer balance can move without the transactions required to explain it.

Table of Contents

1. Define scope and cutover strategy
2. Inventory data and integrations
3. Clean products, prices and tax
4. Prepare inventory and opening stock
5. Customers, loyalty, suppliers and users
6. Transaction history and finance
7. Configure, load and test
8. Pilot, cutover and stabilize
9. FAQs

Scope and Strategy

Decide:

• Branches, registers and warehouses in each wave.
• New or reused hardware.
• Products/categories/variants/barcodes.
• Price lists/promotions/tax.
• Opening stock and in-transit goods.
• Customers, credit/store value and loyalty.
• Suppliers/purchasing.
• Users/roles.
• Open orders, layaways, returns or vouchers.
• Historical transactions and reporting access.
• FBR, payment, accounting, ecommerce/delivery and BI integrations.

Choose a rollout:

• Pilot/waves: learn and reduce risk; requires temporary multi-system coordination.
• Big bang: one transition; higher support and recovery risk.
• New branch first: low legacy migration but may not test existing-branch complexity.

Clear go/no-go criteria must be established: transaction scenarios must pass, integrations must function, stock balances must reconcile, users must be trained, and devices must be provisioned.

Inventory Sources and Ownership

A source register should be created mapping legacy POS, ERP, ecommerce, and payment systems to identify the authoritative system of record for each data object.

Common conflicts:

• Product descriptions/barcodes differ between POS and ecommerce.
• Stock differs between branch sheet, POS and accounting.
• Customer balances are in accounting while contact details are in POS.
• Prices/promotions exist in local files.
• Users are shared or inactive.

Resolve ownership before mapping. Do not let the easiest export become truth automatically.

Clean Product, Price and Tax Data

Product master

Validate unique SKU/barcode, description, category, brand, variant, unit/pack, active status and tax classification. Identify duplicate barcodes, missing variants, retired products and free-text categories.

Preserve legacy IDs for traceability. Define who can create/change products after launch.

Prices

Map base, branch/region/channel/customer prices, effective dates, markdown and promotion. Decide how old future-dated promotions are treated. Test rounding and display.

Tax/FBR

Qualified tax owners approve mapping based on current requirements. Test representative taxable/exempt/discount/return scenarios. Link this guide to current official FBR sources; do not rely on historical assumptions.

Inventory and Opening Stock

Stock migration is both data and physical control.

System States

On-hand, available, reserved, in-transit, damaged/quarantine and consignment may exist. Decide what the new platform can represent and how each state is counted.

Clean location

Validate branch/warehouse/bin and product-unit combinations. Resolve negative stock, impossible quantities and open transfers.

Count and freeze

Plan a physical or controlled count close to cutover based on risk. Define transaction freeze/capture, recount, variance approval and late movement treatment. A total-value match is not enough; reconcile quantity by location/item and agreed value/accounting outputs.

In-transit and open receiving

Decide whether to complete in the old system, recreate in the new, or migrate as open documents. Avoid stock disappearing between dispatch and receipt.

Customers, Loyalty and Credit

Migrate only needed personal data with approved privacy basis, access and retention. Profile duplicates, missing contacts and inconsistent identity. Do not merge customers solely on a shared phone/email without review.

For loyalty/store credit/account balance:

• Confirm owner system and total.
• Reconcile by customer.
• Preserve expiry/terms where applicable.
• Define opening transaction/reference.
• Communicate any program change.
• Test returns/redemption.

Historical purchase detail may be migrated, summarized or archived. Consider customer service and legal/retention needs.

Suppliers, Purchasing and Users

Supplier data may remain authoritative in accounting/ERP. Map IDs, legal/display name, tax/payment references and active status only as required.

For open purchase orders/receipts, choose complete/recreate/migrate and reconcile.

Create unique users with branch/role/approval limits. Remove shared/inactive accounts. Train high-risk workflows: refunds, voids, discounts, stock adjustments, cash close and master changes.

Transaction History and Finance

Ask what history users need inside the new POS:

• Returns against old receipts.
• Warranty/customer service.
• Trend reporting.
• Audit/tax retention.
• Loyalty and balances.

Options:

• Full validated transaction migration.
• Limited recent period.
• Summary opening balances plus searchable legacy archive.
• Read-only legacy system for a controlled period.

The accounting cutover date must be precisely defined, capturing opening receivables, tenders, and stock value. Finance must sign off on reconciliation, and opening balances should never be created without a traceable source.

Configure, Load and Test

Repeatable loads

Use mapping rules, error reports and versioned files. Run trial loads into a test environment. Maintain source row ID and target ID.

Reconciliation pack

• Products active/inactive and barcode uniqueness.
• Prices by list/branch.
• Stock quantity/value by branch/category/item.
• Customers and credit/loyalty totals.
• Suppliers/open documents.
• Users/roles.
• History records/attachments loaded and rejected.

End-to-end scenarios

Run sale, mixed basket, discount, return/exchange, branch transfer, purchase receipt, stock count/adjustment, customer credit/loyalty, shift close, FBR, payment and accounting reconciliation. Test offline and recovery where required.

Users perform tasks. Validate labels, search and performance with realistic volume.

Pilot, Cutover and Stabilize

Pilot

Select a representative branch—enough complexity to test, engaged local ownership and manageable business risk. Run controlled comparison of sales, stock, payments and tax/accounting outputs.

Cutover plan

• Final transaction/freeze timeline.
• Physical count/opening balance.
• Final/delta export and load.
• Device/peripheral deployment.
• Production credentials and integrations.
• User activation.
• Go/no-go and rollback.
• Old-system read-only/archive.
• Customer/branch communication if needed.
• On-site/remote support roster.

Stabilization

Daily review of failed transactions/integrations, stock variance, price/tax errors, returns, cash/payment reconciliation, user access and support tickets. Correct master/workflow issues fast and communicate changes.

Strict criteria must define when a pilot is stable enough for broader deployment. A rollout should never proceed based solely on arbitrary calendar dates if financial reconciliation remains unresolved.

Common Mistakes

• Migrating every field/history without purpose.
• Using branch files without source ownership.
• Loading duplicate products/customers.
• Treating opening stock as an IT total.
• Ignoring in-transit/open purchases.
• Testing only normal cash sale.
• Leaving shared users.
• Underestimating hardware/peripheral drivers.
• Running old/new operational records indefinitely.
• Rolling out before finance/tax reconciliation.

FAQs

What data should move to a new POS?

Required masters, prices/tax, opening stock, active users and relevant customer/supplier/balance data. History based on service, reporting and retention needs.

Can all transaction history be migrated?

Sometimes, but quality/model differences can make archive or limited migration safer. Define needs and test.

How do we prevent inventory loss?

Controlled count/freeze, clear treatment of open movements, trial loads and item/location reconciliation with owner sign-off.

How long does migration take?

Depends on branches, sources, quality, integrations, hardware and rollout. Profile before estimating.

Should all branches switch at once?

Only when standardization, testing, support and rollback justify it. Pilot/waves often reduce risk.

What happens to the old POS?

Make it read-only/archive with approved retention/access, then decommission when obligations and support needs permit.