Switching electronic health record platforms is one of the highest-risk operational projects a small or mid-size medical practice will run, and the part that gets the least attention is the one that determines whether the new system can be trusted on day one: what actually happens to the records that already exist. An EHR data migration checklist matters because most practices treat the go-live date as the finish line, when the accuracy of the data that survives the move is the real measure of success.
Arizona practices switching EHR platforms operate inside a state health-IT landscape shaped by more than a decade of formal health information exchange work — the kind of interoperability groundwork that made statewide, cross-system record sharing a practical reality rather than a slide-deck promise. That history is a useful reminder that data mapping discipline, not vendor marketing, is what actually determines whether a migration succeeds.
Why EHR-to-EHR Migrations Go Wrong
The failure patterns in EHR data migration are well documented and recur across practices of every size. Migrating only partial patient records — omitting historical notes, medication lists, allergies, or lab results — creates gaps in care and can quietly cost a practice missed billing opportunities. Inaccurate data mapping misplaces or loses information outright, and incorrectly converted data, such as medication dosages, is a patient-safety risk, not just an IT inconvenience. Skipping validation steps lets duplicate patient files pile up in the new system. On the operational side, staff routinely struggle with a new system when training is rushed, migrations cause more downtime than planned because cutover activities are underestimated, and projects run over budget because the complexity of the underlying data was never fully scoped before the contract was signed.
Data Mapping Is the Job, Not a Step In It
Rigorous source-to-target mapping is the core technical work of any migration — every field, every allergy list, every medication history, and every lab result has to be mapped correctly from the old system to the new one before it can be trusted. That work goes faster and holds up better when both systems can speak standardized healthcare formats like HL7 and FHIR; the 21st Century Cures Act now requires EHR systems to expose data through FHIR APIs, which gives practices real leverage when negotiating what a migration vendor can and cannot do. Validation should be clinician-led, not IT-led — the people who will actually use the allergy list and medication history are the ones who can tell whether it migrated correctly. And validation belongs before go-live, not after: catching a mapping error once clinicians are already relying on the new system for daily care is a much more expensive and riskier place to find it.
HIPAA Doesn’t Pause for a Migration
Every record touched during a migration is still protected health information, and it stays under HIPAA’s purview from the moment it leaves the old system until it’s confirmed in the new one. That means the HIPAA Security Rule’s administrative, physical, and technical safeguards apply throughout — encryption in transit and at rest, strong access controls, and a complete audit trail of who touched what data and when. The Privacy Rule’s minimum-necessary standard applies too: a migration vendor or contractor should only be handling the PHI required to do the migration, not the practice’s entire historical record by default. If a third-party vendor is involved in any part of the move, a signed Business Associate Agreement has to be in place before that vendor creates, receives, maintains, or transmits any PHI — not after the project starts. Keeping audit-ready documentation of the migration procedures, security measures, and any incidents along the way is what makes a compliance review straightforward instead of stressful.
Deciding What Moves and What Gets Archived
Not every record needs to be actively migrated into the new EHR. Older, less frequently accessed history is often better served by a compliant legacy data archive that keeps it securely stored and retrievable without cluttering the live clinical workflow. The goal is what’s sometimes called "one patient, one record" — a clinician should be able to pull a complete patient history without toggling between two logins.
| Record type | Typical treatment |
|---|---|
| Active problem list, current medications, allergies, recent labs | Migrate fully into the new EHR, clinician-validated before go-live |
| Older encounter notes and infrequently referenced historical labs | Move to a compliant legacy archive rather than a full EHR import |
| Full legacy chart, retained for regulatory retention periods | Keep accessible via parallel legacy-system access for several months post-cutover |
A Practical Pre-Migration Checklist
- Inventory what data actually exists in the legacy system before deciding what to move.
- Build a written data retention roadmap: what to keep, how long, in what format, and where.
- Map every field — problem lists, medications, allergies, labs — from old system to new, not just the obvious ones.
- Confirm both systems support standardized exchange formats like HL7 or FHIR wherever possible.
- Run data cleansing and de-duplication before the migration, not as cleanup afterward.
- Have clinicians validate critical clinical data — allergies and medications first.
- Confirm a signed Business Associate Agreement is in place with any migration vendor before PHI moves.
- Plan a phased cutover with parallel legacy-system access, rather than a single hard switch.
- Document every safeguard, procedure, and incident for HIPAA audit readiness.
- Budget realistically for the migration’s actual data complexity, not the vendor’s estimate alone.
An EHR data migration checklist is only as good as the vendor executing it. Practices switching systems generally need more than one specialist in the process — someone who understands HL7/FHIR data mapping, and often a separate resource for the HIPAA security risk assessment that should accompany any project touching PHI at this scale. That’s the kind of matching a neutral, statewide health-IT directory exists to do: connecting Arizona practices to qualified, vetted vendors for the specific piece of the migration they need, rather than practices vetting unfamiliar vendors cold. None of the above is legal or compliance advice — a qualified health-IT attorney or compliance consultant should review BAAs and retention plans for your specific practice.