Switching EVV Vendors Without Disrupting Medicaid Billing: A Migration Checklist

Agencies switch EVV vendors for plenty of reasonable reasons: the current app is expensive relative to what it delivers, caregivers never fully adopted it, support is slow, or the agency has simply outgrown what it was built to do. None of those reasons are the hard part. The hard part is the week or two where two systems overlap, and a mishandled cutover can turn a good decision into a billing headache that outlasts whatever problem prompted the switch in the first place.

Here’s how to make the actual transition boring, which is exactly what you want it to be.

What’s Actually at Risk During a Switch

Before planning the mechanics, it’s worth being clear-eyed about what a bad migration actually costs:

• A gap in EVV data. Any visit that isn’t captured cleanly by either the old or new system during the transition is a visit that can’t be billed, full stop. This is the single biggest risk, and it’s entirely avoidable with the right sequencing.
• A sync interruption with HHAeXchange. If your new vendor’s Alt-EVV certification or integration isn’t fully live before you cut over, you can end up with visit data trapped in the new app with nowhere to go.
• Caregiver confusion. A roster that’s unsure which app to use on a given day, or logs into the wrong one out of habit, generates exactly the kind of exceptions covered elsewhere on this site, at the worst possible time.
• Losing access to historical data. If you don’t secure an export commitment from your outgoing vendor before you’ve fully left, you may find that data harder to get once you’re no longer a paying customer.

Before You Commit: The Pre-Switch Checklist

Confirm the new vendor’s Alt-EVV certification is actually live, not “in progress.” Ask for proof, not a timeline. A vendor that’s still finalizing its HHAeXchange integration is not ready for your cutover date, no matter how the sales conversation frames it.

Get a written commitment from your current vendor on data export. Confirm the format (CSV, API, something else), what date range is included, and how long the data stays accessible after you’ve canceled. Get this in writing before you give notice, not after, since vendors tend to answer this question differently once you’re no longer a prospective renewal.

Pick a cutover date that isn’t mid-pay-period. Switching mid-cycle means splitting a single pay period’s visit data across two systems, which makes reconciliation harder for no benefit. Align the cutover with the start of a new billing or pay period whenever the vendor timeline allows it.

Plan a short overlap window, not a hard cutoff. Running both systems in parallel for a few days, rather than flipping a switch on a single date, gives you a safety net if the new app has an unexpected issue in its first days live. This doesn’t need to be a full pilot; a few days of overlap is usually enough to catch anything serious.

Cutover Week

Freeze new visit entry in the old app at a clearly communicated date and time, and make sure every caregiver knows the exact moment the switch happens. Ambiguity here is where confusion creeps in.

Re-train caregivers on the new clock-in flow before, not during, their first shift on it. A five-minute walkthrough on a real phone beats any written instructions, and it catches confusion before it turns into a missed clock-in on a live visit.

Watch the exception queue closely for the first week. Expect a higher-than-normal exception rate in the first few days as caregivers adjust, and treat that as normal rather than alarming, as long as it’s trending down by the end of the week rather than staying flat.

Keep read-only access to the old system for a defined window, ideally 60 to 90 days, so your billing team can still pull historical records if a claim question comes up that references a visit from before the switch.

Mistakes Worth Avoiding

Switching without telling your billing team the exact cutover date. They need to know precisely when visit data starts flowing from a new source, or reconciliation at the end of the month becomes a guessing game.

Assuming the new vendor’s onboarding team will handle everything. A good onboarding process still depends on your agency doing its part: confirming caregiver rosters are accurate, client addresses are current, and schedules are loaded correctly before go-live, not after.

Canceling the old contract before confirming the new system is fully live. It’s tempting to end the old subscription the moment the new app is installed, but hold that cancellation until you’ve verified at least a few full days of clean visit capture and successful HHAeXchange sync on the new platform.

The Short Version

A vendor switch fails in the transition, not in the decision. Confirm certification before you commit, secure your data export in writing, pick a cutover date that doesn’t split a pay period, overlap the two systems briefly instead of hard-cutting, and keep close watch on the exception queue for the first week. Do those five things and the switch itself becomes the least eventful part of the whole process, which is exactly the goal.