Brightree is the dominant DME platform for a reason — it's deeply integrated, widely supported, and covers every workflow. That's also exactly why migrating away from it is genuinely hard. Here's what the decision and the process actually look like.
If you're reading this, you're probably frustrated with Brightree. The cost, the complexity, the support responsiveness, the feeling that you're paying for a platform built for a distributor 10x your size. Those frustrations are legitimate — and widely shared among small and mid-size DME operations.
But before you start a vendor evaluation, it's worth being honest about what you're actually evaluating. Switching your DME platform is not a software upgrade. It's an operational migration — with real risks around billing continuity, data integrity, and staff transition. Done well, it's worth it. Done badly, it can generate more disruption than the original problem was causing.
This guide gives you the unvarnished version: what the migration involves, where it typically goes wrong, and how to evaluate whether the switch makes sense for your specific operation.
The common complaints about Brightree fall into a few categories:
Brightree's pricing is enterprise-tier. For large distributors processing thousands of orders, the per-transaction cost is amortized across volume. For a distributor doing 100 orders/month, you're often paying for capabilities you don't use, modules you don't need, and support SLAs that don't match your operational reality. The platform cost itself is often 4–8% of revenue for smaller operations — a real margin hit.
Brightree is built for complexity. The configuration surface area is enormous. That's a feature if you need it; it's overhead if you don't. Smaller operations often spend significant time in Brightree doing configuration work that doesn't create value — they're adapting to the platform rather than the platform adapting to them.
Support quality at enterprise platforms tends to correlate with account size. Small accounts often find response times slow, resolution quality variable, and escalation paths unclear. This is a common pain point that rarely improves over time.
Brightree's core architecture dates to the early 2010s. It works, but integrations are harder to build, the mobile experience is dated, and some workflows that modern operations expect (real-time eligibility, automated PA submission, AI-assisted denial management) require third-party layering rather than native capability.
Every DME platform migration has five phases. The timeline and difficulty of each varies by operation size and data complexity.
Patient records, prescription history, equipment on rent, resupply schedules, billing history, authorization records, payer contracts. Brightree will export most of this, but the format and completeness matter. Budget 2–4 weeks for data extraction and validation. Confirm export format compatibility with the receiving platform before you start.
The hardest phase. Patient data needs to import cleanly — especially active rentals, resupply schedules, and pending authorizations. This is where most migrations slip: data that "looks clean" in export has formatting inconsistencies, missing fields, or duplicate records that cause billing problems after go-live. Plan 4–6 weeks and budget for a dedicated validation pass.
Your clearinghouse connections and EDI payer enrollments are tied to your current platform. Some of these transfer; others require re-enrollment, which takes 2–6 weeks per payer. During this period, you may need to run parallel billing or accept delays on new claims. Plan this carefully — it's where billing disruption actually comes from.
A motivated staff member learns a new DME platform in 2–4 weeks for core workflows. Full proficiency across all edge cases takes 8–12 weeks. During the transition period, expect productivity to drop 20–30% as staff work through the learning curve. For small operations with 2–3 billing staff, this is a significant operational hit.
Running the old and new system in parallel for 4–8 weeks lets you validate that everything is working correctly before you fully cut over. This is the responsible approach — and it's also operationally demanding because staff are working two systems simultaneously. Plan for this period explicitly and don't try to accelerate past it.
Total realistic timeline from decision to full cutover: 4–6 months for a disciplined migration at a small-to-mid-size operation. Anyone telling you 6–8 weeks is either selling you something or hasn't done this before.
Before you start a vendor evaluation, get clear on these:
| Question | Why It Matters |
|---|---|
| What specifically is broken? | "I hate Brightree" is not a migration rationale. Identify the 2–3 specific pain points causing real operational or financial cost. |
| Can a point solution fix it? | If the problem is resupply outreach or denial management, a workflow tool layered on Brightree may cost 20% of a full migration and take 4 weeks instead of 4 months. |
| What's your compliance exposure? | Active CMS audits, pending appeals, or open authorization disputes dramatically complicate migration timing. Get those resolved first. |
| What does your staff bandwidth look like? | Migrations consume 30–50% of your billing team's capacity for 3–4 months. If you're already understaffed, this is a timing risk. |
| What's the contract situation? | Brightree contracts are typically annual or multi-year. Understand your exit terms before you start looking — termination penalties can be significant. |
If you've worked through the questions above and a full migration still makes sense, here's what to actually evaluate during vendor selection:
Who owns the migration? The vendor should have a documented migration process, reference customers who've migrated from Brightree specifically, and ideally a migration engineer who has done this before. "We'll help you figure it out" is not an answer. Brightree-specific migration experience matters because the data export format and known validation issues are platform-specific.
What happens to claims in flight during the transition? Active authorizations? Open denials? Get explicit answers on each, in writing. The vendor's job is to help you maintain billing continuity through the transition — not just to get software running.
Does the new platform support your existing clearinghouse (Availity, Office Ally, Change Healthcare)? What payers require re-enrollment and what's the timeline? This is the single biggest source of billing disruption in platform migrations — understand it fully before you commit.
Migration exit clauses matter. If the migration goes badly or the platform doesn't deliver what was promised, you want contractual recourse — or at minimum a month-to-month option after the initial migration period. Multi-year contracts with no exit path are a red flag in any software vendor relationship, doubly so in a migration context.
A few specific things to verify before you cut over from Brightree:
If a vendor can give you confident, specific answers to these questions, that's a good sign they've done this before:
If the answers are vague, escalate to their implementation team before signing. Sales teams often overpromise on migration; implementation teams are more realistic about what's involved.
Not every Brightree frustration requires a full migration. If your core billing workflow is functional but specific operations are underperforming — verification is too slow, resupply capture is low, denial management is manual — a workflow layer addresses those problems without the migration risk.
ScriptRelay is built to work alongside existing billing platforms for exactly this reason. Verification, intake automation, resupply outreach, and denial management can all improve independently of what's in your core system. Many operations run ScriptRelay in front of Brightree — using us for the patient-facing and intake workflows, letting Brightree handle billing. That's a $500/month decision, not a 6-month migration project.
If you've decided a full migration is the right call, we have the full Brightree comparison here, including the honest conversation about where Brightree is still stronger. And if you want to talk through whether migration or layering makes more sense for your operation, book a call — that's a conversation worth having before you start a 6-month project.
Talk through your specific pain points. Sometimes a workflow layer is the answer. Sometimes a full migration is. There's a right answer for your operation specifically.
Book a Consultation → See the Full Comparison