Clínica Digital Software SOFTWARE
Demo
← Back to the blog
Product 1 October 2026 · 13 min read

Migrate patient data without losing clinical records

Clinic managers export patient data, validate the clinical record and run tests before migrating to new software to avoid disrupting appointments.

Key findings

  • A proper migration is not “just moving contacts”: it requires ensuring continuity of the record, including documents, clinical notes and episodes linked to the correct patient.
  • An CSV export format is useful for tabular data but does not cover attachments, consents or reports; plan those items separately.
  • Pre-migration testing must include real cases: patients with treatment packages, cancellations, insurers, multiple practitioners and corrective invoices.
  • The key criterion is traceability: being able to demonstrate what was exported, when, who validated it and what was excluded, for operational reasons and for the GDPR.

Changing software without losing information is possible, but it must not be improvised. Migration affects the schedule, payments, clinical records and front desk work; if it fails, you’ll see it on day one.

What “not losing the record” means in a clinic

Define “record” according to how you work

In a clinic, record is not just a patient record with a name and phone number. It normally includes items scattered across the current software and in “parallel” folders:

  • Identification: personal data, contact details, DNI/NIE if you use it, address, date of birth.
  • Care relationship: episodes/visits, session notes, practitioner who attended, reason for consultation (if you record it), internal referrals.
  • Documentation: informed consents, reports, attached test results, forms, images, PDFs.
  • Administration: estimates, invoices, payments, payment methods, treatment packages, sessions consumed, unpaid balances, refunds.
  • Operational: reminders, communications, cancelled appointments/no-shows, internal tags (“prefers mornings”, “call before”, “insurer X”).

Action you can take (today): print or share a “record checklist” for your clinic and mark what is essential to migrate and what can remain as archived consultable files.

Decide what continuity you need from day one

Not all clinics need the same things on day one after the switch. The practical question is: what must the front desk and the practitioner be able to see on a call or in an appointment?

Realistic example:

  • The front desk answers a call: they need to see the last visit, treatment package balance, outstanding invoices and the correct phone number.
  • The practitioner opens the session: they need to see previous notes, relevant documents and who attended before.

Action you can take (this week): define an “operational minimum” for the go‑live: 8–12 fields and 3–5 key documents per patient that cannot be missing.

What usually breaks when exporting patient data

CSV is not the complete record

Many tools let you export patient data to a CSV export format. It’s useful, but has clear limits:

  • CSV works well for tables (patients, appointments, invoices).
  • It works poorly or not at all for attachments (PDFs, images), signatures, scanned consents or versioned documents.
  • It commonly loses complex relationships if not exported with consistent keys (for example, visits linked to a patient by an internal ID).

Action you can take: ask your current provider for a list of available exports and mark which are CSV and which are “folders” or “loose files”.

Free-text fields and notes: the typical black hole

If your team writes a lot in free-text fields (“Observations”, “Internal notes”), three things can happen during migration:

  • They are copied but placed in a different field and no one finds them.
  • They are truncated due to length limits.
  • Internal notes get mixed with practitioner notes, creating a usage and confidentiality problem.

Action you can take: pick 20 patients at random and review how many operational decisions live in “notes” (for example: “do not call at work”, “prefers WhatsApp”). If there are many, decide where they should live in the new system.

Duplicates and “similar” patients

In long-running clinics it’s common to have:

  • The same patient with two patient records (one day they arrived with one phone number, another day with another).
  • Surname variants, diacritics or double surnames.
  • Minors linked to a guardian, but with mixed data.

The risk is migrating duplicates so the practitioner later sees the record split in two.

Action you can take: before exporting, agree a unification rule (for example: “if DNI/NIE matches, merge; if not, manual review”) and record who validates merges.

Migration plan in phases (without stopping the practice)

Phase 1: inventory and data map

Nothing moves yet. Decide what exists and how it’s named on each side.

  1. Inventory of modules and “real sources”:
    • Current software
    • Excel with treatment packages
    • Folder with scanned consents
    • Drive/Dropbox with reports
    • Card terminal/bank for payments and refunds
  2. Field map (source → destination):
    • “Phone 1” → “Mobile”
    • “Insurer” → “Insurer”
    • “Front desk observations” → “Administrative notes”
  3. Rules: what is migrated as-is, what is cleaned, what is not migrated.

