CRM migration

Migrate from Open Dental to HighLevel

Field-level mapping, validation, and rollback between Open Dental and HighLevel. We move data and schema; workflows are rebuilt natively in HighLevel.

Open Dental logo

Open Dental

Source

HighLevel

Destination

HighLevel logo

Compatibility

100%

12 of 12

objects map 1:1 between Open Dental and HighLevel.

Complexity

BStandard

Timeline

72–96 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Open Dental logo

Open Dental

What's pushing teams away

  • Open Dental runs on a local Windows server that the practice must maintain; offices without dedicated IT staff experience server crashes, slowdowns, and update failures as operational risk.
  • The interface and feature set have a dated UX that newer staff find unintuitive compared to cloud-first alternatives, leading to training overhead and reduced staff satisfaction.
  • Scaling beyond two or three locations requires significant configuration work (Replication, CEMT, Enterprise features) that demands technical expertise most solo or small-group practices lack.
  • Performance degrades with large patient bases and years of transaction history stored in the same database, causing slow queries and screen delays during peak hours.

Choosing

HighLevel logo

HighLevel

What's pulling them in

  • Agencies choose HighLevel to consolidate CRM, email, SMS, scheduling, and funnels into one subscription, eliminating monthly bills for five to ten separate SaaS tools they previously stitched together.
  • The flat-rate pricing model bills per sub-account rather than per contact, so growing a contact database from 1,000 to 100,000 records does not trigger a billing surprise—a common pain point avoided by migrating customers.
  • White-label and sub-account capabilities let agencies resell HighLevel access to their own clients, turning a software cost center into a recurring revenue stream that justifies the subscription.
  • The platform ships a 14-day free trial with no credit card required, giving teams a low-friction entry point to validate fit before committing to the $97/month Starter tier.
  • Marketing agencies managing multiple client accounts use sub-accounts to maintain data isolation per client while operating under a single agency billing relationship with HighLevel.

Object mapping

How Open Dental objects map to HighLevel

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)

maps to

HighLevel

Contact

1:1
Fully supported

Each 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

maps to

HighLevel

Contact postal address fields

1:1
Fully supported

Open 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

maps to

HighLevel

Contact.phoneNumber1 or phoneNumber2

1:1
Fully supported

Open 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)

maps to

HighLevel

Company (location)

1:1
Fully supported

Open 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)

maps to

HighLevel

Task or Note on Contact

1:1
Fully supported

Open 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

maps to

HighLevel

Note on Contact

1:1
Fully supported

Open 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)

maps to

HighLevel

Contact custom field

1:1
Fully supported

Open 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)

maps to

HighLevel

Note or custom field on Contact

1:1
Fully supported

Open 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

maps to

HighLevel

Note on Contact

1:1
Fully supported

Open 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

maps to

HighLevel

Note on Contact

1:1
Fully supported

Payment 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

maps to

HighLevel

Task on Contact

1:1
Fully supported

Open 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)

maps to

HighLevel

Contact custom field

1:1
Fully supported

Some 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.

Gotchas + challenges

What specifically takes care here

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 logo

Open Dental gotchas

High

X-ray images do not migrate between systems

Medium

Scanned documents require a separate image conversion with additional cost

High

Server must run MySQL with myISAM engine, not InnoDB

Medium

API pagination is limited to 100 records per request

Medium

Custom sheets use proprietary XML that only imports to Open Dental

HighLevel logo

HighLevel gotchas

High

Sub-account architecture creates isolated data silos per client

High

Usage-based telecom and AI costs are not in the subscription price

Medium

Workflows have no native equivalent in most destination CRMs

Medium

API rate limits cap bulk migration throughput at 100 requests per 10 seconds per sub-account

Low

White-label configuration and branding assets do not export via API

