Telehealth subscription migration, whether you are switching platforms or switching payment processors, requires three separate workstreams: moving customer records, arranging payment-data portability, and rebuilding the rules that govern future charges. A spreadsheet of patients does not move a subscription, and a payment token should not be assumed to work in a different processor or account.
For a US cash-pay brand, the objective is a controlled handoff. Each renewal should have one authorized billing owner, a correct amount and date, and a traceable relationship to the patient’s service.
Identify the systems that actually control billing
Before setting a cutover date, identify your payment processor, merchant account, subscription engine, patient platform, and source of billing consent. These may be operated by different companies even when staff use a single dashboard.
Ask the current and receiving providers to confirm the supported transfer route. One payment processor’s migration documentation describes processor coordination and payment-data mapping as part of its migration process. That is evidence for that processor’s workflow, not a guarantee that another vendor supports the same transfer.
Do not ask your staff to export raw card numbers into ordinary files or email. The processors should define the secure route and the required responsibilities. If transfer is unavailable, plan an approved process for patients to provide a new payment method.
Build a migration inventory
Create a record-level inventory before copying anything. Assign a stable internal patient identifier that can be mapped to both systems. Avoid matching people solely by name or an email address that may have changed.
| Record | Fields to preserve or reconcile | Owner |
|---|---|---|
| Patient account | Internal ID and source-system references | Data lead |
| Payment relationship | Processor customer ID and payment-method mapping | Payments lead |
| Subscription | Price, interval, next charge, status | Billing lead |
| Adjustments | Discounts, credits, pauses, cancellations | Finance and support |
| Consent evidence | Applicable terms, timestamp, recorded action | Compliance lead |
| Open balance | Invoice, payment attempts, dispute status | Finance |
Use the data export checklist for the broader record set. Keep permissions limited to the people who need each category of data.
Preserve the meaning of each subscription
Two systems may use the same status label differently. “Active” might describe a billing schedule in one product and a clinically enrolled patient in another. Build a mapping for behavior, not just labels.
For every subscription type, document the next intended charge, whether an invoice already exists, whether collection is paused, and whether a cancellation is scheduled. Record prepaid service periods separately from recurring charges so a patient is not charged again for a period already paid.
Some processors treat subscription import as a distinct migration stage. This illustrates why moving payment details alone is insufficient. Your destination still needs the commercial terms and schedule that tell it when and what to bill.
Test edge cases before the normal case goes live
A clean test account is useful, but it will not reveal all migration risks. Use synthetic cases that represent:
- A patient with a future renewal and no outstanding balance.
- A paused subscription with a planned restart date.
- A cancellation that takes effect at the end of a paid period.
- A failed payment with an existing retry schedule.
- A prepaid plan and a partial refund.
- A discount that expires after the next charge.
For each case, compare the source record, imported record, expected next action, and actual test result. The subscription billing guide provides a framework for defining those actions.
Give every renewal one billing owner
Set a precise cutover boundary, including time zone. Decide which system handles invoices created before that boundary and which handles new renewals afterward. The systems may coexist during transition, but they should not independently charge for the same service period.
Start with a pilot covering different renewal dates and statuses. Select the accounts for coverage of meaningful scenarios rather than convenience alone.
Reconcile scheduled charges before enabling live collection. Record sign-off from payments, finance, and operations. Keep a list of excluded accounts that need manual resolution and explain who will contact those patients.
Monitor the first full renewal cycle
Track duplicate charges, missing renewals, unexpected amounts, failed payments, patient inquiries, and mismatched account IDs. Compare results with the expected schedule, not just aggregate revenue. Matching revenue totals can hide one patient charged twice and another not charged at all.
Use the failed-payment recovery workflow for collection exceptions. Avoid adding an emergency retry process that competes with the processor’s existing schedule.
If clinical records or prescriber relationships are also changing, coordinate that work through the active-prescription migration plan. Billing success does not prove that care continuity has been preserved.
Frequently asked questions
Can payment tokens be transferred when switching payment processors?
No. Portability depends on the processor, account structure, token type, contractual rights, and receiving system. Obtain written confirmation of the supported route before promising patients a seamless transfer.
Do patients need to enter their cards again?
Sometimes. If a supported transfer cannot be completed, the receiving service may need a new payment method. Design a secure update flow and communicate clearly without requesting card details through email.
Can we keep both billing systems running?
They can operate during a controlled transition if responsibility is explicit. Each invoice and service period needs one billing owner, and competing automatic renewals must be prevented.
What makes a migration complete?
Completion means records reconcile, renewal behavior is verified, exceptions have owners, and old access and billing processes are retired according to the approved plan. An import-success message is only one checkpoint.
