CRM migration
Field-level mapping, validation, and rollback between Dentrix and Freshsales. We move data and schema; workflows are rebuilt natively in Freshsales.
Dentrix
Source
Freshsales
Destination
Compatibility
8 of 10
objects map 1:1 between Dentrix and Freshsales.
Complexity
BStandard
Timeline
2–4 weeks
Overview
Dentrix stores patient demographics, appointment schedules, treatment plans, insurance records, clinical notes, and provider data across multiple file-based tables. Freshsales structures data as Leads, Contacts, Accounts (companies), Deals (opportunities), Events, Tasks, and custom fields. FlitStack AI extracts Dentrix data using approved export tools and the vendor-supported migration path, then maps each Dentrix entity to the corresponding Freshsales object — Patient Name and contact details become Contacts with Account links, appointment dates and provider assignments become Events or Tasks, and insurance carrier names become Account-level custom fields. Dentrix clinical data (treatment plans, medical alerts, allergies, CDT procedure codes) has no native Freshsales equivalent; we preserve this in Deal and Contact custom fields so clinical context is available to the front desk without requiring a separate reference document. Workflows, alert rules, and clinical protocol templates are Dentrix-internal constructs that do not migrate. We use the Freshsales REST API with rate-limit awareness to load records in ordered batches, maintaining referential integrity across the Contact–Account–Deal chain. Owner resolution maps Dentrix provider names to Freshsales users by email match. A delta-pickup window captures any appointments or updates made during the cutover so the Freshsales instance reflects Dentrix final state at go-live.
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 Dentrix object lands in Freshsales, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Dentrix
Patient
Freshsales
Contact + Account
many:1Dentrix Patient records carry name, DOB, contact info, address, and an optional company/employer link. We split Patient into a Freshsales Contact (personal fields) and an Account (employer/company link) linked via Contact.AccountId. If the patient record has no employer link, the Account is created with the patient name and marked as a 'Patient Account' for reporting clarity.
Dentrix
Insurance Plan
Freshsales
Account (custom fields)
many:1Dentrix Insurance Plan records (carrier name, plan type, subscriber ID, group number, subscriber name) have no native Freshsales equivalent. We migrate each plan as an Account record using the carrier name as Account.Name, with plan type, subscriber, and group number stored as Account custom fields. Where multiple plans attach to one patient, primary and secondary assignments are preserved in a Plan_Role__c custom pick-list field on the Account.
Dentrix
Appointment
Freshsales
Event / Task
1:1Dentrix Appointment records contain date, time, duration, operatory, provider, status, and procedure codes. We map appointments to Freshsales Events using the original scheduled datetime as Event.start_date and original duration as Event.end_date, linked to the patient Contact and the provider User. Standalone appointments with no linked patient are stored as Tasks in Freshsales.
Dentrix
Provider
Freshsales
User
1:1Dentrix Provider records (dentist name, hygienist, office staff) map to Freshsales Users by email address match. We extract provider email from Dentrix's User or staff table and resolve it against Freshsales user emails during migration. Unmatched providers are flagged before the migration runs; the practice either creates a Freshsales user account or reassigns the provider's records to a designated fallback owner.
Dentrix
Treatment Record
Freshsales
Deal (custom fields)
1:1Dentrix Treatment Record lines (procedure code, tooth number, surface, fee, date, status) have no direct Freshsales equivalent. We create a Treatment_History__c custom field (long text area) on the Freshsales Deal object, serializing each treatment line with its code, tooth, surface, fee, and date in a structured format. Alternatively, we create separate custom fields — Last_Treatment_Date__c, Last_CDT_Code__c, Last_Tooth_Surface__c — for quick reference on the Deal record.
Dentrix
Clinical Note
Freshsales
Contact (custom fields)
1:1Dentrix Clinical Notes contain medical alerts, allergies, conditions, and free-text clinical observations attached to a patient. Freshsales has no clinical notes object — we create custom fields on the Contact record: Medical_Alerts__c (text), Allergies__c (text), Conditions__c (text), and Clinical_Notes__c (long text area). For practices with extensive clinical note history, we scope the migration to the most recent 12 months to avoid overwhelming the Contact record.
Dentrix
CDT Procedure Code
Freshsales
Product
1:1Dentrix stores CDT (Current Dental Terminology) procedure codes used for treatment records and fee schedules. Codes with associated fees can be mapped to Freshsales Products, where Product.Name = CDT code description and Product.UnitPrice = fee schedule amount. This enables deal-line items in Freshsales Deals to reference the correct CDT code when documenting treatment plans.
Dentrix
Ledger Entry
Freshsales
Deal (custom fields)
1:1Dentrix Ledger entries track procedure charges, payments, and adjustments against a patient account. Freshsales has no billing ledger — we create a custom field Ledger_Summary__c (long text area) on the Contact or Deal object, summarizing outstanding balance, total charges, and total payments from the most recent Dentrix ledger snapshot. This gives the front desk visibility into patient balance without requiring a separate ledger lookup.
Dentrix
Document / Attachment
Freshsales
Salesforce Files / Freshsales Files
1:1Dentrix stores attachments including insurance cards, treatment consent forms, and referral letters as linked files. We migrate these files to Freshsales Files attached to the corresponding Contact or Account record. File size limits apply — Freshsales supports uploads up to 25MB per file; larger files are flagged for manual re-upload post-migration.
Dentrix
Referral Source
Freshsales
Contact (custom field)
1:1Dentrix tracks referral source (how the patient was acquired — internal referral, external referral, marketing campaign, etc.) as a patient attribute. Freshsales does not have a native referral source field — we create a custom field Referral_Source__c (text) on the Contact record, preserving the original referral source label from Dentrix for marketing attribution and reporting continuity.
| Dentrix | Freshsales | Compatibility | |
|---|---|---|---|
| Patient | Contact + Accountmany:1 | Fully supported | |
| Insurance Plan | Account (custom fields)many:1 | Fully supported | |
| Appointment | Event / Task1:1 | Fully supported | |
| Provider | User1:1 | Fully supported | |
| Treatment Record | Deal (custom fields)1:1 | Fully supported | |
| Clinical Note | Contact (custom fields)1:1 | Fully supported | |
| CDT Procedure Code | Product1:1 | Fully supported | |
| Ledger Entry | Deal (custom fields)1:1 | Fully supported | |
| Document / Attachment | Salesforce Files / Freshsales Files1:1 | Fully supported | |
| Referral Source | Contact (custom field)1: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.
Dentrix gotchas
No public API for Dentrix G data extraction
Imaging files stored separately from patient records
Balance-forward billing ledger requires explicit handling
In-flight insurance claims must clear before cutover
Custom fields vary per practice with no standard schema
Freshsales gotchas
Freddy AI is Pro-tier only despite heavy marketing
Post-migration emails and sequences are disabled
Bot session credits are a one-time 500-session allocation
Phone credits charged per minute with no cap
File storage limits scale with plan tier
Pair-specific challenges
Migration approach
Extract Dentrix data using vendor-approved tools
We access Dentrix using Henry Schein One-approved migration utilities or direct file-level export (Patient .dat tables, Insurance Plan tables, Appointment tables, Provider/staff tables, Treatment Record tables). We extract clean CSV exports for each object, validate record counts against Dentrix's internal reports, and flag any corrupted or incomplete records before field mapping begins. If the practice lacks an active support subscription, we coordinate with Henry Schein One to obtain the required export tooling during this phase.
Map Dentrix entities to Freshsales object schema
We create a field-level mapping document mapping each Dentrix column to its Freshsales equivalent — Patient fields to Contacts and Accounts, Insurance Plans to Account custom fields, Appointments to Events, Treatment Records to Deal custom fields, and Provider names to Freshsales Users by email resolution. Custom fields (Medical_Alerts__c, Allergies__c, Plan_Type__c, Treatment_History__c, etc.) are specified for creation in Freshsales Admin before data loading. Multi-plan N:N insurance relationships are resolved to primary/secondary assignments during this phase.
Validate referential integrity and run sample migration
We validate all Contact-Account links (every Contact must resolve to an Account), Owner assignments (every record must have a Freshsales User or a designated fallback owner), and date format consistency across appointment timestamps. A representative sample migration runs first — typically 100–300 patient records spanning multiple providers and appointment types. We generate a field-level diff comparing the Dentrix source values against the Freshsales loaded values so you can verify custom field mapping correctness before the full run commits.
Execute full migration with API batch loading and delta pickup
The full migration runs in ordered batches using the Freshsales REST API with rate-limit awareness to avoid throttling. Accounts load first (required for Contact.AccountId), then Contacts with owner resolution, then Events and Tasks, then Deals with clinical custom fields. A delta-pickup window (24–48 hours) captures any appointments scheduled or patient records updated in Dentrix during the cutover so Freshsales reflects the final state at go-live. All operations are logged in an audit trail; one-click rollback reverts to the pre-migration snapshot if reconciliation finds data integrity issues.
Configure Freshsales pipelines, lifecycle stages, and admin settings
After data lands, we configure Freshsales Deal pipelines with stages matching Dentrix's appointment status labels, set up Contact Lifecycle Stages (New Patient, Active, Hygiene, Inactive) based on appointment history, and verify custom field visibility and permissions for the front desk and clinical staff profiles. Provider names from Dentrix are confirmed as resolved Freshsales Users, and any unmatched providers are escalated to your admin for account creation or owner reassignment before go-live.
Platform deep dives
Dentrix
Source
Strengths
Weaknesses
Freshsales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 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 Dentrix and Freshsales.
Object compatibility
2 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
Dentrix: Not publicly documented for Dentrix Ascend API Exchange.
Data volume sensitivity
Dentrix 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 Dentrix to Freshsales migration scoping. Not seeing yours? Book a call.
Walk through your Dentrix to Freshsales migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Dentrix
Other ways to arrive at Freshsales
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.