Pair-specific challenges

  • Open Dental appointment schema has no HighLevel equivalent — appointment history requires deliberate conversion

    Open Dental appointments carry rich clinical context: procedure codes, tooth numbers, surfaces, operatory, confirmation status, and recall intervals. HighLevel has no native appointment object — its calendar module is for future bookings, not historical clinical records. If you have years of appointment history, that data does not land as structured records in HighLevel. We convert each appointment into a Task or Note on the corresponding Contact, preserving the date, provider, and procedure description. The tooth-number and surface data, however, becomes free text in the note body. Before migration, decide how many years of appointment history to convert — importing 10 years of appointment records as notes for 5,000 patients can create noise in HighLevel's contact timeline.

  • PatField custom fields create a multi-step setup requirement in HighLevel before import

    Open Dental PatFieldDefs are defined per-database and can include Text, PickList, Date, Checkbox, and Currency types. HighLevel requires each custom field to be created individually in Settings > Custom Fields before data can be written to it via import. If you have 15 PatFieldDefs, we must create 15 corresponding HighLevel contact custom fields first — including exact picklist values for any PickList fields. HighLevel picklist options cannot be created via CSV import; they must be added manually or via API before the bulk import runs. This sequencing means the migration plan must be locked before the import phase starts, and any late-breaking field additions require re-import of that column.

  • Insurance and billing data has no workflow destination in HighLevel

    Open Dental insurance plans, subscriber IDs, coverage percentages, remaining benefits, claim history, and payment records are clinical-billing records with no equivalent in HighLevel's sales CRM model. HighLevel does not have an insurance object, a claims object, or a payment ledger. We preserve this data as formatted contact notes and custom text fields — it is reference-only. Front desk staff will still need to open Open Dental or access a separate billing tool to verify coverage, submit claims, or track payments. The billing workflow must be re-established outside HighLevel or handled through a third-party integration. Practices that rely heavily on Open Dental's insurance verification module should plan for this gap before committing to the migration.

  • Open Dental recall system converts to one-time tasks in HighLevel — no automated recurrence

    Open Dental's Recall system tracks patients due for hygiene visits, perio maintenance, or specific procedures with configurable intervals (e.g., 'Prophy every 6 months'). HighLevel's Task object does not support recurring or interval-based recurrence. Active recall entries migrate as one-time Tasks with the calculated due date at migration time. After go-live, the HighLevel workflow builder can recreate recall triggers based on custom date fields, but the original recall interval logic does not transfer automatically. Your HighLevel admin will need to rebuild recall automation using HighLevel's date-based workflow triggers if you want automated recall follow-up.

  • Multi-location Open Dental clinics require HighLevel sub-account planning before migration

    Open Dental's Clinics feature allows multi-location practices to operate from a single database with location-filtered reporting. HighLevel uses sub-accounts (available on the $297/month Unlimited plan) as the isolation boundary — each sub-account has its own contacts, pipelines, and workflows. If you run four clinic locations in Open Dental and want separate data isolation in HighLevel, each location needs its own sub-account. Contacts and custom fields must be assigned to the correct sub-account during import, which requires a ClinicNum-to-sub-account mapping before migration begins. Practices on the $97/month Starter plan cannot use sub-accounts and must manage location context within a single account using custom fields.

Migration approach

Six steps for a successful Open Dental to HighLevel data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

Context on both ends of the pair

Open Dental logo

Open Dental

Source

Strengths

  • One-time license fee with no per-seat recurring cost after the first year, making it the lowest total cost of ownership for stable practices.
  • Open-source codebase means the database schema is publicly documented and independent developers can build integrations without vendor dependency.
  • Multi-location support through Clinics, Replication, and CEMT scales from a single practice to a DSO with 30+ locations on a single database.
  • API with REST endpoints for Patients, Appointments, Claims, Payments, PayPlans, Documents, and Setup gives third-party tools a reliable integration surface.
  • Strong practitioner community and independent trainer ecosystem produce extensive documentation, forum support, and video walkthroughs for self-service learning.

Weaknesses

  • Server-based deployment requires the practice to own or rent server infrastructure and maintain Windows Server, MySQL, and .NET dependencies locally.
  • No cloud-hosted SaaS option built and supported directly by Open Dental Software; third-party hosting providers add variable cost and support tiers.
  • Interface design reflects its 2003 origins and has not undergone the UX modernization that cloud competitors have invested in heavily.
  • Performance degrades noticeably as the database grows to hundreds of thousands of patients and millions of procedure rows, requiring periodic database maintenance.
HighLevel logo

HighLevel

Destination

Strengths

  • Consolidates CRM, marketing automation, email, SMS, scheduling, and funnels into one platform at a predictable flat monthly rate.
  • Supports unlimited contacts and unlimited users on all paid tiers, removing per-record billing anxiety as databases grow.
  • Offers white-label and sub-account capabilities that let agencies resell access and manage multiple client environments under one billing relationship.
  • Includes built-in review management, reputation monitoring, and AI agents as native features rather than third-party add-ons.
  • Exports Contacts and Companies via a scalable async bulk CSV system that handles multi-million-row datasets without blocking the UI.

Weaknesses

  • The breadth of features creates a steep learning curve; advanced automations and Workflow configuration require significant time investment that smaller teams may not recover.
  • The platform charges usage-based fees for telecommunications and AI features that are not included in the base subscription, leading to bill surprises.
  • Recurring user reports on Reddit and G2 describe bugs, errors, and slow support response times that disrupt live marketing and sales operations.
  • Sub-account architecture, while powerful for agencies, adds migration complexity when identifying which client data lives in which isolated environment.
  • The platform is designed for agencies and SMBs; larger enterprises requiring deep reporting, custom objects at scale, or complex role-based access may outgrow its capabilities.

Complexity grading

How hard is this migration?

Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Open Dental and HighLevel.

  • Object compatibility

    B

    1 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Open Dental: Remote mode: 1,000 elements; Local/Service mode: 10,000 elements; Enterprise tier doubles Remote mode limits.

  • Data volume sensitivity

    B

    Open Dental doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Open Dental to HighLevel migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Open Dental to HighLevel data migrations

Answers to the questions buyers ask most during Open Dental to HighLevel migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most Open Dental to HighLevel migrations complete in 72–96 hours of clock time for practices with fewer than 25,000 patient records. The longest phase is custom field creation in HighLevel — each PatFieldDef requires manual setup or API creation before import. Practices with 25,000+ patient records, multiple clinic locations, or 20+ PatFieldDefs extend to 7–14 days. The sample migration step adds 1–2 days upfront but prevents errors in the full run.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Open Dental.
Land in HighLevel, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day