What a Platform Has to Prove Before an ABA Provider Will Switch

Part Two of MissionViewpoint's series: The Economics of Switching Practice Management Platforms

In the first article in this series, I argued that most ABA providers don't switch practice management platforms because another product is marginally better.

They switch only when the improvement is large enough to justify the cost and disruption of changing the operational foundation of their organization.

That raises the next question. If switching is that difficult, what does a platform actually have to do to earn a provider's business?

The obvious answer is to build better software. I don't think that's enough.

A platform isn't primarily competing against other platforms. Most of the time it's competing against the provider's decision to stay exactly where they are. And, staying seems (relatively) free and familiar. That competitor (inertia) doesn't need a roadmap or a demonstration.

It only needs the alternative to look like more trouble than it's worth.

So the bar isn't "better." Providers already concede that another platform may have more features; they concede it constantly, and then renew anyway. The bar is better by a margin wide enough to cover the cost of getting there. And most of the work of clearing that bar happens in places that never appear in a product comparison.

Three things determine whether a platform clears it.

• Who it's actually built for.
• Whether it takes responsibility for the departure.
• And whether it lets the provider keep building afterward.

"Better enough" means something different at every stage

There is no standard answer to what a platform has to deliver, because there is no standard provider.

The five stages from Part One aren't just descriptions of technological maturity. They're five different purchase decisions, with five different things standing in the way, and a platform that clears the bar for one may not come close for another.

Worse, some of the requirements are in tension. The capabilities that win the entrenched are not the capabilities that win the builders, and a platform that tries to be both usually ends up being neither convincingly.

It's worth taking them in order, because the difficulty rises as you go — and so does the value of getting it right.

The holdouts are the only segment where the conventional sales motion still works. There's no incumbent to displace, no accumulated workarounds to unwind, no institutional muscle memory to overcome. The demonstration really is the argument.

This is also why platforms over-index on them: they're the easiest deals to run, the shortest cycles, and the cleanest references. But the segment has dwindled to a rounding error, and a go-to-market strategy built around greenfield in a market that is almost entirely brownfield is a strategy running out of room.

The stranded want evidence of commitment, and they have learned to distrust the usual forms of it. A provider on a platform that was once purpose-built for autism care and has since become a minor vertical inside a multi-specialty portfolio has already sat through the roadmap presentation. They heard the reassurance the year of the acquisition. They watched what shipped afterward.

So the claim they're evaluating isn't "we care about ABA." It's "we will still care about ABA in five years, after the capital structure changes."

Roadmap slides don't answer that. Allocation does. Where the engineers actually sit. What shipped for autism care specifically over the last several release cycles, as opposed to what shipped for behavioral health generally and was described as applying. Whether the people making product decisions have ever run an authorization or defended a treatment plan. Whether ABA is the product or a segment of it.

That last question is the one this group is really asking, and most vendors answer it accidentally, in the first ten minutes, by which vocabulary they reach for.

The entrenched are the largest opportunity and the hardest one, and their requirement is almost entirely about departure rather than arrival.

These are providers who standardized years ago on one of the sector's default operating systems and have spent the intervening years building around its limits — the spreadsheets, the custom reports, the exports that get reassembled somewhere else, the workflows that exist because the software required them. The platform works. It is also, by now, load-bearing in ways nobody has fully documented, and getting at their own data is harder than it should be.

What they need isn't a better feature set. They can see the better feature set. What they need is for someone to take responsibility for the extraction — to name what moves, what stays, what their outgoing contract has to permit, and what the first ninety days actually look like. Their switching cost is the highest in the market, which makes them the segment where reducing the cost of change is worth the most, and the segment where almost nobody has invested in doing it.

The builders need the opposite of attention. They've stopped waiting on their platform and started constructing an operating layer around it — data warehouses, decision-support tools, custom applications, increasingly things assembled quickly by people who are not engineers. They're not looking for a vendor to solve their problems. They're looking for one that won't get in the way.

Their requirement is structural, and it's mostly about what the platform promises not to do. Full read and write access to their own data, at a rate limit that supports operational use rather than nightly reporting. Stable interfaces that don't break the things they've built. Pricing that doesn't penalize API volume, since metered access to your own records is a tax on the exact behavior the provider is trying to develop. And some assurance that the capability they build this year won't be absorbed into the platform's roadmap next year and offered back to them as a module.

That last concern is real and rarely addressed. A provider who builds something genuinely differentiating on top of a vendor's data is placing a bet on that vendor's restraint. Most vendors have given them no particular reason for confidence, and the ones that have — explicitly, contractually — are competing on something no feature list can express.

