Getting the data out is the real work
Desktop lab software typically stores data in a local database — often Microsoft Access, SQL Server Express, Firebird or a proprietary format. Extracting it ranges from straightforward to genuinely obstructive, depending on how the vendor feels about customers leaving.
Some vendors provide a clean export. Some provide a partial one that omits historical reports. Some charge for it, and a few simply refuse. If you are still evaluating your current vendor, asking how you would export your data is a revealing question.
Where no export exists, we can usually work directly from a database backup file. Most desktop packages produce one for their own backup purposes, and that is often enough.
What comes across
From a reasonably structured database, almost everything does.
- Patient master with demographics and contact details
- Historical bills with dates, tests, amounts and payment status
- Test master with rates, units, reference ranges and methods
- Referring doctor list with any associated commission or rate structure
- Historical results where they are stored as data rather than only as printed copies
- Outstanding dues and advance balances
Report formats
This matters more than labs expect. Your referring doctors have been reading your report format for years, and they recognise it. A redesign at migration generates questions you do not need to field in your first week on a new system.
We rebuild your existing format rather than substituting ours: letterhead, logo placement, column order, grouping, footer text, signature blocks. The aim is that a doctor receiving a report should not be able to tell you have changed systems.
If you want the format improved, that is a separate conversation to have after you are settled, not during migration.
Switching over without downtime
We migrate into a staging environment first, so you can see exactly what came across before anything changes. You verify a sample of patients, bills and reports against your existing system.
Once you are satisfied, we do a final incremental migration to capture anything entered since, usually on a Friday or Saturday evening. You open the next working day on Diagnosuya.
Your old system stays on the machine it is on, read-only, for as long as you want it. We recommend keeping it for at least three months. Nobody has ever regretted that, and a few labs have been glad of it.
What usually goes wrong, and how to avoid it
The most common problem is discovering at migration that the old system was not storing something you assumed it was — historical results held only as printed PDFs, or referring doctor data that was never captured consistently. Finding this out early is much better than finding out at go-live, which is why we migrate to staging first.
The second is staff anxiety. People who have used one system for a decade are reasonably nervous about a new one. Training on your own migrated data rather than a demo database helps considerably, because they are looking at patients they recognise.