What an EHR Data Migration Should Move, and What to Archive
Key Takeaways
- Scope EHR data migration by record category including active clinical, historical notes, open orders, appointments, billing because “move our data” prices out five different ways.
- Not everything belongs in the new chart. An accessible archive with real search, permissions and export is often cheaper than importing years of scanned documents.
- Patient identity is where migrations fail quietly. After a merger, two facilities can both hold patient number 1042, so map the source organization into the identifier or you will merge two people.
- Named owners beat a RACI chart. A clinical lead accepts clinical meaning, HIM owns identity and archive access, revenue cycle signs off on balances, one sponsor calls go-live.
- Ask vendors to price discovery, extraction, cleanup, mapping, trial imports, validation, cutover and support separately since patient count alone is a weak estimate.
The new EHR is ready, the training sessions are booked, and the old vendor’s contract is about to expire. Then someone asks whether historical medication changes, scanned referrals and unpaid balances will appear in the new system. The answer needs to be more specific than “the data will transfer,” and getting specific is what EHR data migration planning actually is.
EHR data migration means moving selected records from an existing electronic health record system into a replacement system, preserving the information and relationships needed to use those records. The destination may be a commercial platform or the product of your own EHR software development work. Either way, a successful import must leave clinicians able to trust the chart and administrative teams able to finish outstanding work.
For healthcare leaders, the key decisions concern scope, responsibility and evidence. What needs to move? What can remain in an accessible archive? Who confirms the result is safe to use? The replace-or-keep question needs to be answered one step earlier. You can refer to the healthcare software modernization guide once the destination and business scope are settled. It explains how to answer those questions before committing to a migration date.
Define the EHR Data Migration Scope Before Asking for a Quote
Simply asking a vendor to “move our EHR data” is too vague. One vendor may include only demographics and clinical summaries, while another may include years of notes, attachments, and billing records. Both could still call their proposal a complete migration.
Start with an inventory of source systems, facilities, patient populations and record types. Include documents stored outside the EHR, such as scanned consent forms or a separate imaging repository. Check who is responsible for providing each data export and whether the new EHR can import the information in a format that staff can actually use.
Ask both vendors for representative exports and import specifications early. A file containing all the source data may still require considerable work before the destination can use it. The gap between HL7 v2 and FHIR is often where the extra work comes in. A system that only sends HL7 v2 feeds cannot simply provide clean FHIR resources whenever you ask for them.
Migration also varies from ongoing integration. EHR integration keeps applications exchanging information as care continues. Migration establishes the records and history needed for a system transition. The two projects can share interfaces, but they need to have different acceptance criteria.
Which EHR Records Should You Migrate, and Which Should You Archive?
Moving every historical field into the new EHR can increase costs without adding much value to daily care. But moving too little can force staff to switch between systems just to understand a patient’s history. The best approach is to decide what should be moved based on the type of record and how it will be used.
| Record category | Decision to resolve | Evidence to request |
|---|---|---|
| Active clinical information | Which allergies, medications, problems and recent results must be available in the working chart? | Clinician review of representative migrated charts |
| Historical notes and attachments | Should they be structured, readable documents or accessible through an archive? | Successful retrieval by patient, date and document type |
| Open orders and referrals | Which items remain actionable, and who will follow them? | A reconciled list with an owner for every outstanding item |
| Appointments and patient access | What happens to future bookings, portal accounts and communication preferences? | Test appointments and patient access scenarios |
| Billing records | Will balances and claims move, or be worked down in the old system? | Finance reconciliation and an agreed collection workflow |
An archive should be usable by the people who need it. Confirm search, permissions, export, support and the cost of retaining access. A collection of files that only a developer can interpret is a poor substitute for an operational record-access process.
Retention and disposal decisions should be agreed with the organisation’s records and legal teams. Do not assume that the same retention period applies to every type of record or every jurisdiction.
Resolve Patient Identity and Clinical Meaning During EHR Data Migration
A migration can transfer every record successfully and still connect information to the wrong patient or display it incorrectly. That is why validation should check not only the volume but also whether the data is linked to the right patient and still means the same thing.
Patient matching needs special attention after acquisitions or consolidation. Different facilities may use the same local patient number for different people. The same person may also have several identifiers. Keep a clear link between the old and new identifiers, and send uncertain matches for review instead of merging them automatically.
Clinical information requires its own checks. A medication marked “discontinued” must not become active after import. An allergy without a recorded reaction should not be treated as “no known allergies.” A laboratory value needs the correct unit, date and context.
Use a mapping register to document the source field, destination, transformation rule and exceptions. For ambiguous clinical fields, have an appropriate clinical owner approve the interpretation. The implementation team should not have to guess the meaning of undocumented value.
Consider a hypothetical practice merger where two locations use patient number 1042. Matching solely on that number would create a serious error. Including the source organisation in the identifier mapping avoids this conflict. If there is still a possible duplicate patient, it should be reviewed separately rather than merged automatically.
Who Owns Each EHR Data Migration Decision?
The migration partner can implement the transfer, but the healthcare organization must decide what is acceptable for its operation. Assign a specific person to each important decision so there is clear ownership.
| Decision | Accountable role | Contributors |
|---|---|---|
| Scope and funding | Executive sponsor | Clinical, operations and finance leads |
| Clinical interpretation and acceptance | Clinical lead | Specialty representatives and migration team |
| Patient identity and archive access | Health information management lead | Registration, records and technical teams |
| Financial reconciliation | Revenue cycle lead | Billing staff and vendors |
| Security and data handling | Security or privacy lead | Legal, vendors and implementation partner |
| Go-live decision | Named transition sponsor | Clinical, operational and technical owners |
This is a suggested ownership model; smaller organizations may combine roles. What matters is that the technical team has someone to resolve uncertainty and the sponsor knows whose approval is needed to proceed.
Choose an EHR Migration Cutover Approach Your Teams Can Operate
The cutover is the point when the new system becomes authoritative. Below are the three common approaches that deserve consideration.
Switch at a defined time
A single cutover provides a clear boundary between the old and new systems. It can work well for a smaller operation when the data import has been tested and the transfer window is manageable. The main challenge is completing the final export, import, and validation within that time.
A weekend cutover is not automatically safe. The rehearsal should show how long the process actually takes and which services will still be available during the change.
Move by facility or service line
A phased transition can limit the number of users affected by an early problem. It also creates a period when patient information exists in two systems. Teams need rules for shared patients, cross facility appointments and results arriving from external organizations.
Only choose this approach if staff can safely manage these situations. A small technical change can still create a complicated clinical workflow.
Load history first, then transfer final changes
An initial load can move most of the historical data before go-live. A final transfer then brings across new and changed records. This approach depends on the source system exposing changes reliably and the destination handling updates without duplication.
Ask how the process will handle deletions, corrections, merged patients, and documents signed after the first export. Saying “we transfer the new rows” does not fully explain how the migration will work.
How Do You Test an EHR Data Migration Before Go-Live?
Successful import logs are only the first layer of evidence. Build acceptance testing around below four areas.
Completeness: Reconcile the records expected, transferred, rejected and deliberately excluded. Explain differences by category and source rather than relying on one overall percentage.
Clinical accuracy: Have clinicians review a planned sample of charts, including complex histories and known edge cases. Combine that review with automated checks across the dataset. Check medication status, allergy meaning, result units, note authorship and chronology.
Operational continuity: Test future appointments, open referrals, unsigned notes, pending results and patient messages. A result requested before cutover must still reach someone responsible for reviewing it afterward.
Financial continuity: Confirm the handling of outstanding balances, claim status, credits and payment adjustments. If old claims remain in the legacy system, staff need continued access and a reconciliation process.
Write acceptance rules before the test run. For example, an unresolved patient identity mismatch or an incorrect active allergy should be treated as a go-live blocker under the organization’s agreed clinical criteria. Low risk issues, such as formatting problems, can be accepted if there is a clear plan to fix them.
Plan EHR Migration Downtime and Recovery
A promise of zero downtime is difficult to assess without defining what stays available. Patients may still receive care while documentation is temporarily restricted. An archive may remain readable while the new EHR is unavailable. Describe these conditions precisely.
The cutover plan should state:
- When the old system stops accepting each type of update
- How staff document care during any interruption
- Who monitors incoming results and urgent messages
- How information collected during downtime enters the permanent chart
- What triggers a delay, recovery action or rollback
- Who has authority to make that decision
Rollback becomes harder once clinicians start using the new system to record care. Restoring a backup from before the cutover could remove records created after go-live. The recovery plan must also protect new information, including prescriptions, orders, and payments.
HHS’s HIPAA Security Rule describes contingency requirements covering backup, restoration and emergency operation. For migration planning, rehearse recovery and continuity procedures alongside the transfer itself.
Secure the Temporary Data Copies EHR Migration Creates
Migration can create extracts, staging databases, rejected record files and support logs. Include these copies in the project’s data inventory, with defined access, storage, transfer and disposal arrangements.
Confirm the required business associate agreements before giving a migration provider access to electronic protected health information. NIST’s SP 800-66r2 implementation guide helps to understand how regulated entities are expected to handle risk analysis, authorized access, audit controls and information integrity.
Ask the partner to explain how it limits patient data in logs, controls support access and records important transfer activity. At project close, obtain evidence that temporary access and unnecessary copies were handled according to the approved plan.
What Drives EHR Data Migration Cost and Timeline?
Patient count is important, but it is not enough to estimate the migration work. A smaller dataset with proprietary attachments and unclear patient identifiers can take more effort to migrate than a larger consistent data.
Request separate estimates for discovery, extraction, cleanup, mapping, trial imports, validation, cutover and support. Include archive access, overlapping vendor contracts and staff time for testing. The same budget pressures that show up in an EHR integration budget apply here, usually in the cleanup and validation lines rather than the transfer itself.
The main schedule dependencies are usually the availability of source exports, destination import capabilities, unresolved data questions and the time clinical and finance teams can devote to validation. Ask vendors to state those dependencies and the assumptions behind their estimate.
A useful proposal also defines how many test cycles are included, who fixes rejected records and what triggers additional fees. Ask for a cost comparison between importing all historical documents and placing selected history in an accessible archive. The decision should account for retrieval needs as well as implementation price.
Run This EHR Data Migration Checklist Before Go-Live
Before go-live, confirm that:
- Every in-scope record category has an agreed destination.
- Exclusions and archive arrangements have been approved.
- Identity exceptions and critical clinical defects are resolved.
- Open orders, referrals and results have named owners.
- Clinical, operational and finance acceptance is recorded.
- The final transfer has been rehearsed within the planned window.
- Downtime and recovery procedures have been tested.
- Support coverage and escalation contacts are available.
- Legacy access will remain available for the agreed period.
- Decommissioning depends on completed reconciliation and record access.
The most useful question for a migration partner is,”What evidence will we have that our staff can safely work from the new system?” Before signing ask to see the proposed mapping register, exception report, acceptance plan and cutover runbook.
Tech Exactly’s healthcare software development team can help assess the source and destination systems and scope the engineering work around those decisions. Bring a list of systems, sample export specifications and the workflows that must continue during the transition.
Frequently Asked Questions
The terms are often used for similar system transition projects. The practical scope depends on the records, applications and organizations that are involved. You need to define those explicitly in the agreement.
Not necessarily. Some information belongs in the active chart while other history may be better retained in an accessible archive. The decision should be based on clinical usefulness, access requirements, what the new EHR can support, and the cost of migration.
Some approaches can shorten the transfer window, but what is possible depends on both systems and the workflows involved. Define how much interruptions are acceptable and test the plan instead of relying on a general promise.
The old EHR can be retired once required records are still accessible, outstanding workflows have a home, reconciliation is complete and the appropriate owners have approved the retirement. Go-live and decommissioning should have separate acceptance decisions.
