Switching Therapy EHRs Without Losing a Month: The Migration Runbook

Switching EHRs has a reputation for eating a month of a practice’s life, and the reputation is earned — but rarely because the data transfer itself is hard. Migrations go badly when four decisions get made late instead of early: what actually comes across in the export and in what form, when the new system becomes the system of record, how long both systems run at once, and which dates of service get billed from which platform. Decide those four things before you announce anything to the team and the switch becomes a project with a schedule. Decide them during the move and every surprise becomes an emergency. This article is the runbook: your legal rights over the data, what exports really contain, the parallel-run rules that prevent a split chart, and a cutover checklist you can run week by week.

The first honest conversation of a migration is about what “we’ll move your data” actually means, because a practice’s record is not one data set — it is at least five, and they travel differently. The pattern is simple: the closer something is to plain structured fields, the better it moves. Names, birthdates, and contacts import almost everywhere. Clinical narrative sits at the other end: most systems export notes and evaluations as finished documents — PDFs or similar — not as structured records the new system can treat as native, editable notes. Ask the old vendor for a complete sample export of one fictional or test client before you plan anything else, and open every file it produces. That one afternoon of inspection replaces a month of assumptions.

Two implications follow. First, the goal rebuild is the real labor of a therapy EHR migration, so scope it deliberately: rebuild hierarchies for clients with active plans of care, and let discharged clients live in the document archive. Second, because notes arrive as documents, the old chart never fully disappears into the new one — which is why the retention and archive decisions later in this article are part of the migration, not an afterthought.

You negotiate the exit best from a position of knowing what the vendor is and is not free to do. Three federal frames matter. First, the HIPAA right of access does not pause for a migration: patients keep the right to their records in one or more designated record sets, and a covered entity generally must act on an access request within 30 calendar days, with at most one 30-day extension. A vendor transition is not among the permitted reasons to deny access, so your migration plan has to keep you able to produce records the whole way through. Second, the federal information blocking rules under the 21st Century Cures Act, at 45 CFR Part 171, prohibit health care providers, developers of certified health IT, and health information networks from practices likely to interfere with access, exchange, or use of electronic health information except where an exception applies. Third, products certified under the ONC Health IT Certification Program must include an EHI export capability — the § 170.315(b)(10) criterion — that can export a single patient’s electronic health information without developer assistance, and the entire patient population’s EHI in a computable format with publicly documented structure, precisely so that switching systems is possible.

One caveat keeps this honest: many therapy-specific platforms are not ONC-certified health IT, and the certification-linked obligations attach to certified products and their developers. You can check any vendor against the Certified Health IT Product List (CHPL) in a minute. If your old system is not certified, your leverage is the contract you signed, the BAA’s terms for return of protected health information at termination, and your own obligation — which never moves — to produce records when patients and payers ask. That is also the argument for settling export terms in writing at signing time: ONC’s contracting guide for providers observes that few standard EHR contracts include transition provisions at all, so the export format, cost, timing, and transition support you will want at the end are terms you have to ask for at the beginning.

The steps below are ordered by what blocks what, not by the calendar, because the honest schedule depends on two things outside your control: how long the old vendor takes to produce a full export, and how long payer and clearinghouse enrollments take for the new system. Start both of those clocks first and fit everything else around them.

1. 01

   Get the sample export and the exit terms before you commit

   Request a complete export of one test client from the old system and open every file. In parallel, get the new vendor’s contract terms on data export at termination — format, cost, and timing — in writing, so the next migration is easier than this one. If you have not yet signed with the new vendor, this is your maximum-leverage moment on both sides of the move.

2. 02

   Sign the new BAA before any real data moves

   The new vendor becomes a business associate the moment it holds protected health information on your behalf, so the business associate agreement comes before any import, trial data entry with real clients, or staff experimentation. Build the empty shell first: users and permissions, note templates, a goal bank seeded in your own style, fee schedule, and payer list.

3. 03

   Start payer and clearinghouse enrollment immediately

   Electronic claims, remittance, and payment enrollments for the new system are the long pole of most migrations, and each payer runs its own process on its own timeline. Enroll early, track each payer’s status on one list, and do not schedule the billing cutover until your highest-volume payers are confirmed.