Action you can take: create a simple table (Excel) with three columns: Field in current system, Field in new system, Rule/note. Have it signed by the manager and the front desk lead.

Phase 2: controlled export and backup

Before touching anything:

  • Generate a backup of the current system with date and responsible person.
  • Export in blocks: patients, appointments, billing, treatment packages, communications, documents.
  • Store the export in a controlled location with limited permissions.

If you work with a provider, require a log of:

  • Date and time of the export
  • What it includes and what it does not
  • Format (for example, CSV, PDF, ZIP of attachments)

Action you can take: appoint a “custodian” of the files (normally management or administration) and record internally where they are and who has access.

Phase 3: load into a test environment

Request (or set up) an environment where you can import without affecting daily work. This is where you perform the pre-migration tests with real cases.

Operational test checklist:

  • Search for a patient by name, phone and DNI/NIE (if applicable).
  • Check continuity of the record: recent visits, notes, documents.
  • Create an appointment and check availability by practitioner and room (if you use them).
  • Record a payment, an invoice and a refund (if applicable).
  • Check a treatment package: correct balance and consumption when registering a session.

Action you can take: define 10 “typical cases” and assign a validator to each: front desk validates the schedule; administration validates invoices; a practitioner validates the clinical record and documents.

Front desk reviewing patient records and files before migrating

Phase 4: final migration and change window

The final migration is planned with a “window” in which:

  • Changes in the old system are minimised (so no new data is created that won’t be migrated).
  • Rules are defined for how to handle new appointments, cancellations and payments during the window.

Common practice:

  • Work as usual up to an agreed cut-off time.
  • From that time on, the front desk records critical changes in a temporary log (for example, a controlled sheet) to replicate them in the new system after the load.

Action you can take: design a “change log” for the window: patient, action (appointment/payment/cancellation), time, responsible person.

Validation: how to check record continuity without going crazy

Smart sampling: don’t review “everything”, review what matters

Reviewing patient by patient is unfeasible. What works is a sample that covers complexity:

  • Patients with many visits
  • Patients with attached documents
  • Patients with treatment packages and partial consumption
  • Patients with corrective invoices or refunds
  • Patients attended by multiple practitioners
  • Patients with insurer cases (if applicable) and private patients

Action you can take: prepare a list of 30–50 “stress” patients (not by volume but by case type) and use it as a standard test set.

Basic reconciliation: totals that must match

Without getting into public figures or promises, there are simple checks that detect failures quickly:

  • Number of patients exported vs imported (any difference must be explained).
  • Number of appointments in a date range (for example, the last closed month).
  • Number of invoices issued in a closed accounting period.
  • Number of attachments and their accessibility.

Action you can take: request an import report from the provider with “imported / rejected / pending” and the reason for each rejection.

Traceability and GDPR: it’s not bureaucracy, it’s protection

The migration involves processing health personal data. In Spain the GDPR and the LOPDGDD (Spanish Organic Law on Data Protection and Guarantee of Digital Rights) apply. In addition, if a provider helps you, they typically act as data processor and you need an appropriate contract.

In practice, this means:

  • Access control to the exported files.
  • Internal records of who handles data and for what purpose.
  • Secure deletion or archiving of temporary files after migration.
  • Procedures to address rights (access, rectification, erasure) during the change.

The AEPD (Spain’s data protection authority) publishes guides and useful criteria to implement measures and responsibilities without turning it into an endless project.

Action you can take: ask the provider in writing what measures they use to transfer files (channel, encryption, access) and who can access them during the process.

Schedule, payments and staff: things nobody wants to discover on Monday

Schedule: resources, durations and slot rules

When migrating the schedule, the typical failures are not “missing appointments” but:

  • Default durations differing (30 vs 45 minutes).
  • Overlap rules per practitioner.
  • Resources not migrated (room, equipment) and appointments left “without a place”.
  • Appointment types that change name and break internal statistics.

Action you can take: before the change, list your appointment types (first visit, follow-up, report, insurer, video consultation if applicable) with duration and resources; validate they exist the same way in the new system.

Payments and billing: what should be closed beforehand

