Migrate from Pearl Dental Software to HighLevel

X-ray and imaging files require manual re-upload to HighLevel

Pearl Dental stores radiograph files and imaging attachments linked to patient records. HighLevel's file storage is not a radiology viewer — files re-uploaded to HighLevel Contacts are stored as standard attachments without the clinical overlay Pearl provides. X-ray files must be downloaded from Pearl, compressed if over HighLevel's 25MB per-file limit, and re-uploaded manually or via a bulk file job. This step is the most time-intensive part of the migration for imaging-heavy practices and requires coordination with the clinical team to verify each file lands on the correct patient record.

Appointment data must be restructured into HighLevel's Task model

Pearl appointments carry clinical attributes — surgery room, appointment type, practitioner, recall interval — that have no direct equivalent in HighLevel's Task object. HighLevel Tasks support a Due Date, a Description, and an Assigned To user, but appointment type and recall intervals are custom fields we create during migration. The challenge is that HighLevel Tasks are not inherently linked to a calendar view with practitioner availability — calendar booking integrations in HighLevel (such as round-robin or service calendars) must be rebuilt separately and connected to the migrated Task records. Practices that rely on Pearl's recall system for patient re-activation must implement HighLevel workflows for this post-migration.

NHS number and exemption data have no native HighLevel model

Pearl Dental tracks NHS number, NHS exemption category, and private patient status as standard fields. HighLevel has no NHS-specific data model — all of this information must be stored in custom Contact fields we create (NHS_Number__c, NHS_Exemption__c, Private_Patient__c). Custom fields are not automatically surfaced in HighLevel's mobile app or in quick-view panels — your admin must add them to the contact record layout. Additionally, if your practice uses NHS Number for eligibility verification at point of care, that workflow cannot migrate and must be rebuilt using HighLevel's form and workflow tools with an NHS API integration if required.

Pearl Dental has no documented public API for automated data extraction

Unlike larger CRMs that expose REST APIs for programmatic data export, Pearl Dental Software's migration path relies on its built-in data export tool and, in some cases, direct database access for practices hosted on Pearl's cloud infrastructure. The export tool produces structured files (typically CSV or Excel) that FlitStack ingests and maps. If your Pearl instance uses a legacy data format or stores certain clinical fields in non-standard columns, those require manual field-by-field mapping before migration can proceed. Practices should confirm their Pearl export capability with Pearl support before scoping the migration.

HighLevel's sub-account model affects multi-location billing post-migration

Pearl Dental Software charges per surgery/room, which maps cleanly to a per-location billing model. HighLevel's pricing model is per sub-account — one subscription covers a defined set of features and contacts within one sub-account. For multi-location dental groups, migration planning must decide whether to consolidate all locations into a single HighLevel sub-account or create separate sub-accounts per location. Separate sub-accounts each incur a subscription cost, which may be higher or lower than Pearl's per-surgery pricing depending on location count. We surface this decision point in the pre-migration planning call so billing implications are clear before data lands.