Moving from paper to software is a change of habit. Moving from one software system to another is a change of habit plus a data problem, and the data problem is the one that catches clinics out.
The single most common mistake is the order of operations: giving notice to the current vendor before getting the data out. Export requests tend to become slow and complicated at precisely the moment you have announced you are leaving.
This article covers what to extract and when, how to evaluate a replacement while still running the old system, and how to switch without a day where neither system is authoritative.
Before you tell anyone: get your data out
Export first. Give notice second. This is the whole of the advice and it is routinely ignored.
While you are still a paying customer in good standing, a data export is a support request. After you have given notice it becomes a negotiation, and in the worst cases a system you can no longer log into.
What to ask for
- Patient list: names, phone numbers, MR numbers, dates of birth, addresses.
- Visit history: dates, complaints, diagnoses, notes — per patient, in a readable format.
- Prescriptions: what was prescribed, when, at what dose.
- Billing history: invoices, payments, outstanding balances.
- Inventory, if you dispense: current stock with batch numbers, expiry dates and purchase prices.
- Any uploaded files: lab reports, scanned documents, images attached to records.
What format to insist on
CSV or Excel for the structured data. A PDF of each patient record is not an export — it is a printout, and it cannot be loaded into anything.
If the vendor offers only PDFs, that is useful information about the vendor and worth weighing in your decision to leave. Ask specifically: "can I have the patient and visit data as CSV?"
Check the export before relying on it
Open it. Count the rows against what you expect. Pick five patients you know well and verify their history is complete and legible.
Exports that silently truncate — the first thousand patients, or the last twelve months — are common enough to check for every time. Discovering it after you have cancelled is a different problem entirely.
A vendor who cannot explain how you would leave is a vendor who is planning for you not to be able to. Ask the question during the sales conversation, not at the end.
What usually does not transfer, and what to do about it
Set expectations honestly: a clean, complete migration between two different clinic systems is rare. The structures do not match.
| Data | Usually transfers? | What to do |
|---|---|---|
| Patient demographics | Yes | Straightforward import |
| Visit dates and basic notes | Usually | Verify a sample after import |
| Structured diagnoses | Often not | Accept as free text; do not spend weeks remapping |
| Prescriptions | Partly | Most recent ones matter; older ones rarely consulted |
| Billing history | Sometimes | Keep the export as your record even if it does not import |
| Attached files | Frequently not | Download them separately before you leave |
| Templates and custom forms | Almost never | Rebuild; usually quicker than converting |
Attachments are the most commonly lost thing
Lab reports and scanned documents are often stored separately from the main database, and an export of "patient data" frequently does not include them. Download them explicitly, as files, and keep them somewhere you control.
Do not try to make it perfect
Clinics lose weeks attempting to remap every field. The pragmatic approach: migrate demographics and recent history cleanly, keep the full export as an archive you can search if needed, and let the new system fill forward from day one.
Within three months the new system holds complete records for every patient who matters, because the patients who matter are the ones who return.
Evaluating the replacement while still running the old one
Do not cancel anything while you evaluate. Run the trial alongside, which costs you one month of overlap and removes essentially all of the risk.
Test with your own data
Import a sample — fifty patients from your export — into the trial. A demo with the vendor's clean sample data tells you nothing about how your actual records will look, and your records are the ones with three spellings of the same name and a phone number in a notes field.
Put your receptionist in front of it
They run the diary. If they cannot book a walk-in unaided after a ten-minute explanation, the rollout will be painful regardless of what the feature list says.
Check the five Pakistan-specific things
Roman Urdu prescriptions, JazzCash and EasyPaisa in billing, behaviour when the connection drops, PKR invoicing, and WhatsApp delivery. These are the five that imported systems usually miss, and they are covered in the 2026 buying guide.
Ask the new vendor the leaving question too
Before you sign with anyone, ask how you would export your data if you left them. You are in the middle of discovering why that matters. A vendor who answers precisely is telling you something worth knowing.
The switch itself
Pick a cutover date and treat it as a hard line rather than a gradual fade. The failure mode to avoid is a fortnight where some patients are in one system and some in the other, and nobody is sure which is authoritative.
Two weeks before
- Take the full export and verify it.
- Download all attachments separately.
- Import demographics and recent history into the new system.
- Set up users, roles and payment methods.
- Build the medicine shortlist and the Roman Urdu dosage phrases.
The week before
- Train reception on the new diary specifically, nothing else.
- Enter next week's already-booked appointments into the new system by hand.
- Print a test prescription on your own printer.
- Confirm the old system is paid up to the cutover date and not a day less.
Cutover day
From the first patient, everything goes in the new system. Keep the old one open and readable — do not cancel yet — purely as a reference for history that did not migrate.
The month after
Keep read-only access to the old system for at least a month, longer if the subscription is cheap. You will need it a handful of times, and the cost of a month's access is trivial against the cost of discovering a gap after access ends.
Do not cancel the old system until you have verified a full month of normal operation on the new one, including a month-end close.
Telling patients, and telling staff
Patients barely need to know
A software migration is an internal event. Patients notice two things at most: the prescription looks different, and there may be a slower day at the counter.
Neither needs an announcement. What does help is briefing reception on one sentence to use if asked — "we have moved to a new system, your records are all here" — because the question patients actually have is whether their history survived.
Staff need to know why
Staff who were trained on the old system, got comfortable, and are now being asked to start again will reasonably want a reason. "Management decided" produces compliance at best.
Give the actual reason — it goes dark during load shedding, patients cannot read the prescriptions, the pharmacy counter is invisible — and the people who feel that problem daily become the ones arguing for the change rather than against it.
Expect a dip in goodwill around week two
There is a predictable moment, usually a week or ten days in, when the novelty has gone and fluency has not arrived. Staff are slower than they were on the old system and they remember that the old system worked fine.
This moment is normal and it passes. Knowing it is coming is most of managing it: say in advance that week two is the hard one, and it becomes a milestone rather than evidence the decision was wrong.
Specific traps
- Giving notice before exporting: the single most expensive mistake available.
- Assuming the new vendor will do the migration: many will help, but the export from the old system is yours to obtain.
- Switching during your busiest month: as with any rollout, avoidable and worth avoiding.
- Migrating everything: weeks of remapping for data you will rarely open.
- Losing attachments: lab reports and scans are frequently outside the main export.
- Letting both systems run as authoritative: pick a date, hold it, and make the old one read-only in practice.
If you are switching because of a specific problem
It is worth being precise about what you are solving, because some problems follow you.
If the issue is that the system goes dark during outages, that is a real product difference and switching will fix it — the testing procedure is in what happens when the internet goes down.
If the issue is that prescriptions are English-only and your patients cannot read them, that is also a product difference, covered in Roman Urdu prescription software.
But if the issue is that staff never adopted the system, changing vendors may not help. That is usually a rollout problem rather than a software one — everything learned at once, no named owner, started during the busiest month. Before switching, read how to set up a clinic management system and consider whether a structured re-launch of what you already own would be cheaper than a migration.
A reasonable timeline
Four to six weeks from decision to cutover is comfortable for most clinics: a fortnight of evaluation with real data, two weeks of preparation, then the switch. Plus a month of overlap afterwards before cancelling anything.
Faster is possible and usually regretted. The step clinics compress is verification of the export, which is the one step whose failure is permanent.
If you are moving from paper rather than another system, the problem is different and simpler — see going paperless. If you are moving to the cloud from an on-premise server, the cloud EMR migration checklist covers the additional steps.
Two different moves people call switching
Clinics use one word for two quite different projects, and conflating them is why advice on the subject so often misses.
Move from manual to digital clinic records
A clinic that moves from manual to digital has no export to worry about and a staff training problem instead. The risk is behavioural: the register stays on the desk, staff fall back to it on a busy afternoon, and the clinic ends up half-migrated. This is covered in going paperless.
Replacing one system with another
To switch clinic software in Pakistan from an existing system is a data problem first. You are dependent on a vendor you are leaving to give you a usable export, and that cooperation tends to decline the moment you give notice — which is why the export comes first.
If you are moving to migrate clinic data to SehatDoc specifically, the practical sequence is the same as for any system: export and verify, import into a test environment, check a sample of records against the originals by eye, then run parallel for a fixed short period before cutting over.
Frequently asked questions
- How do I move my patient records to a new clinic software?
- Request a full export from your current vendor before giving notice, in CSV or Excel rather than PDF. Download attachments such as lab reports separately, as they are often excluded. Import demographics and recent visit history into the new system, keep the full export as a searchable archive, and let the new system fill forward from the cutover date.
- Should I cancel my old clinic software before switching?
- No. Export your data first while you are still a customer in good standing, then run both systems in parallel during evaluation. After cutover, keep read-only access to the old system for at least a month — longer if it is cheap — and cancel only once you have completed a full month of normal operation including a month-end close on the new system.
- What data usually does not transfer between clinic systems?
- Structured diagnoses, custom templates and attached files are the most common losses. Demographics and basic visit history usually transfer cleanly; prescriptions transfer partly. Attachments like lab reports and scans are frequently stored separately from the main database and are missing from a standard export, so download them explicitly.
- How long does switching clinic software take?
- Four to six weeks from decision to cutover is comfortable: about two weeks evaluating with a sample of your real data, two weeks preparing the import and training reception, then the switch. Add a month of overlap before cancelling the old subscription. Faster is possible, and the step usually compressed is verifying the export — which is the one failure that is permanent.
- My staff never used our current system properly. Will switching help?
- Possibly not. If the problem is a genuine product gap — no offline support, English-only prescriptions, no local payment methods — switching fixes it. If staff simply never adopted it, that is usually a rollout failure: everything introduced at once, nobody owning it, started in a busy month. A structured re-launch of what you already own is often cheaper than a migration.
- How do I switch my clinic from another software to SehatDoc?
- Export everything from your current system before you give notice — patient demographics, visit history, prescriptions and billing records — and confirm you can actually open the export. Run both systems in parallel for a short, fixed period rather than cutting over on a Monday morning, keep the old system readable for as long as your retention obligations require, and move one department at a time if you have several.
- Is it easy to migrate patient records to a new clinic management system?
- Demographics and contact details usually transfer cleanly. Clinical notes, scanned documents, custom fields and billing history frequently do not, because every system structures them differently. Ask the new vendor what they can import and the old vendor what they can export, in writing, before committing — and never cancel the old subscription until the import has been checked by someone who knows what the data should look like.
- Migration
- Data export
- Switching
- Clinic Management
- Pakistan
SehatDoc in your city
Local pages with the practice context for each city.