Case study · August 20, 2026

EMR Migration With Zero Data Loss

Toronto specialty hospital migrates legacy EMR to Epic

The client

A specialty inpatient and outpatient hospital in Toronto, serving a client base of roughly 3,000 patients across a dozen inpatient beds and a broader outpatient practice.

The challenge

The hospital ran on Bcare, a legacy EMR nearing end of practical life, and needed to move to Epic. A decade-plus of clinical history - encounters, orders, results, scanned documents, and free-text clinical notes - had to move with zero tolerance for lost or misattributed patient data. Bcare’s export was its own proprietary shape, nothing close to a standard clinical data format, and Epic expects data in its own structured ingestion format on the other end. A migration of this scope is typically staffed with three to four engineers plus a project manager.

The approach

We ran the migration as a single engineer, end to end.

Managing a common format between two systems that don’t speak the same language: Bcare’s export didn’t map field-for-field onto anything Epic could ingest, and a direct translation from one proprietary shape to another leaves no independent way to check the mapping itself is correct. The fix was a custom intermediate schema, built along the same logic as HL7v2 message segments: patient identifiers, encounters, orders, results, and documents each normalized into their own canonical structure before any of it touched Epic’s side. Every record had one unambiguous shape to be validated against, independent of either system’s own quirks, which is what made the later reconciliation step trustworthy rather than a formality.

Patient confidentiality was held throughout: Every patient record that moved through the migration was protected health information, and it stayed inside a controlled environment for the full length of the project. No record was sent to an external parsing service, no cloud OCR or generic document-extraction tool touched a scanned chart, and access was limited to what the migration itself required. The custom parsers below existed for this reason as much as for accuracy: a generic third-party import tool means handing PHI to a system nobody on the hospital’s side can fully audit.

Custom parsers were created because there were no off-the-shelf tools: Scanned documents, attachments, and free-text clinical notes needed parsers built specifically for this migration, rather than generic import tooling that places data without verifying it belongs where it lands. Parsers also had to be created for the custom Hl7 format the target system used.

Reconciliation against the live source system, not just against the migration plan. Sampling charts and comparing what a clinician could see in Bcare against what appeared in Epic, record by record, against the canonical intermediate outputs as the reference point.

A versioned, re-runnable migration pipeline. Issues found during reconciliation were fixed with a code change and a re-run, not a manual patch under deadline pressure. We stuck to a proper CI/CD pipeline for code changes and merges since for something as complex as an EPIC transition, we needed to ensure the code was versioned for specific data versions.

The outcome

No material data elements were lost. Every patient record, document, and clinical note carried over with its link to the correct patient and encounter intact, and no patient data left the hospital’s controlled environment at any point in the process. The hospital avoided the cost and coordination overhead of a multi-engineer migration team, while maintaining continuity of care documentation and full confidentiality throughout the transition.

Read the underlying methodology in What Actually Breaks in an EMR Migration.