Switching ABA Platforms: What Migration Actually Involves

Nobody switches ABA software for fun. Practices switch because billing is leaking money, clinicians are fighting the data tool, or the platform they bought at ten clients is failing at sixty. And then they hesitate — sometimes for years — because migration feels like moving houses while the kids are still in them. Vendors on both sides of the decision have incentives to distort how hard this is: your current vendor wants it to sound impossible, the new one wants it to sound like a weekend. Here’s the version with no incentive attached.

Before anything: read your contract and test your exports

Two documents determine your leverage: your current contract and your data. Check the contract for the renewal date, the notice period (missing a 60- or 90-day notice window can cost you a full year), and anything about data export on termination. Then actually run the exports — client demographics, authorization history, session data, clinical programs — and open the files. What you can export cleanly today is what you’ll have when it matters. If exports are limited, ask your vendor in writing what they provide at offboarding; put the answer in the decision file.

What typically transfers — and what typically doesn’t

Plan around this rough reality, and verify it per-vendor in demos:

Usually transfers well: client demographics and contacts, payer and authorization records (often via re-entry or import templates), staff records, document files.

Transfers with effort: historical session data — often arriving as exports you archive rather than data that lives natively in the new system’s graphs.

Often doesn’t transfer: clinical program structures and targets built in the old system’s format, historical graphs as interactive data, custom templates and workflows. Teams commonly rebuild active programs in the new platform and archive the old data for reference and audit.

The practical implication: the question isn’t “will everything move?” — it won’t — it’s “what do we need live in the new system versus archived and retrievable?” Payers and auditors care that you have historical records, not that they live in your current software.

The billing cutover is the part that bites

The single most important operational decision is how you handle accounts receivable. The standard pattern: run new claims through the new system from a chosen cutover date, and work the old AR down in the old system until it’s collected or written off. That means a period of operating both systems — budget for the overlap in both subscription cost and biller attention. Ask your new vendor exactly how mid-authorization transitions work, and tell your payers nothing changed clinically: same providers, same services, new plumbing.

People, not data, decide whether it works

Migrations fail socially more often than technically. The pattern that works: pick a go-live date in your slowest season, train a small champion group first (one BCBA, one RBT, one biller), let them find the sharp edges, then train everyone else with the champions in the room. Expect two to four weeks of productivity dip and say so out loud in advance — surprise frustration converts to resistance, predicted frustration converts to patience.

A realistic timeline

For a small-to-mid practice, the honest range is 60–90 days from signed contract to stable operations: two to three weeks of setup and configuration, two to four weeks of parallel running and training, then a cutover and a stabilization tail. Larger multi-site organizations should think in quarters, not weeks. Any vendor promising a one-week enterprise migration is selling something.

When staying put is the right call

Switching costs are real, so the bar should be too. Staying is often correct when the pain is a training problem wearing a software costume (many “platform problems” dissolve after proper admin configuration), when you’re mid-audit or mid-payer-transition, or when the feature you’re chasing is on your current vendor’s near-term roadmap and they’ll commit to dates in writing. Switch when the pain is structural: pricing that scales against you, clinician adoption that never materialized, or billing capability your growth has simply outrun.

The short checklist

1. Contract: renewal date, notice window, export rights — in writing.
2. Export everything today; open the files; archive a copy.
3. Choose the AR strategy: new claims in new system from cutover date; old AR runs down in old system.
4. Champion group first; slow season go-live; announce the dip before it happens.
5. Keep the old system in read-only or archived form as long as audit requirements demand.
6. Only then cancel — after the last old claim is resolved.

This guide is editorially independent — no vendor wrote, paid for, or previewed it. If you’ve been through a migration and learned something this misses, tell us and we’ll fold it in.