Migrate from My Dental Clinic to HighLevel

Billing ledger and claim status have no native HighLevel equivalent — they migrate as read-only reference fields

My Dental Clinic tracks ledger balances, outstanding insurance claims, and payment history as native patient-level fields. HighLevel has no billing module — there is no ledger object, no claim-status field, and no accounts-receivable tracking built in. FlitStack preserves the last known balance and claim count as custom fields on the Contact record, but these are static reference values. Any active billing logic — claim submission, payment recording, statement generation — must be rebuilt in HighLevel using Workflows or connected to a dedicated dental billing integration (e.g., Waystar, Dentrix Ascend billing). Practices expecting HighLevel to replace My Dental Clinic's billing module will need a separate billing solution.

Recall reminder rules do not migrate and require complete rebuild in HighLevel Workflow Builder

My Dental Clinic's recall system (6-month cleaning reminders, annual exam alerts, per-procedure follow-up intervals) is driven by internal rule logic tied to appointment dates and treatment completion flags. HighLevel has no equivalent recall engine — these rules must be rebuilt as HighLevel Workflows using contact custom fields (recall_due_date__c) as time-based triggers, with delay actions and SMS/email task nodes configured to match the original reminder cadence. FlitStack exports the My Dental Clinic rule definitions as a structured JSON reference document so your HighLevel admin has the original trigger logic during the rebuild phase.

Insurance carrier lookup requires a Custom Object — N:N relationships between patients and carriers need junction handling

My Dental Clinic maintains a carrier table with payer IDs and EDI submission endpoints linked to patient insurance records. HighLevel has no native carrier or payer table. FlitStack creates a Carrier Custom Object and an Insurance Policy Custom Object, with Insurance Policy linked to Contact (one patient can have multiple policies, e.g., primary and secondary). If My Dental Clinic allows a single patient to have multiple active carriers simultaneously, the Custom Object relationship model in HighLevel handles this — but the admin must configure the relationship type (one-to-many via Contact ID) before the migration writes these records.

Appointment history migrates as read-only records — future appointments must be manually recreated in HighLevel Calendar

My Dental Clinic appointment records (past visits with provider, procedure code, duration, status) migrate to a Custom Object (Appointment Record) linked to Contact. This preserves historical context but does not integrate with HighLevel's Calendar feature, which only displays future appointments. Active recurring appointments (scheduled future cleanings, follow-up visits) must be manually recreated in HighLevel's Calendar using the migrated scheduling rules as a guide. HighLevel's Calendar supports round-robin assignment, availability blocking, and patient self-booking — features that require reconfiguration to match the original My Dental Clinic scheduling setup.

Custom intake forms and medical history fields require field-by-field mapping — duplicate field names across objects cause mapping ambiguity

My Dental Clinic practices often add custom intake fields for medical history flags, referral sources, or practice-specific data capture. HighLevel custom fields are created at the Contact level or on Custom Objects. When the same field name (e.g., 'referral_source') exists in multiple My Dental Clinic contexts, it may need routing to different HighLevel locations (Contact vs. Custom Object). FlitStack audits all custom fields during the pre-migration discovery phase and generates an unambiguous field-map document before any data writes occur, flagging any duplicate field names for your admin to clarify.