4. 04

   Import demographics, then clean before go-live

   Bring over demographics, contacts, and insurance details from the structured export. Deduplicate and archive inactive records in the process — a migration is the one chance to shed years of data debt rather than pay to move it.

5. 05

   Rebuild the active caseload: schedules, then goals

   Recreate recurring appointment series for active clients in the new system, then rebuild goal hierarchies and plans of care for clients with active episodes. Assign this to clinicians for their own caseloads with protected time; it is clinical work, not clerical work.

6. 06

   Run the parallel period with explicit source-of-truth rules

   For a defined window, both systems are alive and the rules in the next section decide which one owns what. The parallel run ends on the billing cutover date, not when it feels done.

7. 07

   Cut billing over on a single date of service

   Every visit on or after the cutover date is documented and billed in the new system. Everything before it is worked to zero in the old system. The section below covers why this line has to be a date of service, not a claim-submission date.

8. 08

   Take the final export and archive the old system

   After the old accounts receivable runs down, take the complete final export — documents, reports, and billing history — verify you can open and search it, and store it with your retention obligations in mind. Only then does the old subscription end.

The parallel run is where migrations quietly fail. Two live systems with no rules produce a split chart: a session scheduled in one system and documented in the other, a note nobody can find during a records request, a claim billed twice or not at all. The fix is not effort — it is jurisdiction. Before the parallel period starts, write down, per data type, which system is the single source of truth on which dates, and post it where the whole team schedules and documents.

Three rules do most of the work. First, one calendar rules from day one of the parallel period: all scheduling and rescheduling happens in the new system, full stop, because a schedule split across two systems fails within a week. Second, the note lives where the visit is billed — sessions with dates of service before the billing cutover are documented in the old system, sessions on or after it in the new one, so chart and claim never separate. Third, nothing is entered twice by hand. Double entry feels diligent and is actually how the two systems come to disagree; wherever you are tempted to re-key, pick one owner instead. Keep the parallel window as short as your payer enrollments allow, and staff it deliberately — every extra week of two systems is a week of paying twice and reconciling daily.

The cleanest cutover rule fits in one sentence: every visit with a date of service on or after the cutover date is documented, billed, and collected in the new system, and every earlier date of service is finished in the old one. Cutting by date of service rather than by claim-submission date means any given visit has exactly one home, no matter when its claim goes out, gets corrected, or gets appealed. Choose the date deliberately: after your highest-volume payers confirm electronic enrollment for the new system, at a natural boundary like a month start so reconciliation reads cleanly, and never during your busiest season.

Resist the urge to migrate open accounts receivable. Open claims carry payer-specific history — original submission data, correction trails, appeal deadlines — that does not transfer as data, and rebuilt balances are where money disappears. Instead, keep the old system in a billing-only lane after cutover: no new visits, just working the outstanding claims to zero. Watch two lists weekly until they empty — open claims by payer, and unbilled or unsigned sessions with pre-cutover dates of service. Switch time-of-service collections, card-on-file, and patient statements to the new system on the cutover date, and tell families in advance that statements will look different so the first new invoice does not read as a billing error.

Run this as a living document: assign every line an owner and a date, and review it at a standing weekly migration meeting from the day you request the sample export to the day the old subscription ends. The phases match the sequence above, so a stalled line tells you immediately what downstream work it is blocking.

Switching systems does not shorten any retention clock. The HIPAA Privacy Rule itself does not set a retention period for medical records — how long you must keep them is governed by state law and, where applicable, by program and payer requirements — while HIPAA separately requires that its own required documentation, such as policies and authorizations, be kept for six years. Whatever the applicable periods are for your practice, the migration decision is where those old records will live: a complete, verified export you store yourself, a cheap read-only tier of the old system if the vendor offers one, or both for a transition period. Judge the choice by one test — if a payer audit or a records request arrived tomorrow for a client discharged two years ago, could you produce a complete, legible chart within the deadline? A migration is finished when the answer is yes from the new stack alone.