A data migration looks like a technical detail until some records disappear without a trace or someone gets an email about a long-closed request. In a medical project that data is the history of patients' requests, and these mistakes are expensive.
I moved the support desk of a US psychiatric practice from Zoho Desk to Zendesk: 14,299 tickets and about 35,700 messages. Here is what I now treat as non-negotiable.
1. A migration must not touch people. Creating a ticket in Zendesk the normal way sends a notification. For an archive, that would mean emails to patients about old requests. So I used Zendesk's import API: tickets arrived with their original dates, senders and statuses, and no patient received a notification. Before any migration I first find out which side effects the target system triggers when a new record appears.
2. One block first, then the rest. The first archive block showed that an oversized request fails silently as a whole batch. I switched to batching by payload size, and the success rate held at 99.6%. Had I run the whole archive at once, I would have found the problem much later.
3. The importer's report is not proof. The tool that moves the data also counts its own successes. I checked the result with a second, independent count. All 199 active tickets arrived with zero failures.
4. Old conversations must read the same. Every email became its own comment, so staff see each request the way they saw it before.
5. Test data is synthetic only. This holds across the whole project. Testing runs only on synthetic records and DrChrono sandbox patients. Alerts, logs and the audit trail carry record IDs only, never patient details.
6. When the match is not exact, stop. The riskiest point in the medical records flow was a duplicate chart. DrChrono hides inactive patients from a normal search, so the flow searches by date of birth including inactive records. When the match is not exact, it stops and leaves a note for staff instead of guessing.
Silence is a signal too. A failure does not always look like an error. So any lead without a CRM record after 24 hours raises an alert, and the failure monitor has a separate alert for silence during clinic hours.
A short checklist before a migration
- Which notifications and automations will the new system fire when a record appears?
- A trial block before the main run.
- An independent count of the result.
- Synthetic data only in tests.
- No personal data in alerts and logs.
- An inexact match goes to a person.