Changing clinic software is not just a file upload. It is a controlled handover of context: identities, appointments, records, documents and the history your team relies on. A good migration makes uncertainty visible before it reaches the live clinic.
Start with the destination, not the export button
Write down the few journeys that must work on day one: finding an existing client, viewing the next appointment, locating the appropriate record, understanding an outstanding form and knowing what still needs human review. That becomes the acceptance checklist. A migration can contain thousands of rows and still fail if the clinic cannot safely complete those ordinary tasks.
Rytura’s planned migration support is therefore assessed case by case. It is not an automatic promise to import every supplier, document, image or historical field. The current process starts with a conversation about the source system and an approximate record-count range, never a client export sent through ordinary email, a website form or social media.
1. Establish who controls the information
Before any transfer, identify the clinic’s role, the existing supplier’s role and the new supplier’s role. The ICO explains that controller–processor contracts should cover documented instructions, confidentiality, security, help with data-subject rights, return or deletion at the end of the arrangement, and information needed to demonstrate compliance.
Read the ICO’s controller and processor contract guidance. Your clinic’s legal or information-governance adviser should apply it to your circumstances.
2. Inventory the source before mapping it
Ask the current system for a structured export manifest. Record formats, character encoding, identifiers, timestamps, attachment references and known limitations matter. Count the major record groups before transformation so the team can later explain whether the destination contains the same, fewer or more items.
- Client identities and duplicate candidates.
- Future and historical appointments.
- Forms, notes, documents and image references.
- Staff authorship and timestamps where available.
- Payment references without importing secret payment credentials.
- Consent and communication preferences with their source and date.
3. Map meaning, not just column names
“Status”, “notes” and “consent” can mean very different things across products. A field map should say what each source value means, where it will land, what transformation is applied and what happens when the value is missing or unfamiliar. Unknown values should become visible exceptions, not quietly forced into the nearest-looking option.
4. Run the migration somewhere disposable
The first import should never be the production import. Use a controlled, isolated environment with fictional or appropriately protected test material. Reconcile counts, spot-check the journeys chosen at the start and prove that rerunning the process does not create duplicates. Keep a record of the import version, evidence and result.
The ICO’s security guidance frames appropriate technical and organisational measures around the risks of the processing. That supports a risk-based migration rather than casually moving a sensitive dataset because a file happens to fit.
Read the ICO’s security guidance.
5. Put exceptions in front of the clinic
A useful dry-run report is not simply “successful”. It shows counts, duplicates, rejected rows, truncated values, missing attachments and anything that needs a decision. The clinic should be able to distinguish a harmless formatting issue from missing clinical context.
6. Sign off the journeys, then authorise production
Production import should require a named clinic decision after the dry run. Capture what was tested, which exceptions were accepted, what remains outside the new system and the agreed cut-over plan. Preserve the old system or export for the period the clinic has lawfully decided is necessary; do not improvise retention at launch.
7. Verify deletion and rollback
Temporary copies should have a defined deletion point and evidence of deletion. The cut-over plan should also explain what happens if reconciliation fails. “Rollback” may mean keeping the former system read-only while the new import is corrected, rather than trying to reverse every write after staff have started using it.
Questions to ask any supplier
- Which sources and formats have you actually tested?
- Which fields and files are explicitly unsupported?
- How do you isolate the dry run from live clinic data?
- What evidence will show counts, exceptions and authorship?
- Who approves the production import?
- How are temporary exports deleted and evidenced?
Rytura is building this as supported launch onboarding, not a magic importer. See the planned switching process or use the buyer’s checklist to compare another supplier’s answer.