Switching
Moving your data across
We have done this from a twenty-year-old PHP system, and the hard part was never the copying. It was telling the customer the truth about what we found.
The import runs as a rehearsal first
The first run happens inside a transaction that is rolled back at the end. Every constraint is really enforced, so the report is exactly what a live run would produce — a rehearsal, not a simulation. Nothing is written.
You read the report, fix what is worth fixing in the old system while your staff are still using it daily, and then we run it for real on a day with no cases scheduled.
And it tells you what it could not read
Older systems store quantities and dates as free text, so the same column ends up holding four different date formats and the occasional “12 ea”. Anything ambiguous is reported rather than guessed at.
- Unreadable expiry dates — imported with no expiry and flagged, so you check the packaging rather than trusting a guess.
- Ambiguous dates — 03-04-27 could be March 4th or April 3rd. We read it the way the old code wrote it and tell you which ones those were.
- Quantities that are not numbers — reported as errors, never quietly coerced to zero, because that would write off real stock.
- Cards pointing at deleted items — dropped, with a count.
The uncomfortable one: your counts will not match
Most older systems store each quantity in two places and update them from different screens. After a few years they disagree.
We rebuild on-hand from the detailed lot records, because those are what carry the lot number and expiration date you need for traceability. Then we list every item where the two figures disagreed.
Neither number is trustworthy. The lot detail is simply the more useful of the two. That list is what you count on cutover day, and from that point the numbers are right and stay right.
A vendor who imports quietly and says nothing is not doing you a favour. They are moving the discovery to the week you are relying on it.
What the report looks like
--- Imported --- vendors 18 items 608 lots 1,204 cards 25 orders 431 cases 5,912 --- Data quality --- errors 3 warnings 147 --- Stock discrepancies (14) --- Catalogue Item was now diff IOL-22 IOL Monofocal 22.0D 40 30 -10 TIP-9 Phaco handpiece tip 5 10 +5
What comes across
| Vendors | Contacts, ordering numbers, account numbers |
|---|---|
| Item master | Names, catalogue numbers, barcodes, costs, par levels |
| Stock on hand | Rebuilt per lot, with expiration dates |
| Preference cards | Including the item list and expected quantities |
| Purchase orders | With what was ordered and what was received |
| Case history | Grouped into cases, with the lot used on each line |
| Adjustments | Who changed a quantity, when, and why |
| PO numbering | Continues your sequence rather than restarting |
One thing we will not carry across
Passwords. If your current system can show a password to an administrator, it is storing them in a way that cannot be migrated safely — and that means they should be treated as already compromised. Everyone sets a new one on their first sign-in. We import the accounts and flag them, so you can see who is who and invite the people you still need.
Cutover, step by step
- 1Send us an export of your current database, or give us read access to a copy.
- 2We run the rehearsal and send you the report, usually the same day.
- 3You fix what is worth fixing in the old system while staff still use it.
- 4Pick a day with no cases scheduled. Usually a Friday afternoon.
- 5We take the final export and run the import for real. It takes minutes, not hours.
- 6You count the items on the discrepancy list and post the real figures.
- 7Invite your staff. Keep the old system read-only until a month-end has closed cleanly.
Questions about switching
- What does the migration cost?
- Nothing, for a standard import. If your old system is something unusual and it needs bespoke work, we will tell you what that costs before you sign up rather than after.
- How long are we down?
- The import itself takes minutes. The real work is counting the items on the discrepancy list, which depends on how many there are — the report tells you that in advance, during the rehearsal.
- Can we run both systems in parallel?
- For a week or two, yes, and we recommend keeping the old one readable until a month-end has closed cleanly. Do not enter cases in both: you will end up reconciling two sets of numbers by hand, which is worse than either.
- What if the import gets something wrong?
- Every imported row keeps a reference back to its original identifier, so anything can be traced to where it came from. And because the first run is a rehearsal, mistakes are found before they are written.
- Our data is in spreadsheets, not a system.
- That is common and usually easier. Send us what you have and we will tell you what is usable.
Send us your export
We will run the rehearsal and show you what is really in your data — before you commit to anything.