Migrate from Open Dental to Freshsales

Patient-to-Lead/Contact split requires lifecycle-stage value mapping

Open Dental stores patient status as a single PatStatus field ('I' for inactive, 'A' for active, 'P' for patient). Freshsales splits records into Leads and Contacts with separate lifecycle stages. FlitStack routes Open Dental 'Patient' status records to Freshsales Contacts and 'New Patient' or 'Prospect' status records to Freshsales Leads. Records with no treatment history but an active status require a pre-migration rule to determine the correct split. If Open Dental PatStatus is null or custom, all records default to Leads and Contacts are created after manual classification. This split affects every downstream object mapping — appointments and procedures attach to the wrong record type if the split rule is wrong.

Open Dental API rate limits require staggered read cycles

Open Dental's API enforces a strict one-request-per-five-second minimum for read-only access and one-request-per-second with full API permissions. Large practices with 10,000+ patient records need approximately 100 API calls at the five-second rate — roughly eight minutes just to read the patient table before appointments, procedures, and insurance data are queried. Freshsales throttles incoming writes at 1,000–5,000 requests per hour depending on plan tier. FlitStack paces writes at 80% of the destination tier limit and implements exponential backoff on HTTP 429 responses. A migration plan that ignores Open Dental's five-second floor will produce incomplete dataset reads or authentication errors that halt the migration mid-run.

Insurance plan hierarchy has no native Freshsales equivalent

Open Dental supports primary, secondary, and tertiary insurance plans per patient with subscriber assignment rules, BlueBook fee schedule percentages, and claim aging. Freshsales has no insurance model. FlitStack stores primary insurance carrier, plan name, group number, subscriber ID, effective date, relationship, and BlueBook percentage as custom fields on the Contact. Secondary and tertiary plans require additional custom field sets. The claim aging logic — how long a claim has been pending — cannot be represented in Freshsales without a custom date-tracking workflow. Insurance plan dropdowns in Open Dental map to flat text fields in Freshsales, removing the ability to filter contacts by insurance carrier in the same way.

Family guarantor grouping collapses to a single guarantor reference

Open Dental's Family module links multiple patients (spouse, children, dependents) to a single guarantor head-of-household via the Guarantor field. Freshsales has no family or guarantor object — a Contact has one Account and no native family-grouping mechanism. FlitStack maps the guarantor PatNum to a custom text field on each family member's Contact record. The full family tree (which patients share the same guarantor) is reconstructed post-migration by querying Guarantor_PatNum__c. Multi-generational family records where a guarantor is also a patient collapse to a single Contact with the family_gurantor field pointing to itself — this edge case requires manual cleanup.

Claim data and clinical treatment history require custom field setup

Open Dental claim records track claim number, status, date sent, date received, and insurance payment amounts. Freshsales has no native claims object. FlitStack migrates claim status and claim number as custom fields on the Contact record, with date-sent and date-received stored as custom date fields. However, the full claim ledger — adjustment amounts, write-offs, and payment plans — cannot map cleanly to Freshsales without extensive custom field proliferation. Treatment plans (proposed procedures, estimated costs, case values) are stored as custom text fields at best. The clinical depth that Open Dental captures has no meaningful CRM counterpart in Freshsales — the data migrates for reference but cannot drive Freshsales workflows.