EHR migration: why switching EHR systems is hard, and how Luna handles it

An EHR migration is the project most practice owners postpone for a year longer than they should, and the reason is rarely the new system. The reason is the move itself: thousands of client records, years of notes, open claims, and a schedule that cannot pause while the data travels. Ease Health's guide to switching EHR systems puts the typical switch at 12 to 16 weeks and $5,000 to $25,000 in direct and indirect costs, and it cites Black Book Research (2025) for the finding that 40 percent of behavioral health practices switch EHRs within their first three years. Those numbers describe a project that is common, expensive, and mostly made of careful repetitive work. This post walks through where that work goes wrong, and then shows how Luna takes it on: you select the EHR you are leaving and the EHR you are moving to, delegate the migration to her, and she moves the records and verifies that everything landed where it should.

Why practices end up switching EHR systems

The same guide names the three reasons practices give most often: a poor workflow fit, billing functionality that falls short, and customer support that does not answer when it matters. None of those shows up in a sales demo. They show up eight months in, when the group has added two clinicians and the scheduling view that worked for a solo practice now hides half the calendar, or when the biller starts keeping a side spreadsheet because the claims screen cannot show what she needs.

The cost of staying is easy to underestimate because it is paid in small daily amounts. The guide works through an example that is worth repeating: a clinician who loses five hours a week to a poorly fitting system, across 50 working weeks, at a value of $150 an hour, gives up $37,500 a year in lost productivity. Against a switching cost of $10,000, that clinician recovers the expense in about three months. The arithmetic usually favors the move. What stops practices is the fear that the move itself will break something that cannot be repaired afterward, and that fear is well founded.

The EHR migration challenges that cause the damage

Every migration guide lists the same failure modes, and they are worth naming precisely because each one maps to a specific kind of work that someone has to do.

The timeline is longer than anyone budgets for

A switch runs through six phases, and practices that compress them pay for it in errors and staff burnout. The phases also stack on top of a full clinical schedule, since nobody stops seeing clients while the project runs.

Stabilization is the longest bar, and it is the phase practices forget to plan for. It is the period after go-live when staff discover what did not come across, and the length of it depends almost entirely on how well the data was checked before the old system was switched off.

EHR data migration is where records go missing

The guide calls data migration the core challenge, and it describes three ways to do it. A full automated migration costs $2,000 to $10,000 or more and depends on the two vendors having compatible export and import formats. A selective migration moves only active clients and leaves history behind. A manual migration means staff retyping records, which is slow and introduces a typo rate that nobody measures until a claim bounces on a wrong date of birth.

The failure that hurts most is inadequate validation. A practice exports its data, imports it, spot-checks twenty charts, and cancels the old subscription. Three months later a returning client calls, and their chart has a name and a phone number but no insurance details and no treatment history. By then the old system is gone and the record cannot be rebuilt. The work of comparing every record in the old system against its copy in the new one is exactly the work a busy practice skips, because it is tedious and because nobody owns it.

Billing keeps moving while the systems change

Claims submitted from the old system are still being adjudicated when the new system goes live. Someone has to track the accounts receivable left behind, post payments that arrive for old claims, and make sure no session falls into the gap where it was delivered in one system and billed from neither. Practices that go live at month-end, or in the middle of a heavy billing week, make this worse.

Training and the productivity dip

The guide estimates 8 to 20 hours of training per staff member, and a productivity loss of 10 to 20 percent for one to two months after the switch. For a six-clinician group with two administrative staff, the upper end of that training range is 160 hours, which is a full month of one person's working time spent learning screens.

The mistakes that compound

The remaining failure modes are smaller on their own and expensive together.

• No rollback plan. If a critical problem appears in week one, the practice has no way to keep operating while it is fixed.
• Forgotten integrations. The clearinghouse, e-prescribing, telehealth, and lab connections all have to be rebuilt, and each one fails quietly.
• Careless decommissioning. Records have retention requirements, so the old system cannot simply be cancelled the day the new one goes live.
• Implementation and migration fees. The guide puts implementation at $500 to $5,000 and migration services at $500 to $3,000, before any staff time is counted.

How Luna turns an EHR migration into a delegated task

Luna, our AI practice manager, already works inside the systems a practice runs. She signs in to an EHR with credentials you provide, which are encrypted at rest, and she works the same screens your staff uses. Where a system offers a direct connection she uses that instead. That ability to read from one system and write into another is the whole of what a migration requires, which is why a migration is a natural job to hand her, and why she can run one between any EHRs instead of a fixed list of vendor pairs.

It is worth being clear about one thing first. Adding Luna to a practice never requires a migration, because she works with whichever EHR you already have. Switching EHR systems is a separate decision you make for your own reasons, and when you make it, she is the one who carries the boxes.

The process has four parts.

Select your two EHRs

You start on the integrations page, where you connect the EHR you are leaving and the EHR you are moving to. Connecting means giving Luna a way in, either a sign-in or an API key depending on the system. You keep both systems active during the move, which also gives you the rollback plan that most practices skip, because the old system stays complete and readable until you decide otherwise.