The explorers are evaluating the newest cloud-native platforms, or wondering whether AI-native systems will redefine the category entirely. They're the hardest group to serve, because what they're buying is a decade and the evidence for a decade does not exist yet.

They'll ask about architecture, and they should. But the questions that actually discriminate are less technical. Whether the company's funding structure permits a long build or requires an exit on someone else's timeline. Whether the platform's design assumes today's service model — today's codes, today's supervision ratios, today's site-of-service assumptions — or treats those as variables. What happens to their configuration when the underlying model changes, as it will.

The uncomfortable truth is that this group is making the least evidence-supported decision in the market while believing they're making the most sophisticated one.

Read across the five and the tension becomes obvious. Serving the entrenched well requires migration muscle, deep familiarity with the incumbent, and a willingness to absorb operational complexity on the provider's behalf. Serving the builders well requires the opposite instinct — a thin, open, deliberately unopinionated system that gets out of the way. Serving the stranded requires visible specialization. Serving the explorers requires an architectural bet that may not pay off for years.

Those are not the same prospects.

The platforms that attempt all of it simultaneously tend to produce something that clears no one's bar — comprehensive, unobjectionable, and insufficiently better than staying put for any particular provider to move.

The winning strategy probably isn't building the platform that's better for everyone. It's being unmistakably better enough for someone.

The dividing line is the authorization

That's the positioning question. The execution question is harder, and it's where I think much of the industry still gets it wrong.

Most platforms treat migration as an implementation project — or worse, as the provider's responsibility. Once the contract is signed, attention shifts to project plans, data conversion, and training schedules, with the provider expected to decide what should be migrated, which workflows should change, which reports need recreating, and how years of undocumented operational knowledge fits into a new system.

If fear of disruption is the single largest reason providers don't switch, then reducing that disruption isn't a professional services deliverable. It's the product.

And every migration eventually reduces to a question almost no one asks directly: what has to be live in the new system on the first day of operation, and what merely has to be findable somewhere?

Those are different requirements, and conflating them is what makes migrations expensive.

The reflexive answer is that everything matters. In a sense that's true. Historical claims matter when a payor opens a records request. Two-year-old session notes matter when an audit letter arrives. Terminated employees' credentialing history matters when someone asks who was supervising a case in a prior authorization period. Or you face a class action labor lawsuit. None of it is disposable.

But almost none of it has to be 'live'.

The authorization is the natural dividing line because it's the smallest unit of operational obligation a provider actually carries. It defines who is being served, by whom, under what payor, for what service, for how long, and at what remaining balance.

Every operational function downstream — scheduling, staffing, supervision, documentation requirements, billing, revenue recognition — hangs off it. An authorization that is still running is work the organization owes someone tomorrow. An authorization that has closed is evidence.

Work becomes obligation. Evidence becomes reference.

That distinction is the entire migration plan.

One row, walked through the cutover

Consider a single client with an authorization running through the end of the following quarter. It carries approved units across two or three service codes, a delivered-to-date count, a remaining balance, a date span, a payor, a plan, and a set of rendering providers attached to it.

Underneath that sit the constraints that govern how the units may actually be used: which credentials are required to render each code, whether supervision may be billed concurrently with direct service, how the payor rounds partial units, which modifiers apply, and whether the authorization is enforced as a hard cap or a soft target.

On day one in the new platform, all of that has to be true and enforced. Not migrated — operational. The scheduler has to be prevented from booking against a code the assigned technician isn't credentialed to render.

The remaining balance has to be right, because a balance that's wrong by forty units is either revenue the provider never collects or a denial that arrives ninety days later. The supervision rules have to constrain the calendar, not sit in a policy document.

Around that row, a small number of records must come with it. The client's demographics, active insurance record, consents, and diagnosis. The staff assigned to the case, with the credentials that qualify them for it. And a clinical snapshot thin enough to be surprising: the current behavior plan, the active programs and targets, and enough baseline for the next data point to be interpretable.

Not the treatment history. The treatment 'state'.

Clinical continuity requires knowing what a client is working on right now and what the last several data points looked like. It does not require three years of graphed acquisition data to be re-rendered in a new system's charting engine — which is, reliably, the single most expensive and least successful part of any conversion attempted at full scope. The history is evidence. It belongs where evidence belongs.

Everything else stays behind. Closed authorizations. Adjudicated claims and their remittance history. Session notes from prior authorization periods. Terminated staff. Reports that existed only because the old platform couldn't answer a question the new one answers natively.

