Define the records your clinic software migration must cover
A clinic software migration starts with a practical question: will your team be able to find the records, photographs and documents needed at the next appointment? Importing a contact list does not answer it. Agree on the scope of the transfer, test it and involve the people who will use the information in the final review.
For an aesthetic clinic, begin with what practitioners need in the patient record during a consultation. List each category, where it is stored and who will check it. Reception staff and clinicians will often need to assess different parts of the transfer.
- Patient details: identifiers, archived records, changes of name and potential duplicates.
- Clinical history: appointments, dates, authors, notes and associated documents.
- Photographs: available original files, image sets, capture dates and links to visits.
- Documents: estimates, signed consent forms, attachments and available audit information.
- Scheduling: future appointments, practitioners, locations and information needed to prepare each visit.
Give each category a proposed destination: imported data, an accessible archive, or a decision still to be made. A readable PDF history does not necessarily become editable fields in the new system. Make that distinction explicit. This guide concerns a one-off transfer and its acceptance, rather than assuming that every system can migrate the same information within the same timeframe.
Request a usable export and identify the exclusions
Send the outgoing supplier a detailed export request before cancelling the contract. Ask about formats, included categories, separately supplied files and access after cancellation. A contact export, a technical backup and a document archive are different deliverables. The receiving supplier needs to confirm which of them it can actually use.
Limitations can depend on the source system. In its guide to transfers from Aesthetic Nurse Software, Pabau explains that some attachments must be obtained separately and that information entered after the export needs additional handling. That is evidence about this particular transfer route, rather than a rule for every supplier or an explanation of Nextmotion's service.
Have a representative export assessed before agreeing the commercial scope. The migration proposal should identify included work, exclusions, responsibilities and acceptance checks. Ask how unsupported fields, unreadable attachments and subsequent exports will be handled. A free contact import does not establish that a full historical migration is free.
Use a discussion of Nextmotion's open platform to explain your data exchange requirements. An API does not, on its own, show that a particular historical dataset can be imported in full. Our practice management software API guide covers ongoing connections; confirm migration formats and services separately from those integrations.
For each delivery, record when the export was produced, what it covers, which files are expected and what the receiving checks found. Keep source files separate from copies prepared for import. If data needs to be transformed, have the changes documented and retain a reference that allows the team to compare the source and destination versions.
Keep patients, visits, photographs and documents connected
An image copied into the new application may be of little use if its patient or date has been lost. Establish how identifiers from the source will map to records in the destination. A surname alone is a weak basis for matching: people can share a name, change it or have more than one record in the original system.
The documentation for advanced imports into Clinicminds requires historical records and attachments to be linked to a patient, for example through a shared identifier. This documented requirement illustrates a question to resolve in your own project; it does not establish how a Nextmotion import will work.
For photographs, also check the visit association, chronological order and preservation of available originals. Discuss how your team would find those images when using Nextmotion Capture. A structured digital consultation workflow helps the team place photographs within patient follow-up, but it cannot recreate missing dates or associations in the historical collection.
Keep an acceptance table, using the actual results of the test rather than treating the following template as completed evidence:
| Expected data | Received | Imported | Difference | Reviewer |
|---|---|---|---|---|
| Dated clinical history | Export identified | Dates and text checked | To document | Clinical lead |
| Original photographs | Files counted | Patient and visit checked | To document | Photography lead |
| Signed consent forms | Documents counted | Readable copy located | To document | Assigned reviewer |
Check the records before switching systems
An “import complete” message is not a clinical sign-off. Compare expected and received counts for each category, then open representative records. Identical totals can hide incorrect associations or duplicates. A difference may also reflect an agreed consolidation, which should be explained rather than silently accepted.
Include varied cases: an older record, a patient with several visits, signed documents, a photograph with an annotation and a future appointment. Check dates, special characters, line breaks, authors and attachments. Where information becomes an archive rather than structured fields, test how staff will search and read it in that form.
Have a practitioner review clinical content and the appropriate team check appointments. Test access with the accounts staff will actually use. Prefer fictional examples for initial discussions; where testing needs real patient data, agree the scope, authorised recipients and an appropriate transfer channel. An export creates another copy of sensitive information that needs to be accounted for.
Record each discrepancy, its consequence, the expected correction and its owner. Do not merge patients or rewrite clinical information simply to make an import warning disappear. Authorised people should decide how discrepancies are resolved. Keep the test results and approved mapping rules so that the team can check whether the final import follows them too.
Check visual information too: captions, orientation, annotations and the distinction between an original image and an edited composition. If an annotation cannot remain editable, agree how its content will remain accessible. A flattened image should not be described as an equivalent transfer without explaining the difference to the practitioners who rely on it. Record that limitation in the acceptance decision.
Plan the switch and continued access to archives
Agree when the final export will be taken and when new entries will move to the destination system. Consultations, changed appointments and documents created between those points need to be tracked. Plan how to transfer and check that additional information: a successful trial import says nothing about records created afterwards.
Specify which application is the source of truth during the transition, who may still edit the old system and how staff can retrieve a record if something goes wrong. Discuss whether the switch can be paused, whether read-only access is available and how a failed import would be handled. A backup alone does not establish that any of these options is available.
Where the EU GDPR applies, Article 28(3)(g), reproduced by the French regulator CNIL, provides for contractual arrangements under which the processor returns or deletes personal data at the controller's choice, subject to legal retention requirements. It does not define the next application's import formats or a universal period for retaining clinical records.
Complete your clinic software migration with a documented acceptance decision: delivered scope, completed checks, unresolved issues and archive access. Confirm arrangements for returning or deleting temporary copies with the suppliers. End the old subscription in accordance with its terms and the continuity arrangements you need, rather than cancelling as soon as the first imported records appear.
Frequently asked questions about clinic software migration
Can patient photos and signed consent forms be migrated?
That depends on the exportable files and the receiving supplier’s agreed scope. Test available originals, signed documents and their patient associations before confirming the transfer.
Is a CSV export enough?
A CSV file may contain contact details or structured data. It does not necessarily include photographs, PDFs or other attachments. Request an inventory of files that must be supplied separately.
How do we verify that photos remain linked to the correct patient?
Check the matching identifiers, then open representative records in the new system. Review the patient, visit, date and any annotations; counting files alone is not enough.
When can we cancel the old clinic software?
Check the contract and the effect of cancellation on exports and archives. Arrange the access you still need, review the final import and document unresolved issues before closing that access.
Discuss your migration requirements in a demonstration
If you are considering Nextmotion, bring the name of your current software, the categories of data involved and the questions from your inventory. Request a demonstration and discuss your migration requirements to clarify the possible scope, checks and proposed terms. Describe the project without attaching patient records to the commercial enquiry form; arrangements for any data transfer should be agreed separately.
