Migrate from axiUm Dental to HighLevel

axiUm patient records from the Rolodex module map to HighLevel contacts. We extract first name, last name, date of birth, contact phone numbers, and email addresses. Patient ID from axiUm is stored as a custom field (Source_System_ID__c) for traceability and delta-run de-duplication.

axiUm stores patient addresses as a separate sub-record linked to the patient. We map street address, city, state, and postal code to HighLevel's address fields on the contact record. Historical addresses from axiUm are preserved as custom text fields if multiple addresses exist for a single patient. We validate address formats during the test migration pass to catch any truncation or encoding issues before the full cutover.

axiUm flags medical alerts (allergies, conditions, restrictions) that appear in the status bar when a chart opens. These map to a HighLevel custom text field (Medical_Alerts__c) on the contact. We preserve the full alert text string as entered in axiUm.

axiUm appointment records from the Scheduler module map to HighLevel tasks on the associated contact. Appointment date, time, provider name, treatment type, and status (completed, no-show, cancelled) are captured. Historical appointment volume becomes activity history in HighLevel. Provider assignments are resolved through email matching to HighLevel team members, with unmatched providers flagged for team member creation before migration.

axiUm treatment plan records containing diagnoses, planned procedures, and estimates have no direct HighLevel equivalent. We create a Treatment_Plans__c custom object in HighLevel with fields for procedure codes, status, and estimated amounts, linked to the contact record through a lookup relationship. This approach preserves the essential treatment planning information while adapting it to HighLevel's data structure.

axiUm periodontal chart measurements including BOP percentages, pocket depths, and CAL values are clinical data that don't have a direct HighLevel equivalent. We create a Perio_Records__c custom object with numeric fields for each measurement type, linked to the contact record. The full clinical chart notes, tooth-level charting, and radiograph links cannot be migrated to HighLevel and must remain in axiUm.

axiUm clinical notes and procedure notes contain detailed clinical documentation that HighLevel cannot represent. We extract a plain-text summary of the most recent clinical note per patient and store it as a custom field (Clinical_Note_Summary__c) for reference — the full clinical record must remain in axiUm or a separate EHR.

axiUm financial transactions including procedure charges, insurance payments, and patient payments do not map to HighLevel opportunities or any standard object. We skip billing data entirely during migration. Practices needing financial history must retain axiUm access or export separately for accounting purposes. We recommend coordinating with your finance team before the cutover to establish a separate billing export workflow that captures all transaction history for your accounting records.

axiUm practices with multiple clinic locations (separate clinic books for different specialties or satellite sites) can map each to a separate HighLevel sub-account. This requires pre-setting up sub-accounts in HighLevel before migration — we deliver the mapping plan in the pre-migration audit.

axiUm scanned consent forms and patient-uploaded attachments are downloaded and re-uploaded to the contact record in HighLevel as file attachments. We respect HighLevel's file size limits of 25MB per file — any attachments exceeding this threshold are flagged in the migration report for manual handling by your team. Prior to migration, we verify that all consent forms are current and match your active templates.

axiUm provider and faculty accounts are resolved by matching email addresses against existing HighLevel team members. Unmatched axiUm providers are assigned to a fallback team member or flagged for HighLevel account creation before the full migration runs. This ensures all patient records maintain proper owner assignment throughout the migration process and no data is orphaned due to missing user accounts.

axiUm recall records for hygiene appointments and follow-up care cannot migrate as data — they represent a workflow trigger that must be rebuilt in HighLevel using the workflow builder (trigger: contact created more than X months ago, action: send SMS or email reminder).