CRM migration
Field-level mapping, validation, and rollback between Open Dental and HighLevel. We move data and schema; workflows are rebuilt natively in HighLevel.
Open Dental
Source
HighLevel
Destination
Compatibility
12 of 12
objects map 1:1 between Open Dental and HighLevel.
Complexity
BStandard
Timeline
72–96 hours
Overview
Open Dental runs as an on-premise or third-party-hosted practice management system, storing patient records (PatNum), providers, procedure logs, insurance plans, and claims in a MySQL/MariaDB database. Its REST API exposes Patients, Appointments, Procedures, Claims, Payments, and PatFields with pagination at 100 records per page. HighLevel is a cloud-native all-in-one CRM built around Contacts, Companies, Opportunities (pipeline stages), and custom objects, with API rate limits of 200,000 requests per day per sub-account and bulk CSV import for contacts and companies. We extract patient data from Open Dental via API or direct database query, map patient records to HighLevel contacts (using email or phone as the primary key), preserve procedure history and insurance plan data as custom fields or contact notes, and import provider names as companies in HighLevel. Appointment history becomes contact tasks or notes with original timestamps. Any Open Dental PatField custom fields (text, picklist, date, checkbox, currency) migrate as HighLevel contact custom fields. Workflows, automated reminders, and treatment-plan sequences built in Open Dental do not transfer — we export those definitions as a rebuild reference for your HighLevel admin. The migration runs on scoped read access so your team keeps working in Open Dental throughout the cutover, with a 48-hour delta pickup window before you close the source.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Open Dental object lands in HighLevel, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Open Dental
Patient (PatNum)
HighLevel
Contact
1:1Each Open Dental patient record maps to one HighLevel contact. The contact's email address (or phone number if email is absent) is used as the primary key for deduplication during bulk import. If a patient has no email or phone, we generate a placeholder and flag the record for manual review after migration.
Open Dental
Patient.Address
HighLevel
Contact postal address fields
1:1Open Dental stores street, city, state, and zip in the Patient record. These map to the standard address fields in HighLevel Contact. If a patient has multiple addresses (billing vs. home), the primary address maps directly and any secondary is appended to a contact note.
Open Dental
Patient.Phone
HighLevel
Contact.phoneNumber1 or phoneNumber2
1:1Open Dental distinguishes between home, work, cell, and emergency phone numbers stored across separate fields in the Patient record. HighLevel supports phoneNumber1 and phoneNumber2 on contacts. We map the primary phone (typically home or cell) to phoneNumber1 and write any secondary numbers to phoneNumber2 as a comma-separated value. During post-migration review, your admin can split phoneNumber2 into individual entries or update contacts manually if the secondary number is important for outreach. Unmapped phone types (such as emergency numbers) are appended to the contact note field for reference.
Open Dental
Provider (ProvNum)
HighLevel
Company (location)
1:1Open Dental providers (dentists, hygienists, assistants) are staff records with ProvNum. In HighLevel, we create a Company record per provider with the provider's name and specialty. This gives front desk staff a contact company to reference when booking or confirming appointments.
Open Dental
Appointment (ApptNum)
HighLevel
Task or Note on Contact
1:1Open Dental appointments have a rich schema: date, time, operator, operatory, provider, procedure codes, and confirmation status. HighLevel has no native appointment object. We convert each appointment into a Task or Note record attached to the corresponding Contact, preserving the original date, provider, and procedure description. This keeps appointment history visible in the contact timeline.
Open Dental
ProcedureLog
HighLevel
Note on Contact
1:1Open Dental procedure logs store tooth number, surfaces, ADA procedure code, fee, and provider. Since HighLevel has no clinical procedure object, procedure history becomes a formatted Note attached to the Contact, with the procedure code, description, date, and fee preserved as readable text. Treatment plan items are stored as a separate note block.
Open Dental
PatField (custom patient fields)
HighLevel
Contact custom field
1:1Open Dental PatFieldDefs define per-patient custom fields of type Text, PickList, Date, Checkbox, or Currency. Each PatFieldDef becomes a HighLevel contact custom field with the matching type. We create the field in HighLevel before import and map all values field-by-field. If a picklist in Open Dental has values that don't match a HighLevel picklist, we create a new picklist option in HighLevel.
Open Dental
Insurance Plan (InsPlan)
HighLevel
Note or custom field on Contact
1:1Open Dental stores insurance plan details, subscriber ID, and coverage percentages. HighLevel has no insurance object. We preserve the carrier name, group number, and subscriber ID as a formatted contact note. Coverage percentages and remaining benefits are stored as custom text fields for reference — they do not drive any HighLevel automation logic.
Open Dental
Claim
HighLevel
Note on Contact
1:1Open Dental claims carry claim status, service date, tooth, procedure code, and fee. HighLevel has no claim object. We convert each claim into a Note on the associated Contact with the status, date, and fee, preserving the billing history for front-desk reference without requiring access to Open Dental.
Open Dental
Payment
HighLevel
Note on Contact
1:1Payment records in Open Dental include date, amount, payment method, and provider. We convert these to Notes on the Contact with the date, amount, and payment type. The note format includes the provider name so the payment attribution is visible in the HighLevel contact record.
Open Dental
Recall
HighLevel
Task on Contact
1:1Open Dental recall entries track when a patient is due for a hygiene visit or specific procedure. We convert active recall entries into Tasks in HighLevel with the recall due date and description, so staff can act on them in the HighLevel task list after cutover.
Open Dental
Referral source (PracticeSignal guide)
HighLevel
Contact custom field
1:1Some Open Dental practices track how patients heard about the practice in a PatField or provider-defined field. We migrate this as a custom field on the Contact so referral source data is available for HighLevel workflow segmentation and reporting. Once imported, your team can build HighLevel automations that tag contacts by referral origin, trigger personalized follow-up sequences for specific referral channels, and generate reports on which marketing sources drive new patient volume. This preserves attribution data that would otherwise be lost during the migration and enables your HighLevel admin to recreate any referral-based routing logic from Open Dental.
| Open Dental | HighLevel | Compatibility | |
|---|---|---|---|
| Patient (PatNum) | Contact1:1 | Fully supported | |
| Patient.Address | Contact postal address fields1:1 | Fully supported | |
| Patient.Phone | Contact.phoneNumber1 or phoneNumber21:1 | Fully supported | |
| Provider (ProvNum) | Company (location)1:1 | Fully supported | |
| Appointment (ApptNum) | Task or Note on Contact1:1 | Fully supported | |
| ProcedureLog | Note on Contact1:1 | Fully supported | |
| PatField (custom patient fields) | Contact custom field1:1 | Fully supported | |
| Insurance Plan (InsPlan) | Note or custom field on Contact1:1 | Fully supported | |
| Claim | Note on Contact1:1 | Fully supported | |
| Payment | Note on Contact1:1 | Fully supported | |
| Recall | Task on Contact1:1 | Fully supported | |
| Referral source (PracticeSignal guide) | Contact custom field1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Open Dental gotchas
X-ray images do not migrate between systems
Scanned documents require a separate image conversion with additional cost
Server must run MySQL with myISAM engine, not InnoDB
API pagination is limited to 100 records per request
Custom sheets use proprietary XML that only imports to Open Dental
HighLevel gotchas
Sub-account architecture creates isolated data silos per client
Usage-based telecom and AI costs are not in the subscription price
Workflows have no native equivalent in most destination CRMs
API rate limits cap bulk migration throughput at 100 requests per 10 seconds per sub-account
White-label configuration and branding assets do not export via API
Pair-specific challenges
Migration approach
Extract patient and clinical data from Open Dental via API and direct database query
We connect to your Open Dental MySQL/MariaDB instance (or use the REST API with read-only credentials) to extract Patient, Provider, Appointment, ProcedureLog, InsPlan, PatPlan, Claim, Payment, Recall, and PatField records. The Open Dental API paginates at 100 records per request; we use concurrent requests to accelerate extraction for practices with over 10,000 patient records. We extract the full schema of PatFieldDefs and their values so no custom field data is missed. All data is exported to a structured staging directory with original timestamps preserved.
Map Open Dental schema to HighLevel objects and create custom fields
We generate a mapping document mapping each Open Dental table and field to its HighLevel equivalent. PatFieldDefs become HighLevel contact custom fields — we create each field in your HighLevel account via API (text, picklist, date, checkbox, or currency type matching the source). Picklist options for PickList-type PatFields are added to HighLevel before the bulk import. We create placeholder Company records in HighLevel for each Open Dental provider so contact-to-company associations resolve correctly during import.
Resolve provider and user assignments by email match
Open Dental provider records (ProvNum) are mapped to HighLevel users by email address. If a provider has no email in Open Dental, we use their name pattern to match against HighLevel users. Unmatched providers are flagged in the migration report — you either invite them to HighLevel first or assign their contact records to a fallback user. No contact lands in HighLevel without an assigned user. We also map Open Dental ClinicNum to HighLevel sub-accounts if you are on the Unlimited plan, so each location's contacts land in the correct sub-account.
Run a sample migration with field-level diff on 100–500 records
Before the full migration, we import a representative sample of 100–500 patient records spanning multiple providers, appointment types, and PatField configurations. We generate a field-level diff comparing the source Open Dental values against the resulting HighLevel contact records and custom field values. You review the diff to confirm that PatField mapping is correct, that appointment history converted as expected, and that insurance reference data landed in the right fields. We make any adjustments to the mapping before the full run commits.
Execute full migration with 48-hour delta-pickup window
The full migration runs using HighLevel's bulk CSV import for contacts and companies, with the custom field values written in the same import. Tasks and Notes are created via the HighLevel API for appointment history, procedure notes, and billing reference data. During the cutover window, your team continues working in Open Dental. A 48-hour delta-pickup captures any new patients, appointments, or field updates made after the initial extraction snapshot. Once the delta is absorbed, you are ready to switch over to HighLevel as the primary CRM.
Platform deep dives
Open Dental
Source
Strengths
Weaknesses
HighLevel
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Open Dental and HighLevel.
Object compatibility
1 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Open Dental: Remote mode: 1,000 elements; Local/Service mode: 10,000 elements; Enterprise tier doubles Remote mode limits.
Data volume sensitivity
Open Dental doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Open Dental to HighLevel migration scoping. Not seeing yours? Book a call.
Walk through your Open Dental to HighLevel migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Open Dental
Other ways to arrive at HighLevel
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.