How to switch telehealth infrastructure without losing patients
The riskiest moment in a telehealth business is not launch — it is changing the infrastructure under an operating patient base. Done right, patients never notice.
Photograph via UnsplashMigrating telehealth infrastructure safely comes down to four rules: parallel-run the new stack before anything moves, transfer records as data but let clinicians re-establish prescriptions against refill dates, cut over state by state rather than big-bang, and keep the patient-facing experience constant. Refills are monthly — the whole plan has to fit inside that cadence.
Signs it is time to switch
Few teams switch infrastructure for fun. The patterns that actually force the decision: a vendor stack that grew to five or more contracts with seams between them (and you as the unpaid integrator); per-visit economics that stopped making sense at volume; states you cannot expand into because your clinical partner cannot cover them; a roadmap that stalled while your product needs kept moving; or an acquisition or shutdown notice from a vendor you depend on.
Whatever the trigger, the constraint is the same — refills are monthly, so any migration plan has to fit inside your patients' refill cadence. That single fact drives everything below.
The playbook
- Parallel-run before anything moves. Stand up your flows on the new stack in a sandbox while the old one keeps serving patients. Prove intake, visits, and fulfillment end to end with test patients first — including the unhappy paths (failed benefits check, pharmacy out of stock, patient in an edge-case state).
- Move records deliberately. Charts and care plans transfer as data. Prescriptions should not — the clinically clean approach is for clinicians on the new platform to review each incoming chart and re-establish prescriptions, timed against each patient's refill date so nothing lapses.
- Cut over state by state. Never big-bang. Move one market, watch a full refill cycle, then roll the rest in waves. A contained state is a recoverable state.
- Keep the patient experience constant. If patients live in your app and your brand, the switch is invisible — which is the strongest argument for owning your front-of-house rather than renting a white-label portal.
The migration risk register
Every telehealth migration has the same five risks. Name them in the plan and assign each an owner:
| Risk | What goes wrong | Mitigation |
|---|---|---|
| Refill gaps | A refill lands mid-transfer and neither stack fills it | Sequence moves by refill date; never move a patient inside their refill window |
| Prior-auth continuity | Covered patients need new PAs when the prescriber changes | Identify covered patients up front; start re-approvals before cutover |
| Data completeness | The export is missing fields you assumed existed | Audit a sample export against real charts before committing to a timeline |
| Support surge | Even an invisible migration produces questions | One-page FAQ and escalation path per phase, briefed in advance |
| The stragglers | Patients who never respond mid-migration | Decide up front how long the old stack stays warm and the final outreach sequence |
What to tell patients (and when)
If the experience truly does not change, most patients need no announcement at all — and over-communicating an infrastructure change can create worry where none existed. What patients must hear about, clearly and in advance: any change to their clinician, their medication source, their billing descriptor, or any consent they need to re-sign. Keep it in your brand voice, frame it as a care improvement, and give them one obvious way to ask questions.
The first 30 days after cutover
- Watch refill completion rate against your pre-migration baseline — it is the single number that says whether the migration worked.
- Track visit turnaround time and support ticket volume per state as each wave lands.
- Hold the rollback option open until every migrated state has cleared one full refill cycle.
- Only then wind down the old contracts — and take the export of your data on the way out.
What to negotiate before you start
- Data export from your current vendor — formats, completeness, and timing. This is the step that slips.
- Data ownership on the new platform — insist on API export rights from day one, so you are never locked in again.
- Overlap economics — you will run two stacks for a few weeks; price that into the plan.
- A rollback line — know exactly what "abort" looks like for each state until the cutover is proven.
Migrations are a first-class path onto Lithos: parallel-run in sandbox, records transfer, clinician-led prescription re-establishment, and state-by-state cutover at your pace. See the migration page for the full process.
Frequently asked questions
How long does a telehealth infrastructure migration take?
Typically weeks to a few months, driven by state-by-state waves and the rule that each wave clears a full refill cycle before the next — not by the data transfer, which is the fast part.
Will patients notice the switch?
Not if the front-of-house stays constant and the plan respects refill windows. Patients must be told about changes to their clinician, medication source, billing descriptor, or consents — the rest is your infrastructure, not their business.
Do prescriptions transfer between platforms?
Records transfer as data; prescriptions should be re-established by clinicians on the new platform, timed against each patient’s refill date so nothing lapses. That is the clinically clean path.
When is it safe to shut off the old vendor?
After every migrated state has cleared one full refill cycle at or above your pre-migration refill completion rate — and after you have taken a complete data export.
Get the Journal by email
Our best guides on building compliant telehealth programs — a couple a week, unsubscribe any time.
Running a telehealth program at scale, Part 2: eight signs you’ve outgrown your platform
Turnaround drifting with volume, state expansion blocked, data you can’t export, lapses you can’t see. The symptoms operators report, what each costs, and how to tell a platform problem from a process problem.
Read the guide
Running a telehealth program at scale, Part 1: unit economics at 1,000 encounters a month
Cost per encounter is the unit that matters once you have volume. The fixed and variable lines, how they move from 300 to 1,000 encounters a month, and the five levers that change margin.
Read the guide
Labs for telehealth programs: at-home kits vs. draw networks
How kits and draw sites compare on completion, panels, and cost — and how to build the lab loop so results actually gate care.
Read the guideFrom first call to first patient, in weeks.
A 15-minute intro call, sandbox credentials the same day, go-live in 3–4 weeks — new launches and existing patient bases alike.