A pharmacy software migration is successful when the new system represents the business correctly and staff can complete ordinary work. Uploading a CSV without an error message proves neither of those things.
Use a rehearsal, a reconciliation and a controlled cut-over. The approach works across countries, but local requirements for records, privacy, tax and retention must be handled with the responsible professional and system providers.
Inventory the records before exporting
List products, batches, stock locations, supplier balances, purchase records, sales history and any customer information that is actually needed. Distinguish data required for operations from old material retained for evidence or reporting.
Define the export cut-off and ownership of each dataset. If one export was taken Monday and another Friday, their opening balances may describe different businesses. Keep the source files unchanged and work on controlled copies.
Map fields and units explicitly
Build a mapping sheet with source field, destination field, transformation, responsible reviewer and sample value. Treat product identity, strength, form, pack size and batch as distinct fields. Do not merge two products solely because their display names look alike.
Suppose the old system records seven boxes with 20 units per box. The destination expects individual units. The starting quantity is 140, not seven. Run this conversion on a sample first and keep the approved conversion rule beside the import.
Dates need similar attention. An ambiguous date such as 04/05/2026 can mean different days across markets. Use explicit date formats, confirm expiry interpretation and distinguish a date-only field from a timestamp with a time zone.
Reconcile before approving the switch
Compare product counts, batch counts, quantities by base unit, inventory valuation on an agreed basis and outstanding supplier balances. A matching grand total can still hide one overstated product and another understated product.
Create exception categories: duplicate product, unknown batch, missing expiry, unsupported field, unit mismatch and unexplained balance difference. Each exception needs a decision owner. Never resolve a material discrepancy by editing both sides until they agree.
Test a small set of real workflows using safe test data: receiving a delivery, selling a permitted item, refunding under policy, adjusting stock with approval and exporting a report. Check that staff understand the resulting records, not just the screen clicks.
Plan the cut-over and rollback
Select a period with manageable demand. Decide when the old system stops accepting transactions and where any unavoidable interim transactions will be recorded. Reconcile that short interval before opening the new system for normal work.
Write the rollback trigger, decision maker and recovery method before starting. Keep an accessible read-only historical export where appropriate. A rollback that loses transactions made after cut-over is not a safe plan.
Protect exports containing personal information, restrict access and establish a retention/deletion decision under applicable local rules. Do not use real customer data in a public demo or upload it to an unapproved AI tool for cleanup.
For developers, preserve import identifiers and batch mappings so a rehearsal can be repeated without creating duplicates. Provide a preview and an exception report before anything is posted into the operational ledger.
Use RunMyPharmacy's inventory workflow to define the destination records you need, then ask the team about migration and exports. Confirm available import formats and historical-data support instead of assuming that any spreadsheet can be migrated automatically.
Disclosure: created for the RunMyPharmacy team with AI drafting assistance and checks of examples, sources and product links. We build the linked product. Numerical examples are hypothetical.
Top comments (0)