Switch from CentralReach: the notice clock and your export

Start with the renewal date, not the data

CentralReach’s published terms of service set the calendar for a departure. A subscription runs for 12 months and renews for another 12 unless either side gives written notice at least 45 days before the current term ends, and the terms state that the customer has no early termination right, unless your own Order says otherwise. Notice goes to CentralReach by email.

So the first job is to find your Order and your term end date. Everything below hangs off it: the export has to be done before the term ends, the parallel billing cycle has to fit before it, and missing the 45-day window can mean another year. Read your own contract, because an Order can override the standard terms.

What the terms say about your data

The same terms put the export squarely on the agency. The customer is “solely responsible” for exporting all of its content before the agreement ends (or the last billing cycle closes). Exports come out as Excel, Word or CSV files depending on the module, and CentralReach support can help before termination, subject to any support costs.

After termination, CentralReach keeps customer content for at least 60 days as a safety margin. During that period, account access may be restricted and further export requests are made in writing. After it, the content may be deleted.

The practical reading: do the export during the last months of your term, from an owner-level login, and treat the 60 days as insurance rather than as the plan.

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 columns our program import expects, and what happens to rows that do not fit, are set out once in how the import centre works.

Keeping authorizations and claims whole

In-flight claims adjudicate in CentralReach, and its configuration and permission structures stay there; neither is worth trying to move. Historical session notes and signed clinical records travel as documents for continuity and audit.

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. 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 CentralReach drain to read-only until the term ends. 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.