Ask a facility leader what keeps them from switching EMRs and the answer is rarely the new software. It is the years of history in the old one: active charts mid-episode, thousands of inactive charts with retention obligations, billing history, documents, and the quiet fear that something irreplaceable will not survive the move.
That fear is reasonable, and it is also manageable. Safe migrations are not lucky; they follow a recognizable structure. This post lays out that structure: what actually transfers, who does what, and the written agreements that turn a leap of faith into a project plan.
The division of labor nobody explains upfront
The single most misunderstood fact about EMR migration: the new vendor migrates what you can produce, and producing it is usually your job. Your data lives in the outgoing system, and only the outgoing vendor, or your own export tools, can get it out.
That has two practical consequences. First, start the export conversation with your current vendor early, while the relationship still has leverage in it, and before any contract wind-down changes their responsiveness. Second, ask the new vendor exactly what formats they can ingest, so the export you request is the export they can use.
Scope the migration in writing
A safe migration begins with a written scope that answers five questions:
What transfers? Demographics, active charts, documents, medication lists, billing history, and, critically, inactive charts. Outpatient groups commonly carry thousands of inactive charts with retention obligations attached. Confirm they are included, and confirm the new vendor's data retention posture for records you must keep but will rarely touch.
In what form? Discrete data that lands in structured fields, or documents attached to the chart. Both are legitimate; a migration that promises everything as discrete data is usually promising too much. Agree on which record types get which treatment.
Who validates it? Name a person on your side who signs off that migrated data is complete and correct, and define the sample they will check. Validation by nobody is validation by the first clinician to find a gap.
When does it happen? Usually in passes: a bulk load during configuration, then a delta migration close to cutover so the final weeks of activity come across.
What is the fallback? If go-live slips, what happens? A written fallback, including how long the old system stays accessible, converts a crisis into a contingency.
Keep the old system live until the new one has earned it
The structural rule that makes everything else safer: your current system stays live while the new one is configured and validated in the background. Cutover happens after validation and role-based training, not before, and read access to the old system typically continues for some period after go-live as a safety net for anything the migration scoped out.
This is also the honest answer to "can we switch without disrupting care." Yes, when the transition is parallel rather than a hard cut, and when the plan is in writing. Ritten's onboarding follows this model, with data migration included and a dedicated implementation manager running the timeline.
The questions that reveal a vendor's migration maturity
Put these to any vendor you are evaluating, and to their references:
- What formats can you ingest, and what have you migrated from our current system before?
- What lands as discrete data versus attached documents, by record type?
- How do you handle inactive charts, and what is your retention posture for them?
- Who on your side owns the migration, and who on ours validates it?
- What does the delta migration before cutover cover?
- References: did anything go missing, and how quickly was it resolved?
A vendor with crisp answers has done this recently and often. A vendor improvising has not, and your history is the wrong project to learn on.
