Switching from a cloud scribe: a clean migration checklist
Most therapists don’t leave a cloud documentation tool because of one dramatic event. It’s usually a slow accumulation: a price hike, a vague answer about where audio is stored, a privacy policy that quietly changed, or a colleague’s offhand “wait, your sessions go where?” Whatever the trigger, the decision to switch from a cloud AI scribe to a local one raises a practical question that the marketing rarely addresses: how do you move without leaving a mess of orphaned data, broken consent, and notes you can no longer reach?
This is a checklist for doing it cleanly. It assumes you already have a documentation approach you trust on the clinical side; the work here is the migration itself. None of it is glamorous, but skipping a step is how you end up with protected health information sitting in an account you forgot you had.
Step 1: Export everything before you cancel anything
Cancellation and deletion are not the same as access. The moment you downgrade or close an account, you may lose the ability to retrieve your own records — sometimes immediately, sometimes after a short grace window. So export first, always.
- Pull your finished notes in the most portable format offered — PDF for a fixed record, plus a structured export (CSV, JSON, or DOCX) if you want to reuse content.
- Capture metadata you’ll need later: session dates, client identifiers (initials or your internal IDs, not full names), and note types.
- Check for hidden artifacts. Many cloud scribes retain raw audio, machine transcripts, or “AI suggestions” separate from the final note. Export or confirm the disposition of each.
- Verify the export opens on your own machine before you do anything irreversible. A corrupted ZIP discovered after deletion is a bad day.
If your records will live in an EHR rather than the scribe, confirm the finalized notes are actually committed there — not just drafted — before you treat the scribe as disposable.
Step 2: Request deletion in writing, and get confirmation
Exporting your copy doesn’t remove the vendor’s copy. Under most data-protection frameworks and your BAA, you can request deletion of the data they hold. Do it explicitly and keep a record.
Ask not only “will you delete my data” but “what, exactly, will remain, and for how long?”
Cloud platforms frequently keep backups, logs, and de-identified derivatives after you delete the visible account. Get the specifics in writing: what is purged, what is retained, the timeline, and whether anything was used to train models. This matters beyond your own peace of mind — if you’ve ever wondered what happens to your notes if the vendor shuts down, the answer usually lives in these same retention clauses you’re now reading closely for the first time.
Step 3: Reconcile retention obligations against vendor deletion
Here’s the tension most migration advice skips. You have a legal and ethical duty to retain clinical records for years — the exact period varies by state, license, and payer. The vendor’s deletion is about their copy. Your retention duty is about the authoritative record, which should now be in your possession or your EHR.
Before you trigger deletion, confirm:
| You are deleting | You are keeping |
|---|---|
| The vendor’s hosted copy of notes and audio | Your exported, signed notes in your own system |
| Account access and billing | The full retention period’s worth of records |
| Raw audio you no longer need | Anything a payer audit or board could request |
Retention rules genuinely differ across jurisdictions and payers, so confirm your specific obligations with your board, your malpractice carrier, or an attorney before purging anything; treat this as a prompt to check, not as legal advice. The goal is simple: never let a vendor’s deletion create a gap in records you’re required to hold.
Step 4: Update your consent forms and notice of privacy practices
If your old consent language named a specific cloud vendor, described data leaving your office, or referenced third-party processing, that language is now inaccurate. Update it before your first session on the new workflow.
- Revise the informed consent for recording and AI-assisted documentation to reflect the new reality — for example, that audio is processed on your device and not transmitted to a third party.
- Update your Notice of Privacy Practices if it referenced the old subprocessor.
- For active clients, decide whether a brief re-consent conversation is warranted. Often a short, plain note at the next session is enough; document it.
This is also a good moment to reread your own forms with fresh eyes. A consent form written for a cloud tool tends to over-promise on security in ways an on-device tool makes simpler to state honestly.
Step 5: Stand up the new local workflow before you need it
Don’t migrate on a Monday with six clients booked. Run the new system once or twice in low-stakes conditions first.
- Do a dry run. Record or dictate a mock session, generate a draft (SOAP, DAP, or BIRP), and walk it end to end. Confirm the draft is yours to edit and sign — the tool produces a starting point, not a finished note, and you remain the author of record.
- Set your audio retention. Decide whether audio auto-deletes after you finalize, and configure it. On-device tools let you keep this deliberately short.
- Confirm the privacy posture. With a local tool, “where does the audio go” has a literal answer: nowhere. No account, no cloud, no telemetry. That changes the question you answer in an audit from “is the vendor trustworthy” to “is my Mac secured” — a problem you already know how to solve with disk encryption and a strong login.
- Sort your backups. Local-first means you own continuity. Set up an encrypted backup of your notes so a lost laptop isn’t a lost record.
If you’re still comparing options at this stage, a side-by-side of how on-device and cloud approaches differ on data flow and ownership is worth the half hour — that’s what our comparison page is built to make legible.
Sequencing the switch from a cloud AI scribe
The order matters more than any single step: export, verify, then delete; reconcile retention before purging; update consent before the first new session. Reversing those is how PHI gets stranded or records get gapped.
Switching documentation tools is mostly logistics, not drama. Done in this order, the migration is reversible at every point until the final deletion — and once you’ve moved to a workflow where the recording never leaves your machine, the recurring worry about a vendor’s servers, breaches, and shutdown notices quietly drops off your list. CouchNotes is built for exactly that endpoint: a local draft you review and sign, with nothing sent anywhere. But the checklist above is worth following whatever you switch to, and the discipline it asks for — know what you’re keeping, know what you’re deleting, and never let one depend on the other — outlasts any single tool you choose.