From Tally, Excel and a legacy HMS to one unified ERP — phased department by department, with no big-bang cutover.
A migration that skips the readiness audit, skips the parallel run, or trains only the day shift doesn't fail on launch day — it fails two weeks later, when discrepancies nobody caught during testing start showing up in real bills and real medication records. This is a service built around avoiding that, not a generic project-management template borrowed from a different industry.
Most implementation guides written for the Indian hospital market assume broadband, a full-time IT department, and staff who are already comfortable with software. None of that describes a typical tier-2/3 hospital running on a shared 2 Mbps connection with one part-time IT contact and a billing clerk whose only prior software experience is Tally. This page describes the process built for that hospital, not the one written for a 500-bed metro chain.
Map every current system, identify duplicate and dead data, baseline actual connection speed, name a project owner on the hospital side.
Extract, clean and map patient, pharmacy, accounts and HR data. Run old and new systems side by side for one full billing cycle before cutover.
Staff trained on their own screens, in Hindi plus the regional language, on their own devices, in short repeated sessions during shift hours.
OPD registration first, then billing, then pharmacy, then IPD, then back-office — never all departments on the same day.
Old system kept read-only accessible, daily KPI tracking, fast support response, next department only after the current one is stable.
The audit isn't a formality before the "real work" starts — it's where most of the risk in the entire project gets identified and removed. Concretely, it produces four things: a data map showing which system is the source of truth for each data type, a duplicate and dead-data count across patients and stock, a connectivity baseline measured at each terminal rather than assumed from the ISP's advertised speed, and a named project owner on the hospital's staff, not a vendor contact standing in for one. Implementations that skip a named owner consistently run longer, because decisions that should take a day instead wait for "someone" to confirm them.
| Migrate into live ERP | Archive (read-only reference) |
|---|---|
| Active IPD/OPD patients | Discharged records older than the hospital's active-recall window |
| Current pharmacy stock & drug master | Closed purchase orders from prior years |
| Opening account balances | Historical ledger detail beyond the current fiscal year |
| Active employee & payroll master | Exited-employee records, retained per statutory retention period |
| Existing ABHA linkages captured so far | — |
The parallel run matters more than the migration script itself. Running the new ERP and the old system side by side for one full billing cycle, reconciling totals daily, is where migration errors surface — before they touch a live patient bill instead of after. ABDM consent capture should be built into this phase directly: as records are migrated or re-registered, capture ABHA linkage and consent at that point rather than retrofitting it hospital-wide once the system is already live. For the regulatory detail behind why this sequencing matters, see our guide to ABDM/ABHA hospital integration.
The order — OPD registration, then billing, then pharmacy, then IPD, then back-office — isn't arbitrary. Registration is lowest-risk and highest-visibility, a good place to catch interface friction early without touching money or medication. Billing comes next once registration is stable and tax-invoice logic has been verified against real bills. Pharmacy has to be accurate before IPD medication administration depends on it. IPD and nursing carry the highest patient-safety stakes and go live only once everything upstream is proven stable. HR, payroll and accounts back-office carry the lowest patient-facing risk and can safely run last, even though they're often the departments most eager to switch first.
The first two weeks after any department goes live are when latent migration and configuration issues surface, not before. The old system stays accessible read-only during this window, support response times stay short, and a small set of KPIs gets tracked daily: registration time per patient, bill-generation errors, failed ABHA linkage attempts, staff-reported blockers. The next department in the sequence doesn't move until the current one has run quiet for at least five consecutive working days. Once this window closes cleanly, stabilisation transitions into ongoing AMC and managed support, ideally with the same team that ran the implementation.
Most of these patterns share a root cause: treating implementation as a deadline-driven project rather than a phase-gated one. A deadline-driven rollout moves to the next step because the calendar says to. A phase-gated rollout moves to the next step because the previous one is verifiably stable — which is slower on paper and considerably faster in practice, since it avoids the multi-week cleanup that follows a premature go-live.
| Hospital size | Elapsed time |
|---|---|
| Under 50 beds, single specialty | 6-10 weeks |
| 50-150 beds, multi-specialty | 10-16 weeks |
| 150+ beds or multi-location | 16+ weeks, phased by location |
Three factors move a hospital toward the longer end of its range regardless of bed count: the number of legacy systems being replaced simultaneously (a hospital walking away from four disconnected tools takes longer than one replacing a single HMS), the state of the existing data (a hospital with years of duplicate, un-cleaned patient records needs a longer Phase 1), and whether the hospital already has PMJAY, CGHS or ECHS claim workflows live, which adds a compliance-verification layer to Phase 2 that a purely private-pay hospital doesn't need.
For an illustrative 80-bed multi-specialty hospital replacing a standalone HMS, a separate LIS, and Tally: weeks one and two are the readiness audit and data mapping. Weeks three through seven run data migration alongside the parallel run, with daily reconciliation checks against the outgoing systems. Weeks six through nine overlap role-based training into the tail end of migration, so staff are learning the new screens on real, already-migrated data rather than a sandbox. Week eight begins the staggered go-live with OPD registration, moving through billing, pharmacy and IPD roughly one department every one to two weeks, with back-office last. The 30-day stabilisation window then runs from whenever the final department, usually IPD or back-office, goes live, meaning the hospital's actual "fully live and stable" date lands closer to week fourteen or fifteen than the week-eight go-live start would suggest. This is a normal, well-run timeline, not a delayed one; hospitals that expect the entire process to compress into the go-live week alone are the ones most likely to cut a phase short.
What if we're not ready to leave our current lab system? Migration runs module by module. Registration and billing can move first while the lab system stays untouched until you're ready.
What happens to our historical patient records? Active records migrate in full. Closed/historical records are archived read-only, accessible for reference, per the retention period your hospital already follows.
What do we need to provide? Export access or admin credentials to current systems, one named coordinator for the duration, and a sign-off on a data-cleanup pass before migration starts.
Can we pause the rollout partway through? Yes, since go-live is staggered by department, a hospital can hold at any completed phase for as long as needed before resuming the next one — there's no forced continuous timeline once a department is stable.
| Role | Responsibility during implementation |
|---|---|
| Hospital project owner | Single point of decision-making authority; confirms data accuracy, approves go-live for each department |
| Data migration specialist | Extracts, cleans and maps data from each legacy system into the new schema |
| Training lead | Runs role-based sessions per department, in the languages staff actually use |
| QA / reconciliation | Verifies parallel-run totals match daily during the migration window |
| Support handoff lead | Owns the transition from 30-day stabilisation into standard AMC coverage |
Smaller hospitals sometimes assume this requires a large team standing by full-time. In practice, most of this runs as a phased schedule with the same two or three implementation specialists moving through each stage, coordinated against one hospital-side owner — not a large parallel team occupying hospital premises for months.
Everything in the five-phase process still applies, with one structural difference: each location runs its own staggered go-live sequence rather than all locations moving in lockstep. A hospital group typically picks one location as the pilot site, runs the full five phases there, and only begins the second location's Phase 1 once the pilot site has cleared its 30-day stabilisation window. This means a two-location group should expect a timeline closer to two sequential single-site timelines than one combined project, since the lessons from the pilot site's data-cleanup and training pain points directly shorten the second location's Phase 1 and Phase 3. Attempting all locations simultaneously is the multi-location equivalent of a big-bang go-live, and fails for the same reason: no location becomes a known-good reference point before the others depend on the same assumptions.
Implementation has its own cost, distinct from the licence or subscription fee for the ERP itself, and it's frequently under-budgeted because it doesn't appear on the same invoice as the software. Realistic categories to plan for: data migration effort scaled to the number of legacy systems and record volume, training time (which is staff time taken off normal duties, not just a vendor fee), and a contingency for the data-cleanup pass, which routinely takes longer than hospitals initially estimate once duplicate patient records and dead stock entries are actually counted rather than guessed at. Hospitals that treat implementation as a line item equal in seriousness to the software licence itself consistently have shorter, less disrupted rollouts than those that treat it as a formality bundled into the sale.
Ayushman Bharat Digital Mission, consent and HFR/HPR framework, National Health Authority (abdm.gov.in). NABH 6th Edition Standards, Information Management System (IMS) chapter, National Accreditation Board for Hospitals & Healthcare Providers (nabh.co).
A readiness audit of existing systems, data migration from Tally, Excel and legacy HMS/LIS systems with a parallel-run reconciliation period, role-based staff training, and a staggered department-by-department go-live with a 30-day stabilisation window.
Typically 8 to 16 weeks for a hospital under 150 beds, depending on the number of legacy systems being migrated and department count.
Yes. Accounts opening balances from Tally, HR and payroll data from Excel, and patient, pharmacy and lab records from existing HMS/LIS systems are extracted, cleaned and mapped into the new ERP schema.
No planned downtime. Migration runs with the old and new systems operating in parallel until reconciliation is confirmed, and go-live happens department by department rather than all at once.
A named point of contact from the hospital is required for the duration of the implementation, usually an administrator or senior nurse manager, to confirm data accuracy and coordinate staff training schedules.
Migration runs module by module. Registration and billing can move first while the lab system stays untouched until the hospital is ready.
A cleanup pass runs before migration to remove duplicate patient records and dead stock entries, since migrating dirty data is the leading cause of post-go-live billing and inventory discrepancies.
The 30-day stabilisation window transitions into standard AMC support, ideally with the same team that ran the implementation, since they already understand the hospital's specific configuration.
Tell us your current systems and bed count — get a phased plan back.
Start the Readiness Audit