Migrate from AeronaClinic to Salesforce Sales Cloud

AeronaClinic patient demographics (name, DOB, address, phone, email) map directly to Salesforce Contact fields. Medical record number and NHS number migrate as custom fields on Contact since Salesforce has no native equivalents. The primary practitioner assignment resolves to a Contact.Practitioner__c User lookup.

AeronaClinic does not have a native clinic/practice entity, but multi-location setups store a clinic name per patient. We create an Account record per location and link all patients at that location via AccountId on Contact. This enables Salesforce location-based reporting.

Salesforce Event object lacks Status__c, Practitioner__c, Appointment_Type__c, and Cost__c fields needed for clinical context. We create a custom Appointment__c object with these fields, linked to Contact via ContactId lookup. The Appointment_Date_Time__c field stores the original booking timestamp for continuity, preserving the exact scheduling date across the migration.

AeronaClinic appointment statuses (Confirmed, Cancelled, DNA, Rescheduled, Complete) map to Salesforce pick-list values on Appointment__c.Status__c. DNA (Did Not Attend) has no Salesforce equivalent and requires a value-mapping entry to 'No Show' or a custom value. Each mapping is documented in the migration plan before the run.

AeronaClinic practitioners are stored as a practitioner name or ID per appointment and treatment. We resolve each practitioner by email match against Salesforce User records. Unmatched practitioners are flagged before migration — the clinic either creates Salesforce User records or assigns their records to a fallback practitioner owner.

AeronaClinic stores treatment name, tooth number/surface, procedure code (UDDA), cost, and status per treatment. We create a custom Treatment__c object with a ContactId lookup linking back to the patient, an AppointmentId__c lookup linking to the appointment, and fields for Tooth_Number__c, Procedure_Code__c, and Cost__c.

Free-text clinical notes (clinical findings, medical history updates, prescriptions, clinical photographs references) have no Salesforce equivalent. We create Clinical_Note__c with Note_Type__c pick-list, Note_Text__c long-text area (32768 chars), Practitioner__c User lookup, and Original_Create_Date__c preserving the source timestamp. Linked to Contact by ContactId.

AeronaClinic stores patient documents (ID scans, consent forms, treatment plans, radiograph references) as file records. Salesforce Files attach differently to Contacts. We migrate document metadata to a custom Document__c object with File_URL__c (text), File_Type__c, Upload_Date__c, and Source_System_ID__c for traceability. Files are re-uploaded to Salesforce Files or stored with Document__c.File_URL__c pointing to a document store.

AeronaClinic invoices contain invoice number, date, line items, total amount, status, and payment reference. Salesforce has no native invoice object at the Contact level. We create Invoice__c with fields for Invoice_Number__c, Invoice_Date__c, Amount__c, Amount_Due__c, Payment_Status__c, and a ContactId lookup. This preserves full billing history for finance reporting in Salesforce.

AeronaClinic stores patient allergies and medical conditions as structured fields on the patient record. These have no Salesforce Contact equivalents. We create Allergies__c (long-text area) and Medical_Conditions__c (long-text area) on Contact, preserving the full history in the patient record rather than in a separate object.

AeronaClinic captures NHS numbers (UK) and insurance policy details. Salesforce has no native NHS or insurance number field on Contact. We create NHS_Number__c (text, 10 chars) and Insurance_Policy_Number__c (text) as custom fields on Contact. Insurance_Provider__c (text) is added as a companion field.

AeronaClinic records how a patient was acquired (referral, advertising, organic). This maps directly to the native Salesforce Contact.LeadSource pick-list. If AeronaClinic uses custom referral source values not in the Salesforce default pick-list, we add them as new LeadSource values before migration.