How a CentralReach migration works
A CentralReach migration is three phases: export while you still have full access, map and import into the new system, and run one parallel billing cycle before the old subscription ends. Agencies that compress the third phase are the ones that end up reconciling authorizations from memory.
The program library is what you are really moving
Everything else in a CentralReach migration is tractable. Client demographics are demographics, staff are staff, and an authorization is a number with dates on it.
The program and goal library is different, and it is the reason agencies stay put for years after they have decided to leave. It represents accumulated clinical work — targets, mastery criteria, prompting hierarchies, the whole structure a team has refined per client — and rebuilding it by hand across a caseload is not an afternoon’s work. Any migration plan that treats it as an afterthought will stall at exactly that point.
So plan the library first and the rest second. Get it exported, look at what the columns actually contain, and decide before anything else whether it comes across as structure or as reference documents you rebuild against.
The mechanics of the import itself — the record types, the dry run, what arrives as documents — are the same for every source system and are covered in migrating practice management software.
What maps, and what does not
Maps as structured data: client demographics and guardian contacts, payer and authorization records with remaining unit balances, staff and credentials, program and goal libraries, and future scheduled sessions.
Arrives as documents: historical session notes and signed clinical records — they attach to the client chart for continuity and audit, but re-keying years of narrative into structured fields is neither realistic nor required.
Does not transfer: in-flight claims (they adjudicate in CentralReach), CentralReach’s own configuration and permission structures, and anything your export was never granted access to — which is why the export happens first, while an owner-level login still exists.
The cutover sequence that protects billing
Authorizations are the dangerous part: a unit balance that is right in the old system and stale in the new one produces over-delivery nobody catches. The sequence that avoids it: reconcile delivered units against your last payer statements, enter authorizations with their true remaining balances, schedule forward only in the new system from an agreed Monday, and let the old system drain to read-only. One agreed cutover date, no split weeks.
If you are still deciding rather than moving, the CentralReach comparison covers where each product is genuinely stronger, and what a CentralReach quote depends on covers the money. What the destination looks like for an ABA agency is ABA practice management software.
Common questions
How long does a migration actually take?
Will CentralReach export everything we need?
Can we keep read access to CentralReach afterwards?
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.