Migrate from Curve Dental to Freshsales

Curve Dental patient records migrate as Freshsales Contacts. First name, last name, email, phone, address, and date of birth map directly. All other clinical fields (to be identified in discovery) become Freshsales custom fields on the Contact. Source create and modify timestamps are preserved as custom datetime fields since Freshsales CreatedDate reflects migration time.

The dental practice or employer organization in Curve Dental maps to a Freshsales Account. Practice name, address, and contact details become Account-level fields. If the Curve Dental record links patients to employers, those links surface as Account Contact Relationships in Freshsales.

Curve Dental provider records require admin decision before migration: if providers should have CRM login access, they become Freshsales Users (matched by email); if they are referral sources or referral dentists, they become Contacts with a Provider_Type__c custom field set to their clinical role. User roles in Freshsales (Admin, Salesperson, Leader) do not directly map to clinical roles — mapping is admin-defined.

Curve Dental appointments migrate as Freshsales Events linked to the Contact (patient). Appointment date/time maps to Event start_time and end_time, status maps to Freshsales Event status via a value-mapping table, and the provider maps to the Event owner (resolved by email to a Freshsales User). Operatory and chair-time fields have no Freshsales equivalent — they are stored as custom fields on the Event.

Curve Dental procedure codes (D#### CDT codes or internal codes) are mapped to Freshsales custom pick-list or text fields on the Event. Each procedure code value is mapped value-by-value so the Freshsales UI shows readable procedure names rather than raw codes.

Treatment plans with a billing component migrate as Freshsales Deals with a linked Contact. Treatment phases, procedure codes, fee estimates, and clinical notes become custom fields on the Deal. Simple treatment plans with no open deal become Contact-level custom fields or structured Notes, avoiding the creation of empty Deals in Freshsales.

Insurance carrier name, group number, subscriber ID, and relationship (self, spouse, dependent) have no Freshsales standard field. They become custom fields on the Contact: Insurance_Carrier__c, Insurance_Group_Number__c, Insurance_Subscriber_ID__c, and Insurance_Relationship__c. Multiple insurance plans per patient require a separate Insurance Plan custom field group.

Outstanding balance, total paid, and last payment date migrate as custom number and date fields on the Contact record (Last_Payment_Date__c, Total_Paid__c, Outstanding_Balance__c). Freshsales has no native accounts receivable object; detailed ledger history is stored as a structured Note or referenced in an attached PDF export.

Clinical progress notes from Curve Dental migrate as Freshsales Notes linked to the Contact. Notes are stored with the original note date preserved (as Note body text) and the provider as Note owner. Rich-text formatting from Curve notes is simplified to plain text since Freshsales Notes do not support full rich-text.

Tooth-number charting, existing restorations, missing teeth, and perio pocket depth readings are dental-specific with no Freshsales standard equivalent. We create custom fields (Tooth_Chart__c as long-text, Perio_Readings__c as long-text) and preserve the full charting data as a structured text block. Original exam dates are stored as custom date fields.

X-ray files and intraoral images attached to Curve Dental patient records are downloaded and re-uploaded as Freshsales file attachments on the Contact. Freshsales file storage limits apply per plan (2GB per user on Growth; 5GB on Pro; 100GB on Enterprise). We flag any files exceeding the destination limit before migration.

Curve Dental recall dates (6-month hygiene, annual exam) have no Freshsales standard field. We migrate the recall date as Next_Recall_Date__c custom field on the Contact and the recall type as Recall_Type__c. Freshsales workflows can then trigger off Next_Recall_Date__c to create Tasks for follow-up, but the workflow itself must be rebuilt.