What actually goes wrong when therapy practices switch EHRs

The single most underestimated risk in an EHR migration is not data export. It is the consent and Release of Information (ROI) requirements that gate the export, a procedural blocker that can take weeks and stalls the migration before it starts.

Switching an EHR feels like a technical task: pull the data out of one system, push it into another. In practice, the technical export is rarely the part that breaks. The parts that break are the parts no one budgeted for. Consent forms that gate the transfer. Calendars that do not move. Notes that arrive merged into one undifferentiated pile.

This post draws on Oasys's proprietary knowledge: direct, ongoing conversations with practicing therapists and practice owners, and our seat at the infrastructure layer of real practices, where we see how documentation, billing, and consent actually work day to day. Across conversations with practice owners who have migrated or attempted to migrate EHRs, the same failures surface repeatedly: calendar data that cannot be migrated at all, consent forms not visible post-import, multiple note types merged into a single undifferentiated bucket, and scored assessments that will not transfer. At least one 25-provider practice deliberately deferred its full EHR migration specifically to prevent a staff exodus. Its implementation strategy became cautious and staged after staff described witnessing a practice furlough its entire team during a failed EHR rollout.

The distinction this piece turns on: the risk is not the technology of moving bytes. The risk is the procedural and structural work the export format hides from you. Below, we walk through the five assumptions that reliably break, and how to clear them.

Is migrating EHRs mostly a technical data-export problem?

No. The hardest part of most EHR migrations is not exporting the data. It is the consent and Release of Information requirements that gate the export.

Many platforms require patients to sign consent before their records can be transferred to a new practice entity, even when the same clinician is involved. This is a procedural blocker, not a technical one, and it is routinely underestimated. It takes weeks to clear because it runs at the speed of clients returning signed forms.

The migration cannot start until it is cleared. Treat consent collection as the first phase of the project, not a step you run in parallel with the data export.

Do scheduled appointments carry over to the new platform?

No. Calendars and upcoming appointments cannot be migrated from most EHRs, because they do not export in a transferable format.

Every scheduled appointment must be manually re-entered in the receiving platform. That task falls to front-desk staff during a transition period that is already disrupted. It is one of the most reliably reported surprises in migrations, and one of the most operationally painful.

The fix. Freeze new scheduling in the old system at a known cutover date, export the appointment list as a reference report, and staff the manual re-entry deliberately rather than hoping it absorbs into a normal week.

What gets lost in an EHR migration?

Export formats flatten data. Session notes, process notes, and chart notes that live in separate buckets in the source platform frequently land in a single undifferentiated category in the destination.

Consent documents and scanned attachments can disappear from client document tabs entirely, requiring a manual audit to find them. Scored and standardized assessments, including DASS-21 and PHQ-9 histories, often will not migrate at all, because they live in a proprietary assessments module with no export path.

This is the loss that hurts longest. A flattened note pile is recoverable with effort. A missing baseline-to-current PHQ-9 trajectory is the measurement spine of treatment, and it does not come back. Other platforms may be built differently. Oasys treats structured assessment history as data that should remain queryable, not as a screenshot trapped in a module (other tools vary).

How long does an EHR migration actually take?

Large practices should budget weeks, not days. At high client volume, prior platforms may require a formal email request to initiate export with no bulk download option, which adds days of wait time before the migration even begins.

The failure modes compound. A large zip file of chart data can fail mid-upload, requiring a fallback to a different file transfer method and a restart. Manual data entry for fields that did not map cleanly, such as gender-versus-sex mismatches in insurance records, adds further time on top of that.

So plan in weeks. The practices that get burned are the ones that promised staff a long weekend and delivered a month.

Do staff permissions and role configurations carry over automatically?

No. Supervisor assignments, clinician permissions, and admin role configurations must be rebuilt from scratch in the receiving platform.

Permission gaps at go-live are a predictable failure mode: associates who cannot access their client list, or supervisors who cannot see associate notes. In a behavioral-health practice, a supervisor who cannot see associate notes is a compliance problem, not just an inconvenience.

The fix. The practices that handle this best treat permissions configuration as a formal pre-launch checklist item, not an afterthought. Map every role, every supervisory relationship, and every access boundary before go-live, then test them with real logins.

So, how do I switch EHRs without losing patient data?

You clear the consent gate first, then sequence the rest so nothing silently disappears. The technical export is the easy part. The work is procedural, and it is checkable.

A migration is on solid ground when these properties hold:

1. Consent and ROI cleared before export begins. Confirm whether the source platform requires client consent to transfer records to a new entity, and collect those signatures as phase one.
2. A scheduling cutover plan. Assume calendars do not move. Staff manual re-entry of upcoming appointments deliberately.
3. A note-type and document audit. Verify after import that note types stayed differentiated and that consent forms and scanned attachments actually appear in client document tabs.
4. An assessment-history check. Confirm before cutover whether scored instruments (PHQ-9, DASS-21, and similar) can transfer at all, and capture them manually if they cannot.
5. A permissions checklist tested with real logins. Rebuild supervisor, clinician, and admin roles, then verify access before go-live.
6. A timeline measured in weeks. Budget for email-gated exports, failed large uploads, and manual field remapping.

If yes to all six, ship it. If not, you have found your next blocker.

Migration failure is rarely about losing the bytes. It is about losing the structure that made the bytes mean something, and the practices that clear it treat consent, scheduling, and permissions as the work, not the footnotes.