Migrate from Core Practice to HighLevel

No native dental data model in HighLevel requires custom field strategy for every clinical record

Core Practice stores treatment histories, tooth charts, allergy records, prescription data, and HIPAA consent flags as patient-level data. HighLevel has no native equivalent for any of these — there is no treatment plan object, no tooth chart field, no insurance carrier relationship object. Every clinical field in Core Practice becomes a custom field on the HighLevel contact record or a separate custom object. This is not a limitation of the migration — it is a structural difference between a dental practice management system and a general CRM. We create the custom field schema in HighLevel as part of the migration plan, but your team decides which fields are worth migrating versus summarizing in a linked document. The volume of custom fields directly affects migration pricing because each field requires schema creation, validation, and a mapping entry.

HighLevel API rate limits require batched bulk imports to avoid throttling during large migrations

HighLevel's API imposes a rate limit of 200,000 requests per day and 100 requests per 10 seconds per sub-account under the GHL-APP integration token. For migrations exceeding 10,000 contact records with associated appointment and note data, the total API request count can approach this limit if imports are not batched correctly. We handle this by using HighLevel's bulk CSV import endpoint (which operates outside the per-request rate counter) for contacts and companies, and staggering custom object and appointment imports across multiple passes. For very large datasets, we request a temporary rate limit increase through HighLevel's API increase request form before the migration window. This is disclosed upfront in the migration plan so there are no surprises on migration day.

Workflows, automations, and appointment sequences do not migrate and must be rebuilt

Core Practice appointment reminder sequences, follow-up task automations, and patient communication workflows have no direct export path to HighLevel. The workflow logic — triggers, conditions, delays, and actions — lives in Core Practice's own automation engine and is not accessible via API in a transferable format. We export the workflow definitions as a written reference document describing each automation's trigger, conditions, and action sequence. Your team or a HighLevel specialist then rebuilds these in HighLevel's workflow engine using the exported logic as a guide. This is a manual step that adds 1–3 days of configuration work depending on the number of active automations. We flag this clearly in the migration plan and offer a workflow-rebuild scoping call as an optional add-on.

Core Practice has no documented public API — data export relies on CSV extraction with field availability variation

Unlike HubSpot, Salesforce, or HighLevel itself, Core Practice does not publish a public REST or GraphQL API for automated data extraction. The primary export path is Core Practice's built-in CSV export feature for contacts and appointments. The fields available for export depend on your Core Practice plan and configuration — some custom fields may only be exportable individually or may require a screen scrape. We audit the export capability during discovery and identify any fields that require manual extraction. If your Core Practice plan does not support bulk export for all desired fields, we scope a manual extraction process with your team and build the import mapping around the available data. This is a discovery-phase step that always precedes the migration run.

Appointment status value set differs between platforms requiring explicit value mapping

Core Practice uses appointment status values such as Scheduled, Confirmed, Checked-In, No-Show, Cancelled, and Rescheduled. HighLevel's Calendar Event booking status values are different by default and are configurable per sub-account. The mapping between these two value sets is not 1:1 — there is no 'Checked-In' status in a standard HighLevel calendar event, and 'Rescheduled' is not a native status in either system. We create an explicit value-mapping table for appointment statuses during the planning phase. Cancelled appointments are preserved with a cancelled status flag rather than deleted. No-show records are preserved as completed events with a no-show tag applied. Your team confirms the value-mapping table before the migration runs to ensure appointment history reflects the intended status in HighLevel.