Most EHR migrations go wrong because the practice never decided what should work better in the new system.
Most clinicians dread switching EHRs, and for good reason. Almost every clinician we work with has a bad migration behind them, usually a team trying to learn a new system while keeping the clinic running.
That dread is a reasonable response to how these transitions have usually gone.
Not every practice should switch. What follows is the process we use with functional, integrative, and longevity practices to decide whether a switch is worth making and, when it is, how to make sure it simplifies the work rather than recreating the same problems in newer software.
Step 1: Map the work before you look at software
The most common mistake is starting with demos. A demo shows you what a product does well. First, you need to understand what your current workflow is not doing well.
For one week, ask everyone on your team to write down their recurring tasks and the steps inside each one. "Review labs" may mean logging into several lab portals, downloading reports, uploading them into the chart, finding prior values, writing the interpretation, translating it for the patient, and creating the follow-up.
That is a workflow inside a workflow.
Once the tasks are on paper:
- Circle every step that uses AI. Is it built into the workflow, or does it require another tab, tool, or copy-and-paste step?
- Count the tools and logins involved. Include lab portals, intake tools, messaging platforms, spreadsheets, supplement dispensaries, and payment systems.
- Mark every handoff or repeated step. Look for information being copied, re-entered, rewritten, reformatted, or passed to someone else.
At the end of the week, you will have a friction list. Seeing it all in one place matters, because sprawl hides inside reasonable decisions. Every tool probably solved a real problem when you bought it. That is why the weight of the whole system is hard to see from the inside.
Inventory every subscription too: the job it performs, what it costs, and whether you bought it to patch a gap in another tool. Those patches are usually where the surprises are. We itemized what a typical stack costs in the real cost of running a practice on 4 to 7 tools.
Do not lose the forest for the trees. The goal is a simpler workflow that gives your team more time and attention for clinical thinking, patient communication, and follow-through. A perfect process map is not the point, and neither is the smallest possible stack.
This audit may also tell you not to switch. If the friction list is short and your current stack works, stay where you are. No vendor should talk you into fixing a problem you do not have.
Step 2: Build the magic wand list with your team
Bring your clinical and administrative teams together and ask one question:
If you could wave a magic wand and make one part of your workday easier or make it disappear, what would go first?
Have everyone answer before discussing it as a group. The answers will not match, and that is the point.
Your front desk may be chasing forms that never reached the chart. Your medical assistant may be logging into the same lab portals every morning. Your health coach may be documenting the same plan twice. Your clinicians may be turning one visit into a note, a patient summary, a protocol, and a follow-up message.
Push past broad answers. Ask:
- Which labs and portals create the most work?
- Where is the same information entered more than once?
- Which part of a 30-minute visit creates another 30 minutes of work afterward?
- Which patient questions keep returning because the plan or next step is hard to find?
Then translate each answer from a feature into an outcome.
"Has lab integrations" is a feature. "Our most-used lab results enter the chart automatically and can be trended in minutes instead of reviewed across several PDFs" is an outcome.
"Uses AI for documentation" is a feature. "One encounter produces the clinical note, patient instructions, and follow-up tasks without three separate rewrites" is an outcome.
Written this way, your magic wand list becomes the requirements document for the switch.
Step 3: Make the demo about your practice
Bring two lists to every demo: the friction points you need to smooth over and the magic wand requests that would meaningfully improve how your practice works.
Label every item as one of two things:
- Non-negotiable: It must work on day one for the practice to operate safely and efficiently.
- Nice-to-have: It would improve the workflow, but the practice can function without it while it is configured or developed.
Non-negotiables may include your exact lab integrations, prescribing and ordering, patient communication, role-based access, billing or membership workflows, and a complete data export.
Send the lists before the demo. Ask the vendor to show how your practice would work inside the platform. Skip the full feature tour.
Have them walk through:
- A new patient with a complex history and records from several sources
- A specialty lab panel arriving and being compared with prior results
- A visit becoming a clinical note, a patient-facing plan, and assigned follow-up tasks
A polished demo shows you the cleanest possible version of the product. You need to know how it handles your messiest Tuesday.
We are no longer in the software stone age, when every practice was handed the same rigid system and told to work around it. Many AI-native vendors now want detailed workflow feedback and have teams that can configure workflows or add well-defined requests to the development roadmap.
But a roadmap promise is not a current capability. Ask: Does this work today? Can it be configured during implementation? Is it actively being built? Who owns the request, and what is the realistic timeline?
A nice-to-have may be able to wait. A non-negotiable should not depend on "coming soon."
Pay special attention to your heaviest workflow. For many functional and integrative practices, that is lab volume. If you run hundreds of orders each month across multiple labs, confirm that the platform can support the actual load before you choose a migration date. Waiting is better than running two systems indefinitely because the most important workflow was not ready.
Finally, ask what format your data exports in, what it costs to leave, and how long an export takes. You may never need the answer. You should still have it.
Step 4: Plan the whole EHR migration before it begins
Treat the migration like any serious practice goal: give it a date, work backward, block the schedule, assign owners, and prepare your team and patients.
Before the migration begins, decide:
- The launch date: When the new system becomes the source of truth
- What moves: Which records migrate in full, which come over as summaries, and which remain in a secure archive
- How the team prepares: When training happens, which workflows you will rehearse, and whether the clinical schedule needs to be reduced
- What patients see: When they are notified, where they will log in, and when the old portal will close
- How the migrated data gets checked: Who verifies a sample of records against the old system before launch, and what happens if they do not match
- When the old system becomes read-only: A firm endpoint, not an open-ended parallel workflow
A short, dated window of parallel access is a reasonable safety net. Leave it open-ended and neither system becomes the source of truth: half the team works in one, half in the other, and six months later the practice is paying for both and trusting neither.
Not every historical record needs to move in the same form. Active records may need to come over in full. Others may be better as summaries or archived exports. Preserve the history you need without importing ten years of clutter.
Training should feel like a rehearsal of your real week. Use your own intake, your most complex patient archetype, your lab workflow, and your follow-up cadence. Everyone who touches the system should perform their own job inside it at least once before launch.
AI-native onboarding should feel different from legacy EHR training. Instead of memorizing click-paths, your team can interact with the system in natural language and focus on how the practice works. But easier software still requires training, human review, and live support. The questions that matter usually surface in the second week.
Plan the patient-facing transition just as carefully. Patients should have one platform, one set of instructions, and one place to communicate. Every extra login becomes a support message or missed communication later.
Step 5: Make a plan, stick to it, and don't look back
Going live is the middle of the switch. It is finished when the old tools go dark.
Turn the subscription inventory from Step 1 into a shutoff list. Put an owner and a cancellation date beside every tool the new platform replaces. Consolidation only saves money if you stop paying for the old stack, and it only simplifies the workflow if your team stops using it.
Then watch for workarounds:
- A spreadsheet appears to track something the platform should handle
- Someone quietly returns to an old tool
- Part of the clinical record starts living outside the system
- The same patient or staff question keeps resurfacing
Read these as signals that a workflow is unclear, training is incomplete, or the platform is not yet carrying its weight, before you read them as resistance to change.
Bring that feedback to the vendor early. A workaround is often the first tool in the next round of sprawl.
This is why the team behind the platform matters as much as the platform itself. Gaps will surface after launch. What varies is whether your feedback reaches people who understand the clinical workflow and can act on it or disappears into a support queue.
At Ultralight, the feedback loop from a clinician identifying a gap to the product team hearing about it is measured in days. That loop, more than any feature list, is what determines whether the transition still works a year later.
Frequently asked questions
How long does it take to switch EHRs? It depends on your data volume, your integrations, and how much history you migrate. Anyone who quotes a single number without asking about those is guessing. Small practices with clean data move in weeks; larger, lab-heavy practices should plan around integration readiness, which can add months. Ask any vendor for a timeline against your specific system and record volume.
Can I run my old EHR and the new one in parallel? For a short, planned window with a firm end date, yes. As a standing arrangement, no. Open-ended parallel operation means neither system is the source of truth, and it's the most common way a switch quietly fails.
What data should I migrate? Depending on your reporting obligations, you may need to migrate all data on all patients. Otherwise, move active patients in full, keep inactive patients as summaries or archived exports, and make a clean break on anything the new system structures better than the old one did. Keep a complete export of the old system regardless.
Is there a checklist for switching EHR systems? The five steps above are the checklist: a friction audit, a magic wand list, a demo built on your own scenarios, a migration plan with a launch date and a read-only date for the old system, and a shutoff list for the tools the new platform replaces.
How do I tell my patients? Once, clearly, close to the cutover: what's changing, what they need to do, and when the old portal closes. Then make sure the old access actually closes. Patients adapt to a new platform quickly; what frustrates them is two platforms.
When should I not switch? If your friction audit comes back short. If a single tool closed your only real gap and the rest of your stack is quiet. If your heaviest workflow isn't yet supported on the platform you'd move to. And if you're within a few months of a practice-changing event like a new location or a new provider cohort, sequence the switch around it rather than through it.
If you've run the friction audit and want to see what your workflows look like on an AI-native system, we'll walk through them with you, using your own scenarios.
See Ultralight in action.