The legacy system doesn't get decommissioned. It gets demoted.

This is the part that reframes the economics, and the part vendors rarely put in a proposal.

Keeping the outgoing platform available in a read-only capacity — through the claims runout, the appeal window, and whatever record-retention period the provider's state licensure and payor contracts actually require — is almost always cheaper than converting the data those obligations attach to.

It is also dramatically lower risk, because a read-only legacy instance is, by definition, already correct. Nothing has been transformed, so nothing can be transformed wrongly. When an audit letter arrives eighteen months later, the record it asks about is sitting in the system that produced it, in the format that produced it, with the metadata that produced it.

Providers resist this, understandably. Paying two vendors feels like failure. But the comparison isn't a maintenance fee against zero. It's a maintenance fee against the cost of converting years of inactive clinical and financial data, validating that conversion, and then defending the converted version to an auditor entitled to ask why a note's timestamp changed.

That's the arithmetic. It usually isn't close.

It requires the outgoing vendor to permit it, which is its own market signal. A platform whose commercial model depends on making departure structurally difficult — where the export is partial, the archive is priced punitively, or read-only access simply isn't offered — has told the provider something about the relationship - and how they perceive those serving a vulnerable population.

Why this is harder than a professional services engagement

Naming the dividing line looks like a data exercise. It isn't. It's operational diligence.

Deciding what moves requires knowing which of a provider's practices are payor requirements, which are state regulatory requirements, which are genuine clinical best practice, and which are workarounds that exist because the outgoing software couldn't do something.

Those four categories look identical from the outside. They live in the same spreadsheets, the same custom reports, the same "this is just how we do it" explanations from the operations team.

An implementation consultant reading a schema cannot tell them apart. Someone who has replaced the same platform eleven times can, because the same workarounds often appear in every organization running it.

That pattern recognition is the asset — and it's a different asset than data mapping, staffed differently, priced differently, and sold differently.

Which is why most platforms don't have it. Migration sits inside professional services, gets scoped as an implementation project, and gets measured on whether it finished on schedule rather than on whether the provider is operating better.

The vendor that can walk into a diligence conversation and say here is what we would move, here is what we would leave, here is what your legacy contract needs to allow, and here is why — before the contract is signed — is not selling the same product as the vendor promising a comprehensive data conversion.

It is selling a smaller migration. Which is the only kind that consistently works.

The platform is judged by what happens outside it

The third question is what the provider is able to do once they've arrived.

AI has become the dominant competitive theme in practice management software. Every platform has a roadmap; many already ship documentation assistants, scheduling recommendations, claims reviews, automated workflows, and generated reports.

Those capabilities matter. But they share an assumption worth questioning — that AI is something that lives inside the platform.

The advantages that prove durable will come from what providers build around it. As organizations develop operating layers connecting practice management, CRM, HR, recruiting, finance, business intelligence, and clinical systems, AI can begin supporting decisions no individual application could support alone.

• Recruiting ahead of demand because referral growth, payor mix, and margin trends suggest expansion is coming.
• Identifying markets where hiring should accelerate before scheduling capacity constrains it.
• Connecting clinical outcomes to recognition and incentive programs.
• Engaging families through workflows that deliver personalized content based on what's actually happening clinically.

Those aren't software features. They're organizational capabilities, and they don't belong inside a single practice management platform — a point I've made at length elsewhere, and one that hasn't gotten less true. Connected systems aren't the objective. Connected decisions are.

So the platforms that create the most long-term value may not be the ones that build every capability themselves. They may be the ones that make it easiest for providers to build capabilities no competitor can easily replicate.

Which brings the argument back to where it started. The real competitor isn't another platform. It's inertia — and inertia is beaten by lowering the cost of change, not by raising the ceiling on features.

The platforms that consistently win won't simply build better software. They'll reduce the total cost of changing: financially, operationally, strategically. And they'll offer something more valuable than a feature set, which is the freedom to keep innovating.

Providers won't differentiate themselves because their practice management platform has better features. They'll differentiate themselves because it became the foundation for an operating layer where AI, analytics, automation, and proprietary operational knowledge can evolve independently of the platform underneath.

That's a much harder capability to copy. And ultimately, it's a much more compelling reason to switch.

In the final article of this series, I'll turn back to the provider's perspective. If you're considering replacing your practice management platform, how should you evaluate the decision, reduce migration risk, and choose a technology partner that will continue to support your organization as it evolves?