If you change software in the middle of a billing period, operational questions arise:

  • Where do I issue a corrective invoice for an old invoice?
  • Where do I look up a patient’s payment history if there’s a claim?
  • How do I control unpaid balances if status didn’t migrate correctly?

Without giving tax advice, the management practice is clear: close what you can close before the change and define which consultations will be done in the old system as “archive”.

Action you can take: agree an internal “operational cut-off” date for billing and a procedure: “previous invoices are consulted in the old system; new invoices are issued in the new one”.

Team: permissions, roles and user accounts

The human risk is high during a migration:

  • Someone logs in with excessive permissions “to help”.
  • Generic shared users are created.
  • Roles are not replicated correctly (front desk sees notes they shouldn’t, or the practitioner can’t see required documents).

Action you can take: prepare a list of users with their role and the minimum necessary access. Review on day one: front desk, administration, management and each practitioner.

What to ask a provider before signing the migration

Concrete questions that avoid surprises

Take these questions to the demo or the technical meeting:

  • What export formats do you support from my current system: CSV, Excel, JSON, ZIP of attachments?
  • How do you import documents: by link, by mass upload, by folder per patient?
  • Which fields are not imported and why?
  • How do you resolve duplicates: automatic rule, manual review, conflict report?
  • What do you deliver at the end: import report, error list, mapping log?
  • Is there a test environment and how many test iterations does the process allow?

If you are evaluating ClinicaDigital Software, apply these same questions; they help compare any alternative without relying on commercial language.

Action you can take: insist on a “migration scope” document specifying: what is included, what is excluded, what is validated, who validates and what constitutes an accepted migration.

Risk signals (stop and redefine if you see them)

  • “Everything is transferred” without detailing what everything means.
  • No test plan before the change date.
  • No import error report.
  • They ask for files over informal channels without access control.
  • No discussion of roles/permissions or traceability.

Action you can take: if you detect a signal, convert the point into a requirement: “no go-live date without a test environment”, for example.

How to Apply This in Your Clinic

  1. Monday (management + front desk, 45 minutes): define the “operational minimum” of record continuity (fields and essential documents) and note it in a shared sheet.
    Check: all profiles (front desk, practitioner, administration) confirm that with that minimum they can work a full day.
  2. Tuesday (administration, 60 minutes): inventory data sources and available exports; ask the current provider for the export in a CSV export format and, separately, attachments/documents.
    Check: there is a controlled folder with dated exports and a record of who has access.
  3. Wednesday (designated lead + provider, 60–90 minutes): build the field map source→destination and agree rules for duplicates and normalization (phone numbers, diacritics, DNI/NIE if applicable).
    Check: the map has an owner and a version; any change is recorded.
  4. Thursday (front desk + 1 practitioner + administration, 90 minutes): run the pre-migration tests with 10 typical cases (treatment package, insurer, refunds, multiple practitioners, documents).
    Check: list of incidents with a screenshot or example, and a decision: fix in source, in mapping or in destination.
  5. Friday (management, 30 minutes): define the change window and the “change log” to record appointments/payments during the cut; communicate it to the team.
    Check: everyone knows what to record, where and who will transfer it to the new system.

Frequently Asked Questions

What minimum data should I migrate to start working?

You should migrate patient identification, contact details, future schedule and a usable summary of the recent record. Add open billing (unpaid invoices, active treatment packages) so the front desk can charge and reconcile. The rest can remain as consultable archive if you define it that way from the start.

Is CSV suitable for migrating documents and consents?

No, CSV is for tabular data and basic relationships if they are well identified. Documents are usually migrated as files (for example, folders or ZIPs) and require a rule to link them to each patient. Ask for a method to import attachments and test it with several document types.

How do I handle new appointments during the change window?

Define a cut-off time and a single temporary log for critical changes: new appointments, cancellations and payments. One responsible person transfers those changes to the new system after the final load. Without a single log, you will end up with duplicated slots or missing appointments.

What should I request to comply with GDPR during a migration?

You should request secure transfer and storage measures for files, access control and traceability of who handles the data. Ensure there is a data processing agreement if a provider intervenes, in accordance with the GDPR and the LOPDGDD (Spanish Organic Law on Data Protection and Guarantee of Digital Rights). Keep an internal record of the process and delete temporary copies when no longer necessary.

Tags migration data clinical record software change

Keep reading