Migrating practice management software: how it works

The four record types that decide a migration

Every practice migration is really a question about four things. Everything else is either derivable, or it is history that can sit where it is.

Clients — demographics, MRN and status, with duplicate detection against the MRNs already in the practice.
Staff — people and their roles, so assignment and supervision survive.
Authorizations — the unit pools. Losing these mid-year is the migration failure that actually costs money.
Programs and goals — the program library, which is the switching barrier every incumbent relies on.

Rebuilding the last of those by hand is the single most common reason a practice stays where it is. That is why it is an importer rather than a services engagement with a quote attached.

Nothing is written until a dry run has passed

Every row is validated against the same constraints the database enforces, and you see a verdict per row — column, row number, what is wrong — before anything is committed.

A migration that half-lands is worse than one that refuses to start, so this one refuses. There is no partial write, no “imported with warnings”, and no state where half a caseload is in one system and half in another because row 412 had a malformed date.

In practice this means a migration is iterative rather than a single event: run the dry run, read the error report, fix the source file, run it again. Most practices go around that loop two or three times, and the loop is cheap because nothing has happened yet.

What arrives as documents instead

Records outside those four come across as documents attached to the chart, or stay with the outgoing system as the historical record. Which of those is right depends on your retention obligations, not on what is convenient to move.

This is the part people underestimate. Historical progress notes, treatment plans and assessments generally arrive as attached files rather than as structured, queryable data — from any system to any system — because the structure they had was specific to the software that created it. Plan for the last two years of notes being readable rather than searchable.

Export everything before you cancel anything

Whatever you decide, and wherever you are going, get a complete export out of your current system while the subscription is still active. It is your record. Access to it after cancellation is a matter of that vendor’s policy rather than your right to the data, and the two are not the same thing.

Do this before you have chosen a destination, not after.

HL7 and FHIR: we do not exchange them

Worth saying plainly, because silence on it reads as a yes to anyone working from an integration checklist. MegAligna does not exchange HL7 v2 messages or FHIR resources today, in either direction, and there is no interface engine behind it. A hospital that needs an ADT feed, or a partner expecting a FHIR endpoint, is not going to get one here.

What you do get is your data, in bulk, whenever you want it: a full organisation export covering every record type, and per-patient record exports. That is enough for a migration, an audit, an attorney’s request or a family asking for their own record — and it is not enough to stand in for a live interface, which is why it is stated this way round.

If an integration list is what decides your purchase, this is a reason to rule us out now rather than three months in. Practices that exchange nothing but their own records with their own biller are the ones this fits.

Guides for leaving a specific system

Each of these covers what is particular about that migration — what tends to be at risk, and the order to do things in:

From CentralReach — the program and goal library
From Motivity — program structure mapping
From Raven Health — authorizations mid-period
From SimplePractice — structured data against documents
From TherapyNotes — notes and treatment plans
From WebPT — sequencing a business-model change
From Jane — standing appointments

Common questions

How long does a migration take?

The import itself is fast; preparing the CSVs is the work, and it is usually measured in afternoons rather than weeks. Most of the elapsed time goes into getting a clean export out of the outgoing system and reconciling what its columns mean against what yours do.

Can both systems run at once during the transition?

Yes, and for most practices they should for one billing cycle. The outgoing system keeps historical records and any in-flight payments; new visits document and bill from here. Running in parallel is also the only honest way to evaluate, because a demo shows you the product working and a parallel run shows you your practice working.

What happens if a row fails validation?

The whole run refuses rather than importing what it can. You get a per-row verdict naming the column, the row number and what is wrong, you fix the source file, and you run it again. Nothing is written to the practice until a run passes cleanly.

Do historical notes come across as structured data?

Generally no, from any system to any system. Historical notes, plans and assessments arrive as documents attached to the client record, because the structure they had belonged to the software that created them. Expect them to be readable rather than searchable.

Is migration a paid service?

No. The import centre is part of the product rather than a services engagement, and MegAligna charges per active clinical seat regardless of how much data arrives with you.

Try it end to end with test data

14 days, no card required. Use made-up patients while you evaluate — real patient information waits until a business associate agreement is in place.

Start a 14-day free trial See pricing