Luna supports migrations between any EHRs, in either direction, and the pairing is yours to choose. The systems behavioral health practices ask about most are already listed: SimplePractice and TherapyNotes, which she works through the same sign-in your staff uses, and Healthie and IntakeQ or PracticeQ, which connect with an API key. A practice leaving SimplePractice for TherapyNotes follows the same four parts as one leaving IntakeQ for Healthie. If your EHR is not on the list, the approach is the same, because any system a person can sign in to is a system she can read from and write to.

Delegate the work in plain English

You then tell Luna what you want, in the same words you would use with a person. A typical brief reads like this: move all active clients first, starting with the ones who have appointments in the next two weeks, then move inactive clients seen in the last three years, and bring each client's demographics, insurance details, upcoming appointments, and documents. She plans before she acts, shows you the plan, and asks about anything ambiguous before she starts, such as how to handle two records that look like the same person.

Luna migrates the records

She works through the list record by record. For each client she reads the source record, creates the matching record in the new system, and enters each field where the new system expects it, including the cases where the two systems disagree about structure. One EHR stores a single insurance field and the other separates the payer, the member ID, and the group number. One stores a client's preferred name in a notes box and the other has a field for it. A bulk import drops or mangles these, and a person handles them inconsistently on the four hundredth record. Luna applies the same rule every time, and what she learns about how your practice's data is laid out is kept in the confidential memory she builds for each practice, so the decisions made on the first fifty records carry through to the last.

She keeps a ledger of every record she has touched, marked as handled, not needed, or failed. If the work is interrupted, she resumes from the ledger and does not create duplicates.

Luna verifies that everything is set up properly

Verification is the step that separates a migration you can trust from one you hope went well. After the records are moved, Luna goes back through them and compares each one in the new system against its source in the old one.

She also checks the setup around the records: that each clinician's calendar shows the right availability, that service types and session lengths match what you offered before, and that upcoming appointments sit on the right clinician at the right time. At the end you receive a written report that lists what was moved, what was verified, what was corrected, and what is waiting on a person.

What a migration looks like for one practice

Consider an illustrative example. Harbor Light Counseling is a six-clinician group practice with about 1,400 client records, of which 380 are active. The owner has decided to leave an EHR whose billing screens her biller has worked around for two years.

Done by hand, the data work alone is large. At ten minutes a record to retype and check, 1,400 records come to more than 230 hours, which is close to six weeks of one full-time person doing nothing else. That is why most practices choose the selective route and leave history behind.

With Luna, the owner connects both systems on a Monday and writes the brief. Luna moves the 380 active clients first, in order of their next appointment, so that every client seen that week already exists in the new system. She moves the inactive records after that, in the background, while the front desk keeps working. Staff spend their training hours learning the new screens with real client data already in place, which is a better way to learn than practicing on an empty system. When verification finishes, the report lists eleven records that need a decision, most of them possible duplicates, and the office manager resolves them in one sitting.

The numbers in that example are illustrative and not a measured study, but the shape is the point. The 12 to 16 week timeline does not disappear, because planning, training, and stabilization still involve people. What changes is that the data work stops being the part that sets the pace, and the stabilization phase shrinks because the missing-data surprises were found by verification before go-live.

What stays with your team

An agent doing the moving does not remove the decisions, and it should not. Four things stay with people.

1. Choosing the new EHR. Luna moves you to the system you picked. Whether it fits your workflow and your billing is your judgment to make.
2. Clinical review. She moves records and confirms they match. She does not interpret a treatment history or decide what belongs in a chart, and anything that calls for clinical judgment goes to a clinician.
3. Consequential choices. Before merging two records, skipping a client, or changing anything in billing or settings, she asks.
4. Retention of the old system. Keep read access to the old EHR for as long as your record retention obligations require, even after every record has been verified in the new one.

Every task she runs leaves a trail you can inspect: the plan she made, the steps she took, a recording of the session, and the ledger of records handled. If a record is ever questioned, you can show what the old system held and what she entered.

For practices with needs beyond records, such as rebuilding a clearinghouse connection or a custom integration between the new EHR and other software, our forward-deployed engineering team works alongside Luna on the parts that need an engineer.

An EHR migration checklist for the weeks before go-live

Whether or not an agent does the moving, the same preparation applies, and it is short enough to keep on one page.

1. Pick a go-live date that avoids month-end billing, holidays, and your busiest clinical weeks.
2. List every connection the old system has, including the clearinghouse, e-prescribing, telehealth, and reminders, so that none is forgotten.
3. Decide which records move first, and put clients with upcoming appointments at the front.
4. Keep both systems running in parallel for one to two weeks, which is your rollback plan.
5. Verify every record against its source before you cancel anything.
6. Plan for the 10 to 20 percent productivity dip by lightening schedules in the first two weeks.
7. Confirm how long you must retain the old records, and keep access for that long.

Switching EHR systems will always be a real project, and the honest version of the promise is a narrow one. The planning and the training remain yours. The thousands of careful, identical steps in the middle, and the checking that proves they were done right, are work you can now delegate. If you are weighing a move, walk us through the two systems involved and we will show you what the migration would look like for your practice.

Also read

• Behavioral health practice management with an AI co-worker: what Luna does in your EHR once the move is finished, from daily housekeeping to the report she writes each evening.
• Mental health clinics need an AI employee, not another AI receptionist: why work that spans several systems needs one worker who can cross them, which is the same reason a migration suits an agent.
• Patient engagement software for behavioral health, compared: how to add agents beside the tools you already run when you are not ready to switch anything yet.