How to Switch Hospital Management Software in India

Most hospitals plan a software change around the system they are moving to. The thing that actually decides how the change goes is the system they are moving from — and specifically whether you can get your data out of it, in a form a machine can read, on a date you choose rather than one your outgoing vendor chooses.

If you read nothing else here, these three:

1. Ask for the export before you sign anything new. Your negotiating position with the old vendor is at its strongest while they still think they might keep you.
2. Assume the masters break, not the patients. The patient list usually moves cleanly. The doctor list, the tariff catalogue, the item codes and the numbering series are where migrations actually fail.
3. Keep less than you think. Migrating everything is the most expensive option and rarely the most useful one. Decide what you need live, what you need readable, and what you are only keeping out of habit.

What to ask for, from the vendor you are leaving

Your data, in a format a machine can read

“We will give you your data” is not an answer. Ask for the format in writing. What you want is CSV or a database dump — one file per table, with column headers, in a character encoding that survives Indian names. What you do not want is a folder of PDF reports, which is a picture of your data, not your data.

Ask, in one email:

• Which tables or entities will be included, and which will not
• The file format and the encoding
• Whether attachments — scanned reports, uploaded images, signed consent forms — come with it, and in what folder structure
• Whether the export is a one-time file or something you can re-run if the first one is wrong
• The charge, if any, and whether it is in your existing contract
• The date they will deliver it

That last one matters more than the rest. An export promised “after go-live” arrives after your leverage is gone.

The things people forget to ask for

The database is the obvious ask. These are the ones that get remembered three weeks too late:

• The document templates. Your prescription layout, your bill format, your discharge paperwork and your report headers were configured once, by somebody, over several weeks. Ask for copies even if the new system cannot import them, because rebuilding from a sample is far quicker than rebuilding from memory.
• The report definitions. Every hospital has three or four reports the owner actually reads. Print the last twelve months of each one before the system goes dark. You will need them to prove the new system agrees with the old.
• The user list with roles. Who had access to what is both a security question and a configuration shortcut.
• Open items. Unsettled bills, pending insurance files, advances held against future treatment, credit notes. These are liabilities and receivables, not history.
• Any integration credentials your hospital paid for. Portal logins, gateway merchant identifiers, machine interface configurations.

Put a date on it, then put it in the new contract

Whatever you learn here, write into your next agreement before you sign it. An exit clause costs nothing at signature and is unbuyable at exit. Three sentences are enough: the data belongs to the hospital, an export in a named machine-readable format is available on request within a stated number of days, and the charge for it is either zero or a number written down today. The vendor’s answer to that request tells you a great deal about the vendor.

What actually breaks

Patient identity

Two systems rarely number patients the same way. The old one may use a per-year series, the new one a permanent identifier; one may store a single “name” field where the other wants name parts; phone numbers arrive with country codes, without them, and occasionally with two numbers in one field.

Decide before the import, not during it:

• Whether old registration numbers are preserved, mapped, or printed on the card alongside the new one
• What happens to the duplicates you already have — the same patient registered three times under three spellings is in every hospital database on earth
• Which field is the match key when you merge: phone number is usually the only honest one

Print the old identifier somewhere visible in the new record for the first year. The desk will thank you every time an old file comes back.

The money record

This is the part to be slow and careful about. Receipt and invoice numbering must continue without repeating a number and without skipping a block, because both are hard to explain later. Decide where the new series starts, record the last number issued by the old system on the day you stop, and keep that note.

Outstanding balances have to be reconciled by a human, not trusted to an import. Pull the closing receivables from the old system, pull the opening receivables from the new one, and sit with the difference until it is zero or explained. Do this on day one. A gap found in month three cannot be traced.

Also settle the tax setup deliberately rather than inheriting it. Core healthcare services and the lines that sit outside them are treated differently, and a migrated tax configuration that nobody re-checked is a quiet problem that surfaces at filing time.

Master data

Masters are the unglamorous part and the usual cause of a bad first week:

• Doctors — names, specialities, consulting days, fee structures, revenue-share rules
• Services and tariffs — often several price lists for cash, corporate and scheme patients
• Items — drug and consumable catalogues with their pack sizes and units
• Rooms and rates, where you have them
• Discount and approval rules — who is allowed to reduce a bill, and by how much

Every one of these is a decision somebody made years ago and nobody wrote down. Budget real time for rebuilding them, and treat the migration as a chance to delete the ones that have been dead for years rather than carrying them across.

Reports that no longer reconcile

