An HMS migration does not begin when a vendor imports a database. It begins when the hospital decides what must still work at 9:00 on the first morning after cutover.
Registration must find the right patient. The ward must see current admissions. Billing must carry the correct balances. Pharmacy and stores need trustworthy stock. Clinicians need the records required for safe continuity of care. Those are separate acceptance tests, not one technical milestone called “data migrated.”
This guide turns an HMS switch into a controlled hospital programme. It does not prescribe a fixed timeline because source systems, data quality, integrations, and facility scope differ.
Start with a migration charter, not a feature list
Write one page before anyone maps a field. It should name the executive owner, clinical safety owner, privacy owner, finance owner, technical lead, and vendor lead. It should also state:
- which facilities and departments are in scope;
- which system is authoritative before, during, and after cutover;
- which workflows cannot tolerate an outage;
- what success looks like for patient identity, clinical access, billing, and inventory;
- who can approve cutover, pause it, or order a rollback.
The National Informatics Centre’s eHospital service illustrates why module boundaries matter. Its official service describes functions including patient registration, admissions, billing, pharmacy, laboratory, and blood bank. A hospital may use a different product and module set, but the migration still has to follow the real departmental handoffs rather than a vendor’s umbrella label.
Build a data decision register
“Move everything” sounds safe. It usually hides hard choices. A better register assigns every data group one of three outcomes: migrate into the live system, retain in an accessible archive, or dispose of it only under an approved retention and legal process.
| Data group | Questions to settle before extraction | Practical acceptance evidence |
|---|---|---|
| Patient identity | How are duplicates, aliases, old identifiers, and deceased patients handled? | Sample matches reviewed; duplicate rules signed off |
| Encounters and clinical records | Which notes, diagnoses, allergies, orders, results, and documents remain clinically necessary? | Clinician can trace a selected patient journey |
| Admissions and beds | Which current admissions and transfers must be live at cutover? | Ward census reconciles to the source |
| Billing and receivables | Which open balances, deposits, refunds, and payer references move? | Finance totals and patient-level samples reconcile |
| Pharmacy and inventory | Which item masters, batches, expiries, and opening stock are authoritative? | Store totals and selected batches match physical checks |
| Users and permissions | Who needs access, at which facility, and with which role? | Joiner, mover, leaver, and privileged-access tests pass |
| Audit and consent records | What must remain searchable, attributable, and exportable? | Retrieval test succeeds with timestamps and actor context |
Keep the register versioned. If the decision for an old document changes from “archive” to “migrate,” the change should name an owner and a reason.
Clean identity before moving history
Patient matching is not a cosmetic cleanup. A duplicate can split a clinical history; a false merge can place one person’s information in another person’s record.
Profile the source first. Count empty identifiers, duplicate mobile numbers, reused local IDs, malformed dates, and records that disagree across systems. Then define deterministic matching rules and a queue for human review. Do not let a vendor silently resolve uncertain matches through a broad fuzzy rule.
Use synthetic or properly controlled test data during early rehearsals. When personal data is used, apply the hospital’s approved access, purpose, retention, and security controls. The Digital Personal Data Protection Act, 2023 establishes duties around processing digital personal data; it does not turn a software purchase into automatic compliance. Hospitals should obtain legal and privacy guidance for their circumstances.
Rehearse the migration at least as a full workflow
A technically successful import can still fail at the counter. Rehearsal must include users following work from start to finish.
One useful sequence is:
- Freeze a source snapshot and record its timestamp.
- Extract and transform it with logged rules.
- Load it into a production-like target environment.
- Reconcile totals, exceptions, and selected patient records.
- Ask departmental users to complete scripted workflows.
- Log every defect, assign an owner, and rerun the affected test.
- Measure the final-delta load that cutover will require.
Test awkward cases on purpose: an inpatient with an outstanding bill, a patient with two old identifiers, a returned pharmacy item, a corrected lab result, and a staff member whose role changed. These cases expose handoff errors that happy-path demonstrations miss.
Set cutover gates that anyone can read
A go-live meeting needs facts, not confidence. Use a short gate sheet with a named approver for each line.
- Critical data reconciliations are within the hospital’s approved tolerance, with every exception documented.
- Current admissions, urgent patient lists, and essential clinical history are available.
- Registration, admission, discharge, billing, pharmacy, and other in-scope workflows pass.
- Interfaces and devices have passed end-to-end tests, or a documented manual fallback exists.
- Role-based access and privileged accounts have been reviewed.
- Backups, restore evidence, downtime forms, escalation contacts, and rollback criteria are ready.
- Staff know which system is authoritative and where to report a problem.
“The database loaded” is evidence for one line of a much larger decision.
Keep parallel running narrow
Some hospitals compare critical outputs in both systems for a limited period. That can catch mapping problems. It can also produce contradictory balances, duplicate orders, and exhausted staff.
If parallel checks are required, name the authoritative system per workflow and restrict the comparison to defined outputs. For example, finance may reconcile a daily total while clinicians document only in the new record. Set an end date. Once the old HMS becomes read-only, verify that authorised staff can still retrieve retained history.
Plan rollback around transactions, not servers
A server snapshot is useful, but it does not explain what happens to registrations, payments, orders, or notes created after go-live. The rollback plan should answer four questions:
- What condition triggers the decision?
- Who makes it, and by what deadline?
- How are post-cutover transactions exported and reconciled?
- How will staff and patients be told which system is authoritative?
Run a tabletop exercise. If the team cannot explain how a payment entered at 10:15 would survive a rollback at 11:00, the plan is incomplete.
Treat interoperability claims as test cases
ABDM is not a checkbox to inherit from a sales deck. The ABDM Health Data Management Policy describes a consent-oriented framework for health data exchange. A buyer should ask what specific capability exists today, which environment it works in, what evidence can be demonstrated, and which party operates each workflow.
Patient Square’s ABDM integration is on the roadmap. We do not present the product as ABDM-certified or as having completed an ABDM milestone. Verify current product status during procurement.
Use the same discipline for every integration. Ask the vendor to demonstrate a real registration, result, billing, or record-retrieval path in the quoted configuration. A logo on a slide is not an acceptance test.
Demand an exit package before signing
The best time to negotiate the next migration is before this one begins. Put export scope, format, attachments, code sets, audit data, fees, assistance, deletion, and turnaround terms into the contract.
Ask for a sample export and have someone other than the vendor open it. A large file is not necessarily a usable record. The hospital should be able to identify a patient, reconstruct important history, and reconcile balances without a proprietary viewer that disappears with the contract.
A practical first conversation
Bring three artefacts to the vendor: the migration charter, the data decision register, and ten workflow tests. Ask the vendor to mark what is standard, configurable, custom, or unsupported. Then price the gaps and attach responsibilities to the statement of work.
Patient Square Hospital Copilot can be evaluated in either of two configurations: alongside an incumbent hospital system, or, where the quoted scope fits, with the complete Patient Square HIS/EHR. The discovery session should confirm the actual modules, interfaces, data work, and support required. Do not infer unlisted hospital capabilities from the Copilot name.