Search “EHR data migration checklist”, and you’ll find a few dozen versions of the same article. Twelve to fifteen items, organized around a generic project lifecycle, are useful as a starting point and not much more. The items aren’t wrong, but they rarely reflect what actually breaks down in an enterprise migration.
A good checklist for an EHR migration captures the decisions, audits, and confirmations that have to happen in a defined order, owned by named people, and signed off before specific gates. The checklist that protects a project surfaces the questions someone forgot to ask three months ago, while there is still time to answer them.
This checklist is built around the eight-phase framework described in our EHR Data Migration: The Enterprise Guide, but organized for how project teams actually use it: four phases that map to the chronological work of pre-migration planning, data discovery, mapping and validation, and go-live with post-cutover monitoring. A consolidated PDF version is available for download at the end if you would rather print it or share it with your project team.
How to Use This Checklist
This checklist works for organizations of different sizes, but how it gets used varies. A small ambulatory group running a single-instance migration may complete each section in a few weeks. An enterprise health system consolidating multiple acquired sites can spend months on Section 1 alone. The work doesn’t change. The timeline does.
Each section assumes a defined owner. Pre-migration planning typically belongs to the executive sponsor, often the CIO or CMIO. Data discovery sits with the IT integration lead in coordination with clinical informatics. Mapping and validation cross both groups, with clinical leadership signing off on what counts as acceptable. Go-live and post-cutover belong to the project director, with help desk, finance, and compliance leadership participating closely in the immediate post-cutover weeks.
Section 1: Pre-Migration Strategic Planning Checklist
Executive Sponsorship and Project Governance
This is where the project’s authority structure gets set. The migrations that struggle later are usually the ones where this section was treated as administrative paperwork rather than the architecture for everything that follows.
- Executive sponsor named in writing, with documented budget authority and escalation power
- Clinical, technical, and operational leads named, with explicit time commitments to the project
- Governance committee defined, including meeting cadence, decision rights, and escalation paths
- If no one on staff has run an enterprise EHR migration before, an external advisor or migration partner is engaged early, not at the point where the project is already in trouble
Scope Definition and Documentation
The cost of getting the scope wrong is paid in months, not weeks. Every item below should be settled in writing before the project moves into discovery work.
- Source and destination EHR platforms documented, including the version
- Sites, departments, and specialities in scope vs. out of scope
- Historical data depth decisions made in principle: migrate, archive, or retire
- Custom-build conversion approach defined per element. The three options are convert in place, redesign for the destination platform, or retire. Each choice needs documented rationale, not a default selection.
- Integration footprint understood at the category level (HL7, FHIR, HIE, e-prescribing, registries)
Go-Live Readiness Criteria
These criteria need to be written before the timeline is locked. Once the schedule is set, anything not already documented gets renegotiated under pressure.
- Readiness criteria documented per data category, with validation tolerance levels
- Clinical sign-off authority identified for each criterion
- Specific go/no-go decision points named, with the decision-makers for each
- Rollback plan defined for the case where go-live cannot proceed
- Communication plan to clinicians prepared, covering what changes and what doesn’t
Initial Compliance and Risk Assessment
Treating compliance as an end-of-project checkpoint is one of the more common project missteps. The audit work that gets done in this phase either protects or exposes the organization for the next 9-18 months.
- HIPAA gap analysis completed against current source system controls
- Business Associate Agreement scope drafted for the migration partner
- Information blocking analysis initiated under the 21st Century Cures Act
- State-specific requirements documented (42 CFR Part 2, behavioral health, minor consent, HIV)
- Initial risk register established, with named owners per risk
Section 2: Data Discovery and Audit Checklist
Source System Inventory
The audit phase exists to turn assumptions into documented reality. Most projects underestimate this work because they trust the existing source system documentation, which in a mature EHR environment is rarely complete.
- Complete data volume baseline by category (structured clinical, unstructured, financial, audit logs)
- Custom build inventory: order sets, smart phrases, decision support rules, reporting workbench reports, custom forms, specialty templates
- Historical data depth documented year by year
- Source system data dictionary reviewed and validated against actual production data
- Interview the system administrators and original implementation staff (where they’re still around). Their tacit knowledge of the source environment is rarely captured in the formal documentation.
Integration Footprint Mapping
The integration audit usually surfaces interfaces nobody knew existed. Skipping it is what creates the post-cutover surprise where reports stop flowing, and nobody can explain what the interface was actually doing.
- Every active HL7 v2 interface documented: direction, format, frequency, external owner
- Every FHIR endpoint documented, including patient-facing app dependencies
- HIE participation confirmed and connection status verified (Carequality, CommonWell, regional HIEs)
- E-prescribing, lab, radiology, device, and telehealth integrations documented
- Quality reporting registry connections documented, including CMS, MIPS, and speciality boards
Data Quality and MPI Audit
The data quality work has to happen before mapping begins. Migrating dirty data into a clean destination just moves the problem with extra cost.
- Duplicate patient records identified, flagged, and queued for clinical review. Algorithmic merge alone tends to create new problems faster than it resolves old ones.
- Provider records audited for accuracy and active status
- Insurance and contract records reconciled against current payer relationships
- Problem list, medication list, and allergy data quality reviewed for known issues
- Data convention inconsistencies across acquired sites are documented for harmonization
Historical Data Scope Decisions
These decisions narrow as the project progresses. Making them now keeps the technical scope from spiraling later when fewer options remain.
- Migrate vs. archive vs. retire decision documented per data category
- Archival vendor evaluated if any data is archiving rather than migrating
- Audit log retention strategy confirmed for HIPAA compliance
- Retention requirements documented per applicable regulation (state, specialty, federal)
- Legacy system decommissioning timeline drafted
Section 3: Mapping, Cleansing, and Validation Checklist
Field and Semantic Mapping Documentation
Field mapping is technically intensive, but the harder work is semantic. A code that means one thing in the source system has to mean the same thing in the destination, and the rules vary by data category and destination platform.
- Field-level mapping is documented for every structured data type in scope
- Semantic mapping rules documented (ICD-10-CM to SNOMED CT, source-specific codes to destination equivalents)
- USCDI standards compliance confirmed for destination data structures
- Custom build mapping decisions documented per element: convert, redesign, or retire
- C-CDA document handling is defined for the portions of the historical record that need it
Test Environment and Test Migration
The test phase is where most of the surprises that would have surfaced at go-live can be caught instead. Compressing it under timeline pressure is among the higher-risk decisions a project can make.
- Test environment provisioned, mirroring production access controls and integrations
- Test data set defined. The choice between a representative sample and a full production clone depends on the validation rigor required; production clones cost more but catch issues that representative samples miss.
- Test migration executed end-to-end before production migration is scheduled
- Test results documented against the validation criteria established in Section 1
- Mapping gaps identified and resolved before production migration scheduling
Validation Criteria and Sign-Off
Validation that confirms data is present in the destination is necessary but not sufficient. Effective validation confirms the data behaves correctly in real workflows: that allergy alerts fire, medications reconcile properly, and order sets execute the way clinicians used them last week.
- Clinical end-users identified for workflow validation: physicians, nurses, MAs, billing staff
- Validation scenarios written for each major specialty and workflow type
- Parallel testing window defined, during which source and destination both operate
- Sign-off authority documented per data category, captured in writing
- AI-assisted validation tooling configured if used in the project
- Failure thresholds set per category. Patient safety data carries zero tolerance. Reporting data can carry more. Each threshold has an escalation path that doesn’t require interpretation in the moment.
- Re-validation process defined for any failed test scenarios
Section 4: Go-Live and Post-Cutover Checklist
Cutover Window Preparation
The cutover window is where coordination either holds or fails. Communication gaps in the 72 hours before cutover create issues that take weeks to recover from.
- Cutover date and window finalized, with read-only periods and downtime fully defined
- Communication to all clinical and administrative users at 30 days, 14 days, 7 days, and 24 hours pre-cutover
- Manual workflow procedures documented and distributed for the downtime window
- Final data sync executed and confirmed against the cutover plan
- Cutover command center staffed with named representatives from IT, clinical, revenue cycle, and compliance
Day 1 Through Day 7 Monitoring
The first week sets the trajectory for the rest of the recovery period. Issues that surface here either get resolved while the project team is fully engaged or roll forward as operational debt.
- Help desk staffed at three to five times normal coverage for the first 72 hours. Anything less and the team absorbing the spike loses the capacity to actually resolve the issues that come in
- Daily claim rejection report run against the pre-migration baseline starting Day 1
- Clinician workflow exception reports are collected daily
- Integration health checks executed daily across all external connections
- Daily project status meeting with the executive sponsor through Day 7
- Open issues spreadsheet maintained with resolution status and owner per item
30/60/90-Day Reconciliation
The reconciliation cadence is what catches the slower problems. Some issues do not surface until claims complete their full adjudication cycle or quality reporting periods close.
- Day 30: AR aging review against pre-migration baseline, integration audit, clinician feedback survey
- Day 60: Quality reporting submission validation, custom build adjustment review, post-cutover cost review
- Day 90: Full data integrity audit, full integration audit, formal project retrospective
- Post-cutover support ramp-down plan executed against actual ticket volume rather than projected
Legacy System Decommissioning
Decommissioning is the final closeout, and the gating items here protect the organization from compliance exposure after the source system is no longer accessible.
- Retention windows confirmed for all data categories before decommissioning
- All HIE connections, registry submissions, and external interfaces confirmed functional on the new platform
- Read-only access to the legacy system is kept available for a defined retrieval period. Audit requests, payer disputes, and litigation holds all surface months after cutover, sometimes more than a year after.
- Decommissioning approved by the executive sponsor, compliance, and IT leadership in writing
- Source system data backup is retained according to the documented retention plan
Frequently Asked Questions
When in the project should the checklist start being used?
The earliest items begin during executive sponsorship and budget approval, often before the destination EHR has been selected. Most of Section 1 should be complete before contract signature with the destination vendor. By the time the project is six months out from go-live, Sections 1 and 2 should be largely complete and Sections 3 and 4 should be actively in progress.
Who owns the EHR migration checklist?
Ownership shifts by section. Section 1 is owned by the executive sponsor, typically the CIO or CMIO. Section 2 belongs to the IT integration lead with clinical informatics support. Section 3 is jointly owned by the technical migration team and clinical leadership. Section 4 sits with the project director. A single document custodian, often the PMO, maintains the checklist as the source of truth across all sections.
What is the most commonly skipped item on an EHR data migration checklist?
The integration audit in Section 2. Project teams trust the existing integration documentation, which, in a mature EHR environment, is rarely up to date. Interfaces configured years ago by people who have since left the organization tend to surface during cutover, when something stops flowing, and nobody can quite explain what the interface was actually doing.
How does the checklist change for M&A consolidation migrations?
The structure stays the same, but Section 1 doubles in complexity. Two organizations' data conventions, custom builds, and clinical practices have to be harmonized before mapping can begin. The most common pattern: the consolidation gets scoped around the M&A integration calendar rather than the data readiness calendar, and the checklist items in Sections 1 and 2 get pushed into a parallel track that runs against the technical migration timeline rather than ahead of it.
How long does an EHR data migration take with Infowerks?
Project duration depends on the source environment, the integration footprint, and the historical data scope. A relatively clean single-instance migration with disciplined scope typically completes in three to six months from data discovery through go-live. Enterprise migrations with significant custom build conversion, multi-site consolidation, or complex integration footprints commonly run nine to eighteen months. Initial scoping conversations with Infowerks usually take two to three weeks and produce a defensible timeline and budget against the actual work that needs to happen.
What does an Infowerks EHR data migration engagement include?
A full Infowerks engagement covers the work from data discovery through post-cutover stabilization. That includes source environment audit, integration mapping, data quality assessment, MPI reconciliation, field and semantic mapping, test migration execution, parallel testing support, go-live execution, and 30/60/90-day post-cutover monitoring. Each engagement is scoped against the specific source and destination platforms, the data categories in scope, and the organizational complexity. The work is reviewed and signed off against documented validation criteria rather than against project milestones alone.
In Conclusion: What a Good Checklist Actually Does
A checklist is not a guarantee. It is a structured way to surface the questions a project would otherwise miss. The items above will not catch every issue that could appear in your specific environment, and they cannot substitute for the operational judgment of a team that has run enterprise EHR migrations before.
What a good checklist does is force the conversations that need to happen, on the schedule they need to happen on. The risk register gets written before the schedule locks in. The integration audit precedes mapping rather than running parallel to it. Validation criteria are signed off before the test migration runs. None of that is new work created by the checklist itself. What the checklist changes is the timing, whether each item happens while there’s still room to address it well or after the consequences have already started showing up.
Looking for an EHR Data Migration Partner?
Infowerks works with healthcare organizations on enterprise EHR data migration with a focus on clinical accuracy, integration continuity, and post-cutover stability. Our methodology covers every section of this checklist, from initial source environment audit through 30/60/90-day post-cutover monitoring. If you’re scoping a migration and want to talk through what the work would look like in your specific environment, we’d be glad to discuss the project.
Download the PDF version of this checklist to share with your project team, or contact Infowerks to discuss your EHR data migration directly.
This article was written by Shristi Patni and reviewed by Jeff Deitch, CEO and Co-Founder of Infowerks Data Services, with nearly 35 years of experience in healthcare data interoperability.
