Moving to POS software should give the shop a trustworthy starting position. Importing every spreadsheet row quickly is not the same achievement. The new system needs to identify products correctly, explain opening stock and customer balances, and let staff trade without maintaining competing versions of the truth.
Our first recommendation is to scope Bizman Sales and Inventory around a counted stock position and a rehearsed migration. Bring representative files to BriskRetail after removing unnecessary personal data, and agree what will move, what will remain in a protected archive and what must be corrected first. No migration duration or automatic import capability is promised in this article.
Commercial disclosure: BriskRetail offers Bizman. This is an affiliated planning guide, researched on 23 October 2026, not a report of a completed customer migration. All sample stock and naira amounts are fictional. The mapping below is a preparation worksheet, not a verified Bizman upload specification.
COVER BRIEF — Original illustration, 1600 × 900. A spreadsheet becomes a reviewed product map, stock count and signed opening balance. Alt text: “A retail migration starts with clean identifiers and reconciled balances.” No genuine customer records or invented product screenshots; artwork pending.
1. Define what is moving and which records remain authoritative
List the source files and their owners: product catalogue, physical counts, purchases, supplier balances, customer credit, price lists and historical sales. Record their date, branch and purpose. A workbook called “final stock” is not reliable evidence of when it was last counted.
Decide whether historical transactions will be imported, summarised or retained in a searchable archive. Importing years of imperfect records can introduce more confusion than value. Keeping only opening balances, however, requires a usable history for returns, disputes and accounting evidence. Agree that boundary with the people who will need those records.
Set one authoritative source for each field during preparation. The selling-price sheet may be current while the stock workbook contains old prices. The customer-balance file may be correct in total while its invoice allocations need repair. Do not allow a convenient source file to overrule the owner of the underlying process.
Preserve untouched copies of the source files and work on controlled preparation copies. Record changes with a reason and owner. A correction should be explainable later, especially where two apparently duplicate product rows are actually different sizes or purchase units.
2. Clean identifiers, variants and units before quantities
Give each sellable variant a stable SKU. A red medium shirt and a blue medium shirt should not share a stock identity merely because both were entered as “shirt.” Separate a barcode from the internal SKU: one is a scanning identifier, while the other is your controlled product reference.
Microsoft’s guidance on leading zeros and large numbers explains how Excel can alter numeric-looking identifiers. Treat barcodes and similar codes as text during preparation, then inspect the actual exported values. Changing display formatting after digits have been lost does not reconstruct them.
Define the base stock unit and each conversion. If one carton contains 24 pieces, write that relationship explicitly. Do not import a count of five cartons as five pieces. If suppliers use different pack sizes, distinguish the packs and confirm how purchasing converts to the common stock unit.
| Source field or issue | Prepared meaning | Validation before import |
|---|---|---|
| Product name | Clear description plus required variant | Different stock identities remain distinct |
| SKU and barcode | Stable text identifiers | Unique where required; leading zeros preserved |
| Quantity and unit | Base-unit count by location | Pack conversion reconciles to counted units |
| Cost and selling price | Separate fields with a stated tax basis | No selling price used as opening stock cost |
| Customer or supplier balance | Referenced outstanding amount at cut-off | Agrees to approved supporting schedule |
Normalise spelling and spaces without blindly merging records. Two suppliers with similar names may be separate entities. Two customer rows may share a phone number but belong to different people. Keep a reviewed exception list and preserve the old-to-new identifier map.
3. Agree the opening valuation and financial boundary
Quantity and value are separate acceptance tests. A system can import the right number of units at the wrong cost, causing apparently healthy margins that are false. Ask the accountant to approve the opening cost basis and treatment of taxes, freight, damaged stock and any valuation adjustment.
For a fictional cutover, the accepted physical stock is:
| Item | Opening quantity in base units | Approved example unit cost | Opening value |
|---|---|---|---|
| A | 120 pieces | ₦1,000 | ₦120,000 |
| B | 80 pieces | ₦2,500 | ₦200,000 |
| C | 50 pieces | ₦600 | ₦30,000 |
| Total | 250 pieces across these items | Not a common unit cost | ₦350,000 |
Item A might represent five cartons of 24 pieces. Import either the agreed converted quantity or the supported unit relationship, not both as separate opening stock. The total piece count is useful for this simple example; in a real catalogue, do not add kilograms, litres and pieces into a misleading grand quantity.
Suppose approved customer receivables are ₦90,000 and supplier payables are ₦140,000. Reconcile each to its invoice or opening-reference schedule. Do not create ordinary new sales merely to reproduce old debt: that can duplicate revenue, tax and stock movements. The target system’s opening-balance mechanism must be understood and demonstrated.
Likewise, an opening stock upload and an imported old purchase receipt can both increase stock if the boundary is poorly designed. Agree which records have a financial or stock effect and which are historical references only. Have the accountant sign off the migration boundary before the full import.
4. Obtain the actual import template and test its behaviour
Ask for a sample file exported from the proposed version and configuration. Determine which columns are required, which are optional, how dates and decimals are represented and what an empty field means. Do not rename headings simply to make them more readable if the importer depends on them.
Loyverse’s import documentation recommends creating representative sample items and exporting them as a pattern. Its variant and multi-store fields illustrate why a generic product spreadsheet may be insufficient. That method is useful for planning, but its column names are not a Bizman specification.
Shopify’s product CSV documentation warns about dependent variant fields and distinguishes product import from multi-location inventory import. Missing or blank information can have significant effects. Ask the Bizman implementer to show the equivalent rules for the chosen importer rather than assuming a blank cell means “leave unchanged.”
Confirm whether a repeated import creates, updates or duplicates records. Odoo’s import/export guide explains external identifiers for matching records. Whatever mechanism the target uses, keep a durable old-to-new mapping and prove what happens when the same test file is processed again.
Never test overwrite behaviour against the only live copy of the business. Use an isolated environment with a known reset point and disable external messages or financial actions. Treat imported text as data; unexpected spreadsheet formulas or executable content should not become part of the migration workflow.
DIAGRAM BRIEF — Original mapping diagram, 1440 × 960. Preserved source → reviewed transformations → trial import → reconciliation → approved cutover. Alt text: “Each imported record can be traced back to its source and reviewed transformation.” No actual customer data; illustration pending.
5. Rehearse representative transactions after the trial import
Do more than count rows. Scan a barcode with a leading zero, sell the smallest unit from a carton-based item and select a product variant. Test a customer with an opening balance and a supplier with an outstanding invoice. Include a zero-stock item and a product that should not be available for sale.
For the fictional stock example, sell three units of A and two of B in the test environment. Remaining quantities should be A 117, B 78 and C 50. At the example costs, cost of goods sold is ₦8,000, and remaining stock value is ₦342,000. If one A is returned saleable and the cost reversal follows the agreed example policy, stock becomes ₦343,000 and net cost of goods sold ₦7,000.
These calculations test the example, not a universal valuation method. Confirm the actual return-cost treatment with the accountant and supplier. A damaged return may have a different stock state or write-down and should not automatically increase saleable availability.
Check customer allocations as well as the balance displayed. A ₦10,000 receipt against an opening receivable of ₦90,000 should leave ₦80,000 under this simple example, but the correct invoice or opening reference must also be settled. A correct grand total can hide incorrect customer allocation.
Train users during the rehearsal. A cashier should complete a sale, authorised discount and return; the receiver should enter a purchase in the correct unit; the manager should investigate an adjustment. Record usability failures alongside data failures, because both can disrupt the first trading day.
6. Plan the stock count and cut-off precisely
Choose a cut-off time and control movements around it. If stock is counted on Friday but imported on Monday, record every sale, receipt, transfer and return in between. The opening position must represent the agreed cut-off, not an unexplained mixture of dates.
Count by location and stock state. Separate damaged goods, customer reservations, supplier-owned stock and goods in transit as appropriate to the business. Clarify ownership and accounting treatment rather than loading everything physically present as available stock.
Arrange independent recounts for important differences. A spreadsheet discrepancy is not resolved simply by choosing the larger number. Keep count sheets, approved adjustments and reasons. The shrinkage guide explains why differences deserve investigation.
Freeze catalogue edits during the final conversion or maintain a controlled change queue. New products created after extraction can otherwise be missing on opening day. Similarly, changed prices must reach the final file through an authorised process, not an unrecorded last-minute edit on someone’s laptop.
Set responsibilities for final extraction, conversion, upload, verification and release. The shop owner should know who can make a go/no-go decision and how the team will communicate if the work overruns. A cutover plan needs a realistic trading contingency, not a promise that every shop can migrate over one weekend.
7. Use a reconciliation sheet and a genuine go/no-go gate
Agree acceptance criteria before the migration. Compare independent totals from the approved source with the target, then inspect representative records and relationships. Any permitted tolerance should have a reason; “close enough” is not a suitable policy for an unexplained customer debt difference.
| Acceptance check | Fictional source expectation | Required decision |
|---|---|---|
| Product identities | Three example SKUs; no unintended duplicates | Match identities and mappings |
| Stock quantities | A 120, B 80, C 50 at cut-off | Explain all location and unit differences |
| Opening valuation | ₦350,000 | Accountant accepts basis and total |
| Receivables and payables | ₦90,000 and ₦140,000 | Match schedules and allocations |
| Operations and recovery | Sample workflows pass; restore rehearsed | Owner approves release or delays |
Keep the actual sheet with counts, totals, exceptions, reviewer and timestamp. Do not sign off only a screenshot of the dashboard. The reviewer should be able to trace a sample product or invoice back to its source and explain any transformation.
Examples of a no-go include duplicate customer balances, unexplained stock value, incorrect tax settings, failed barcode scanning on essential items or no workable recovery procedure. A small cosmetic label issue may be scheduled for correction, but material errors require resolution before ordinary trading begins.
8. Define rollback before the first live transaction
Before live trading starts, rollback may be as straightforward as restoring the known pre-import state or resetting an isolated target, provided the source remains intact and no external actions occurred. After trading starts, returning to the old system is a reconciliation project: new sales, payments, returns and receipts must be preserved and accounted for.
Draw that boundary explicitly. Record the last source transaction, first target transaction and exact release time. If rollback becomes necessary, stop uncontrolled dual entry, capture the target’s new activity and have the designated team reconcile it before resuming elsewhere. Never wipe the new system just because the old spreadsheet still exists.
Shopify’s backup documentation shows why an export may not reproduce all system records and configuration. Apply the same scrutiny to the proposed recovery route: can the team restore both data and usable operation, and has it actually rehearsed that process?
Keep the former source read-only for the agreed retention period, with access controls. It can support investigation without continuing as a competing live ledger. During the first trading days, review exceptions daily and record approved corrections in the new system.
WORKFLOW BRIEF — Original decision diagram, 1440 × 810. Before first live sale: reset possible; after live sale: preserve and reconcile new activity. Alt text: “Rollback changes once real transactions have entered the new POS.” Conceptual boundary, not a product guarantee; artwork pending.
9. Request a migration scope that the shop can verify
Ask BriskRetail for a written Bizman Sales and Inventory migration scope covering record types, source cleaning, opening balances, trial import, training, cutover support and acceptance evidence. Separate standard import capability from custom work. Costs and timelines are quote required after inspecting representative data.
The data-migration service page is a starting point for that discussion, not proof that every legacy file or transaction type is supported. Agree what happens to rejected records, how personal data is protected and who owns the final exports and mapping documentation.
For comparison, Loyverse’s documented CSV workflow may suit a simpler catalogue, while Odoo’s import tools address broader record relationships with configuration effort. If an existing system already meets the shop’s needs, cleaning its data may be preferable to replacement. The reason to move should be a demonstrable operational improvement, not dissatisfaction with a messy spreadsheet alone.
Use the Bizman product information and request a scoped consultation. The migration is ready when stock, balances and working procedures can be explained and reproduced—not merely when the importer says it finished.