To switch clinic software without losing patient data, export everything you can from the old system and clean it. Import a small test batch, run old and new side by side, then validate counts, balances and stock. Never delete the old copy until the new one passes those checks.
This guide is for doctors, clinic managers and nursing-home owners who want to migrate patient records to new software without a messy Monday morning. It covers a phased cutover plan, a data-priority table, vendor questions, validation, rollback and the legal angle (record retention and the DPDP Act).
Key Takeaways
- Treat the move as a project with phases: export, clean, test, parallel-run, validate, then retire the old system.
- Rank your data. Patients, outstanding balances and current pharmacy stock must move before go-live. Old settled history can wait or stay archived.
- Ask your current vendor in writing what you can export, in which format, by when, and whether a final export on cutover day is possible.
- Validate with numbers: patient counts, ledger balances, stock totals and a spot check of real patients. "No error message" is not proof.
- Keep a rollback path. The old system stays available until a full month-end has reconciled.
- Record-retention duties and the DPDP Act do not pause during a switch. Exported files are patient data.
- Clinizy Care offers free remote setup and a 30-day free trial, so you can test your own data.
Take stock of where your data lives
Clinic data migration is moving patient, billing and stock records from one system to another without changing their meaning. Before you export anything, write down every place clinic data is stored. Most clinics find more than expected. Common sources are the old software database, an Excel sheet at the front desk, paper registers, lab reports in a WhatsApp group and the accountant's ledger.
For each source, note what it holds and how far back it goes. Then record your baseline: total patients, total outstanding dues, last month's collections and the count of stock lines. You cannot prove a migration worked without the starting figures.
If part of your data is on paper, note that typing it in makes it digital personal data under the DPDP Act (explained below).
What to migrate first: data types, risk and priority
Not every record needs to move on day one. The table ranks data types by the cost of a mistake.
| Data type | Why it matters | Risk if wrong | Priority |
|---|---|---|---|
| Patients (name, phone, age or date of birth, ID) | Everything hangs off the patient record | Duplicates, wrong phone numbers, lost history link | Before go-live |
| Visits and prescriptions | Past diagnoses, allergies, medicines | Clinical risk if history is missing or on the wrong patient | Active patients first, archive the rest |
| Billing and ledger balances | Dues, GST records, past invoices | Money disputed; GST records split across systems | Balances before go-live, history soon after |
| Pharmacy stock, batches, expiry | Dispensing and purchasing | Wrong stock, expired medicines sold | Before go-live |
| Lab reports and attachments | Review of older cases | Files orphaned from the patient | Keep as archive, link later if needed |
| Staff and roles | Logins and permissions | Wrong access to patient data | Rebuild by hand, test every login |
| Upcoming appointments | Next week's bookings | No-shows and angry patients | Before go-live |
Anything not seen for years, and fully settled invoices, can stay archived as readable files and be imported only if the patient returns.
What to ask your current vendor
Ask early, because vendor delays are the usual reason a switch drags on. A US government guide to switching electronic health record systems notes that very few vendors include transition terms in standard contracts. It advises agreeing the data format and a conversion deadline up front. The context is American, but the principle holds here.
Send a written request, keep a copy, and ask:
- Which data can I export (patients, visits, billing, stock, attachments), and from where?
- In which formats, and is there a data dictionary that explains the columns?
- Do exports include batch numbers, expiry dates and outstanding balances, or only totals?
- Can I get a final export on cutover day so recent registrations and bills are not lost?
- Will my account stay active, read-only if possible, during the parallel run?
- What will exports or help cost, and by what date will you deliver?
- After I confirm the migration, will you delete my data and confirm it in writing?
Not every vendor will agree to all of this. If answers are vague, plan for reports you export yourself, plus PDF archives. Treat every file as a patient record: share it only through a secure link or a password-protected file.
Clean, map and test-import a small batch
Raw exports are rarely clean. Old systems collect duplicate patients, blank phone numbers, training-day test records and dates in five formats. Importing as-is moves the mess across. In Excel or Google Sheets:
- Merge obvious duplicates, such as the same name and phone number.
- Use one 10-digit phone format and one date format, such as DD/MM/YYYY.
- Remove test entries and flag missing phone numbers or dates of birth.
- Keep first name, last name, age and gender in separate columns.
Then map fields. Your old software may say "Mobile No." where the new one says "Phone". This is where imports quietly go wrong.
Clinizy Care's patient import accepts CSV or Excel, with a downloadable sample file and a preview before anything is imported. Pharmacy inventory import also has a sample and a preview. Load 20 to 30 patients first and open each record. Check that the phone number sits in the phone field and the date of birth reads as a date. Fix the mapping, then run the full import.
A phased cutover plan
A cutover is a sequence of gates. Do not move to the next phase until the current one passes. The plan has no fixed durations on purpose: your data size, your vendor's speed and your staff's availability set the pace.
- Inventory and baseline. List every data source and record starting counts and balances. Pick a quiet week, away from festival rushes and camp days.
- Vendor request. Send the written export request from the section above.
- Export and secure. Store the first export in an encrypted, backed-up place with limited access.
- Clean and map. Fix duplicates and formats, then map columns using the sample file.
- Test import and preview. Import a small batch, check the preview and open each record.
- Full import and validation. Import the rest, then run the checklist below. Fix mapping errors while re-importing is cheap.
- Parallel run. Use both systems for real work, compare daily totals and keep one issue list with an owner for each item.
- Final export and go-live. Import the last export, confirm counts, test every login and printer, and tell staff exactly which day is the switch.
- Retire, archive and erase. Make the old system read-only, archive final exports safely, and request deletion only after your retention needs are met.
Train staff on real cases, not a demo script: a returning patient, a GST bill, a part-payment, a dispensed medicine and a printed prescription.
Parallel run and rollback
Do not flip a switch on Friday and hope. A parallel run means using both systems for a while. During it, real registrations and bills go into the new system while the old one stays open as a safety net. It costs extra effort, but it catches a missing billing item early.
Each day, compare patient count and total collections in both systems and note any gap. Decide rollback rules before go-live:
- Trigger. Agree what forces a rollback, such as balances that cannot be reconciled or prescriptions printing against the wrong patient.
- Fallback. Keep the old system and the final export untouched, and record which system was the source of truth on which day.
- Re-entry. Note anything entered only in the new system so it can be re-keyed if you go back.
- Exit. Retire the old system only after you have closed one full month in the new one and reconciled it against the old figures.
Validation checklist
An import that loads without an error is not the same as an import that is correct. Use this as a sign-off sheet, with a named person and a date on each line.
| Check | How to do it | Pass when |
|---|---|---|
| Record counts | Compare patients, stock lines and open dues entries | Counts match, or every gap is explained |
| Balances | Tally one past month's collections and ten patients with pending dues | Totals and amounts match exactly |
| Stock totals | Compare total stock quantity, then count a few fast-moving medicines | Quantities, batches and expiry dates match the shelf |
| Patient spot checks | Search ten patients by phone number and review their history | Right person, right history, nothing in the wrong field |
| Live workflow | Register a patient, raise a GST bill, dispense, print a prescription | Every step completes without a workaround |
| Logins and roles | Each staff member signs in and sees only what their role allows | Access matches your role list |
If you find a mistake in ten records, assume it is in all of them. Go back to the mapping and re-import.
Retention, DPDP and the Clinical Establishments Act
This is general information, not legal advice. Confirm your duties with your legal adviser and state medical council.
How long records must be kept. The Indian Medical Council (Professional Conduct, Etiquette and Ethics) Regulations, 2002 are published on the National Medical Commission website. Clause 1.3.1 says: "Every physician shall maintain the medical records pertaining to his / her indoor patients for a period of 3 years from the date of commencement of the treatment." That clause names indoor patients and gives no period for outpatient records. Keep records longer if there is a dispute, complaint or pending case. Clause 1.3.2 says a request for records should be answered within 72 hours.
The NMC notified new conduct regulations in August 2023. Its rules and regulations page lists a 23 August 2023 notification keeping them in abeyance, and the 2002 regulations were adopted again. As of October 2026 we found no later replacement.
Clinical Establishments Act. Where it applies, rule 9 of the Central Government Rules, 2012 says establishments "shall maintain and provide Electronic Medical Records or Electronic Health Records of every patient as may be determined and issued by the Central Government or the State Government". It applies only in States and UTs that adopted it, so check yours. Our Clinical Establishments Act guide covers the basics.
The DPDP angle. The Digital Personal Data Protection Act, 2023 treats your clinic as a data fiduciary and your software vendor as a data processor. For a migration:
- Scope. The Act covers digital personal data, including data collected on paper and digitised later (section 3).
- Patient rights. Patients can ask for a summary of their data (section 11) and for correction, completion, updating and erasure (section 12). There are also grievance redressal and nomination rights. The Act has no general data portability right, so getting data out of an old vendor depends on your contract and their export function.
- Security. You must take reasonable security safeguards, including for data a processor handles for you (section 8(5)). Rule 6 of the Rules lists minimum measures: encryption or masking, access control, logs, backups and a processor contract. Apply these to export files. The Act's Schedule sets a maximum penalty of up to ₹250 crore for failing this duty.
- Contract and erasure. A processor may be used only under a valid contract (section 8(2)). Unless a law requires retention, you must erase data once it is no longer needed and make the processor erase it too (section 8(7)). So keep what medical-record rules require, and ask the old vendor in writing to delete the rest.
- Timeline. The Rules were published on 13 November 2025, and rules 5 to 16, including rule 6, take effect eighteen months later, on 13 May 2027. The PIB release describes the same 18-month phased timeline.
For wider practice, read our guide to cloud backup and data security for clinics.
Where Clinizy Care fits, and what it is not
Clinizy Care is cloud-based, hosted in India, and available in Hindi and English. Remote setup is free, and the team helps configure your clinic, doctors and pharmacy over a call. Standard Excel or CSV import is free. Complex legacy migration, manual data cleaning or unsupported formats are quoted separately, so ask before you commit.
The 30-day free trial needs no credit card, so you can test with your own data and use the trial for your parallel run. The Clinic plan is ₹1,499 a month plus 18% GST (see pricing). There is no long lock-in contract, and the product has a clinic data export and account erasure.
Clinizy is not a promise that every old system can be exported, and it does not replace your validation. It claims no NABH or ISO certification. On ABDM, the FHIR Implementation Guide for ABDM defines minimum requirements for exchanging health data in India. Ask every vendor whether ABDM integration is live today or on the roadmap. Clinizy Care's ABDM modules are built and certification is pending. Our ABDM registration guide explains the programme.
Still comparing? Read the clinic software cost guide, the free clinic software guide, the best clinic software guide, the best hospital software guide and the HMS buying questions.
Common mistakes and the first month
Most failed migrations repeat the same errors. They retire the old system too early, skip the clean-up, import everything at once, trust "no errors", migrate in a rush week, leave staff untrained or email exports around unprotected.
After go-live, review the issue list daily in week one. In week two, compare visits and collections with a similar period, since a sudden drop often means a billing item was not set up. In week four, close the month and reconcile it with the old numbers. Our first-week onboarding guide lists what to set up and in what order. Pharmacy owners should read the guide to batch, expiry and purchase management.
Ready to test your own data? Start your 30-day free trial on the Clinic plan.