Migrating practice management software: how it works

The four imports, and what each one needs

The import centre sits in practice settings and takes one CSV per record type. Import clients first: authorizations and programs attach to a client by MRN, so a row naming an MRN the practice does not hold yet is refused.

Import	Required columns	Optional columns	What it creates
Clients	First name, last name, MRN	Preferred name, date of birth, status	One client per row. An MRN that already exists in the practice, or appears twice in the file, is flagged.
Staff	Email, role	Display name	An invitation per person, sent the moment the row imports.
Authorizations	Client MRN, start date, end date, service code, authorized units	Authorization number, period (week, month or total), modifiers	Rows sharing an MRN, authorization number and dates become one authorization with several service lines.
Programs and goals	Client MRN, title	Type (goal, objective, program or target), measurement method, description	Items on the client’s current treatment plan, or on a new draft plan for a clinician to review and activate.

A few details decide whether a real export goes in cleanly:

Dates are accepted as YYYY-MM-DD or M/D/YYYY. Two-digit years are refused rather than guessed, because 3/4/26 could be 1926 or 2026.
Authorizations have no “units used” column. An authorization that is part-way through its period on cutover day needs its remaining units worked out first, from your session records and payer statements, and entered as the figure to carry forward.
Measurement methods for programs are trial, task analysis, frequency, duration, rate, latency, partial interval, whole interval and momentary time sampling. A program library that used other labels needs them translated in the spreadsheet.
Staff rows send real email. Each one goes out through the same invitation as the roster’s invite button, so a staff import cannot be taken back.

The program library deserves the most time of the four. Rebuilding it by hand is the most common reason a practice stays where it is, and the reason it is an importer here rather than a services engagement with a quote attached.

How the dry run handles a bad row

Every run starts the same way: upload the file (up to 5,000 rows), confirm which of your columns maps to which field, and validate. Headers are matched automatically only when they are an exact, known spelling. Anything ambiguous is left for you to map, because a wrong guess that put “provider” into “preferred name” would quietly damage a roster.

Validation checks every row against the same constraints the database enforces and gives a verdict per row: the row number as your spreadsheet shows it, and what is wrong with it. Nothing is written at this stage. If a required column is not mapped at all, nothing can be imported.

Rows with problems are skipped, not forced through. You can import the rows that passed and download the rest as a CSV: your original columns, untouched, with a column saying what was wrong. Fix that file and run it again. Changing the file or the mapping throws away the earlier verdicts, so nothing is ever written in a shape that was not validated.

Client, authorization and program imports can be undone after the run. Undo retires the records rather than deleting them (clients discharged, authorizations cancelled, plan items discontinued), and the audit trail keeps both the import and the undo. Staff imports have no undo, for the reason above.

In practice a migration is a loop rather than a single event. Most of the elapsed time goes into the source spreadsheet, and going round it twice costs very little.

What does not go through the importer

Appointments and recurring schedules, session-by-session data, notes, treatment-plan narratives, claims and payment history have no CSV import. They reach MegAligna in one of two ways, or they stay behind:

As documents on the client’s chart. Files are uploaded one at a time to each chart: PDF, image, text or Office documents, up to 25 MB each. They are readable and retained, not searchable as structured data.
Re-entered where they are still live. A standing appointment, an active treatment plan or a future session is rebuilt in the new system, because it is something the practice is still acting on.
Left with the outgoing system as the historical record, which is often the right answer for claims that are still adjudicating there.

Which of those is right for older history depends on your retention obligations, not on what is convenient to move. Plan for the last couple of years of notes being readable rather than searchable, from any system to any system.

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. The guides below say what each vendor’s own documentation promises about its export, and where it says nothing.

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 covers what that vendor’s own documentation says about getting your data out, and the part of that particular move most likely to go wrong:

From CentralReach: the renewal notice clock and the program library
From Motivity: program structure mapping
From Raven Health: authorizations and the managed-billing tail
From SimplePractice: what the Complete export leaves out
From TherapyNotes: exporting before the retention period ends
From WebPT: sequencing a business-model change
From Jane: standing appointments and prepaid packages

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?

It is skipped, and you see why: the row number and the problem, per row. You can import the rows that passed, download the failed ones as a CSV with the reason in its own column, fix them and run that file again. Client, authorization and program imports can be undone afterwards; staff imports cannot, because each row sends an invitation email.

Do historical notes come across as structured data?

Generally no, from any system to any system. Historical notes, plans and assessments are uploaded as documents on 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.

Run a practice import with made-up records

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