Begin with an honest inventory
List every place data lives today: the current hospital information system, laboratory and pharmacy applications, accounting packages, spreadsheets maintained by individual departments, and the paper archives that staff will still need to reference long after go-live.
For each source, name two people — the owner who is accountable for the data and the person who understands its quirks, such as which columns are reliable and which are completed only when someone remembers. Knowledge of that kind sits with individuals, not with the system.
A written inventory prevents the classic surprise: weeks after go-live, someone recalls a register that was never in scope, and reception has no way to look up an old reference number for a returning patient.
Decide what moves, what stays and what is archived
Not everything should cross. Active patient records, live inventory, outstanding invoices and current staff files must be usable on day one. Completed episodes from years ago may be better handled as a read-only reference or a separate export than as live rows in a new system.
Let retention policy and internal agreement drive the decision. Agree the cut-off with clinical, finance and administrative leads before any extraction begins, because moving less data is almost always faster, cleaner and easier to verify than moving all of it.
Write the decision down. A migration in which the scope is left to be settled during the run becomes a migration with an argument at two in the morning, when nobody is at their best and every option looks worse than the last.
Cleanse before you extract
Duplicates, inconsistent codes, mismatched unit conventions and free-text entries where a structured value belongs are the usual offenders. Cleansing is unglamorous work and is very often the longest part of the whole project, so plan it early rather than treating it as a final polish.
Clean at the source, not in the target. Correcting a duplicate in the old system is visible to the team who owns the data and can confirm the fix; correcting it inside a transformation script is invisible, hard to review and easy to repeat wrongly on the next run.
Agree a small set of rules first — how patients are matched, how items are coded, how missing values are treated — and apply them consistently. Perfect data is not the goal. Data the new system can read and the departments can trust is the goal.
Map fields deliberately
A field map documents where every important value in the old system lands in the new one, including how codes, statuses and dates are converted. It is a working document that analysts, department leads and the implementation team all review and sign off.
Expect the awkward cases: a status that exists in the old system with no equivalent, a combined field that must be split in two, a date stored as free text. Decide each one explicitly and record the decision, rather than letting a default quietly choose for you.
Validate the map against real extracts from every source rather than tidy sample files. Sample data is well behaved by construction; production data carries a decade of exceptions, and those exceptions are exactly what the map has to survive.
Rehearse the cutover
Run the full migration end to end at least once before the live window, at real volume, and time every stage. A rehearsal converts guesses about duration into a schedule with named owners, which is the difference between a planned evening and an anxious one.
Plan the downtime window in operational terms: what the front desk tells patients, which processes run on paper, who authorises exceptions, and when the paper work is entered afterwards. Technical readiness without a front-line script still stops the hospital.
Keep a stated rollback position — the point at which the decision is made to return to the old system — and agree it in advance. Teams that never discuss rollback end up improvising it under pressure, which is precisely when improvisation costs the most.
Validate with the people who use the data
Technical reconciliation confirms counts and totals; only department users can confirm meaning. Give registration, pharmacy, laboratory and finance each a short checklist of records they already know well and can verify quickly against what they remember.
Bring super users in from the mapping stage rather than introducing them at go-live. They carry credibility back to their own teams, catch errors the project team cannot see, and become the people their colleagues ask before raising a support ticket.
Log every discrepancy with an owner and a date. A short, visible issue list that shrinks each day is far more useful than a general assurance that the numbers appear to match.
The weeks after go-live
Keep the old system available in read-only form for a defined period, so staff can confirm history that was deliberately left behind or that failed to migrate. Confidence in the new system grows when yesterday's records can still be checked in seconds.
Expect a burst of questions in the first days and staff it deliberately with people who know the answers. Leaving an unprepared helpdesk to guess during week one costs goodwill that takes months to rebuild.
Review the issue log weekly and look for patterns rather than treating each item separately. Repeated questions usually point to a workflow or a report that needs adjusting, and are a better signal for change than another round of generic training.