Your new system will count something differently from your old one. It will define a “visit” differently, or date revenue on a different event, or include cancelled bills where the old one excluded them. This is normal, and it panics owners who were not warned.

The defence is the printout you took earlier. Run the same three reports in both systems for the same period, compare, and write down every difference and its cause. Once you have that page, the new numbers are trustworthy. Without it, you will spend a year unsure.

Anything plugged into the old system

Integrations do not migrate. They are rebuilt. Make the list before you switch: laboratory analysers and the machine that talks to them, imaging and image storage, payment terminals and gateways, SMS or WhatsApp senders, accounting software, government and insurance portals, and any custom report somebody built for you.

For each one, write down who owns it, who supports it, and how long a rebuild takes. The answer to the last question is usually “longer than the software vendor said”.

The desk

The largest cost of a switch is not technical. It is four weeks of a receptionist who was fast being slow, in front of patients, while a queue forms. That cost is real whichever system you pick, and it is the one that decides whether staff talk about the new software warmly or bitterly a year later.

Reduce it by training on your own data rather than demo data, by going live on a quieter day of the week, and by having one person in the building on day one whose only job is to stand at the desk and unblock people.

What to keep, and what to leave

A useful way to split it:

Keep live, inside the new system — patient identity and contact details, outstanding balances and advances, the active master data, anything a patient might reasonably expect you to know when they walk in tomorrow.

Keep readable, in an archive — full clinical history, old bills, old reports. A read-only copy of the old database, or a well-organised set of exports on storage you control, with someone named as responsible for it. Test that you can actually retrieve one patient’s history from it before the old system is switched off. An archive nobody has ever read is not an archive.

Leave behind — dead doctors and services, tariffs that have not been used in years, duplicate patient records you have been meaning to merge, workflow habits that only existed because the old software forced them.

One thing that is not yours to decide on convenience alone: how long the records have to be kept. Retention duties come from medical-record regulation and from the clinical establishment rules in your state, and they do not lapse because you changed vendors. Check the text that applies to you before you agree a date on which the old vendor deletes anything. Separately, the Digital Personal Data Protection Act, 2023 sets out duties for whoever is handling personal data on your behalf — worth reading before you sign with anyone new, not after.

The case for not migrating at all

For a hospital whose work is mostly outpatient, starting fresh is a legitimate strategy rather than a failure. The record that matters is the one created at the patient’s next visit. You go live in weeks instead of months, you inherit none of the duplicates, and the old data sits in an archive you can search when you genuinely need it.

We take that position ourselves. Arko Care hospitals start fresh: we configure the doctors, their fees and consulting days, the hospital’s logo, letterhead and web address, then train the desk. Patients are registered on their first visit, so there is no bulk import holding up go-live. It suits an outpatient-led hospital and it does not suit everyone — if your value is locked in years of inpatient history, say so early and make the vendor answer for it.

Running the cutover

Pick a quiet date and freeze. A weekday with a lighter clinic, not a Monday. Announce a freeze on master data changes in the old system a week ahead, so the export you tested against is the export you import.

Take the final export on the day, not in advance. A migration rehearsed on last month’s data and executed on last month’s data loses a month.

Keep the old system readable, not running. Parallel data entry for a month sounds prudent and is usually a mistake: it doubles the desk’s work and produces two records that disagree. Read-only access for lookups is what people actually need.

Reconcile on day one. Receivables, the last receipt number, patient count, today’s collection by payment mode. Four numbers, checked the first evening, against the old system’s closing position.

Book the second week. Almost everything that goes wrong shows up between day four and day ten, once the easy cases are done and the first unusual one arrives. Make sure the vendor who sold you the system is still contactable then, by name.

The clauses to put in your next contract

Learn from the exit you just went through, and write it into the next agreement:

• The hospital owns its data, said plainly
• A machine-readable export on request, in a named format, within a named number of days, at a named charge
• What happens to your data after termination, and when it is deleted
• Where the data is stored, and in which country
• Who at the vendor is accountable during go-live, by name
• What is included in the quoted number and what is billed separately — migration, training, customisation, integrations, renewals

If you are early in this and still choosing, the companion piece to this one is what to ask a vendor in a hospital software demo, which is about the hour in the room rather than the exit. For the wider evaluation — modules, support, scale — see how to choose hospital management software. If the acronyms in your vendor’s proposal are doing the work, start instead with HMS, HIS, EMR, EHR: what the terms mean.

Arko Care is an AI-native, white-label hospital management system for Indian hospitals: your name, your logo and your own web address on every screen, prescription and bill. If you are weighing a change, book a demo and ask us the exit questions above about our own system first.