CRM migration
Field-level mapping, validation, and rollback between Open Dental and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
Open Dental
Source
Salesforce Sales Cloud
Destination
Compatibility
12 of 12
objects map 1:1 between Open Dental and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
48–72 hours
Overview
Open Dental is a patient-centered dental practice management system where the Patient record is the root entity — linked to family guarantors, multiple insurance plans, appointments, procedures, prescriptions, referrals, and financial balances. Salesforce Sales Cloud is a sales-oriented CRM built around the Contact-to-Account relationship with separate objects for Leads, Opportunities, Tasks, and Events. There is no native dental or scheduling model in Salesforce Sales Cloud. FlitStack AI migrates all structured Open Dental data — patients, guarantors, appointments, procedures, providers, insurance plans, prescriptions, referrals, lab cases, documents, and payments — into Salesforce as Contacts, Accounts, and custom dental objects. We preserve every original Open Dental identifier (PatNum, AptNum, ProcNum) as custom fields for traceability and delta-run de-duplication. Open Dental workflows, automation rules, and eForm configurations do not migrate and must be rebuilt in Salesforce Flow — we export those definitions as a rebuild reference. The migration runs via Open Dental's REST API (paginated, up to 100 records per page) with Salesforce Bulk API for high-volume writes into custom objects. A 24–48 hour delta pickup window captures any records modified during the cutover before the go-live reconciliation.
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 Open Dental object lands in Salesforce Sales Cloud, 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
Salesforce Sales Cloud
Contact
1:1Open Dental Patient maps to Salesforce Contact. The PatNum is stored as Source_System_ID__c on the Contact for traceability and delta‑run de‑duplication. Family members without guarantor status are created as separate Contacts linked via AccountId, preserving the family hierarchy and enabling reporting across the Account.
Open Dental
Patient.Guarantor
Salesforce Sales Cloud
Account
1:1Open Dental's guarantor concept (the financially responsible party) maps to Salesforce Account. For family groups, the guarantor is the parent Account and family members are Contacts linked to that Account. Multi-person families use Account hierarchies to preserve the financial responsibility chain.
Open Dental
Appointment
Salesforce Sales Cloud
Dental_Appointment__c (Custom)
1:1Salesforce has no native scheduling object. FlitStack creates a custom Dental_Appointment__c object with lookups to Contact (patient) and Provider__c (custom), plus Operatory__c, Status__c, AptDateTime__c, TimeEnded__c, Length__c, and AppointmentType__c fields. Open Dental's AptNum is preserved as Source_AptNum__c. The custom object also includes a Clinic__c lookup for multi-location practices and an Appointment_Notes__c text area for provider instructions.
Open Dental
InsPlan
Salesforce Sales Cloud
Insurance_Plan__c (Custom)
1:1Open Dental's insurance plan model has no Salesforce equivalent. We create a custom Insurance_Plan__c object with SubscriberID__c, Relationship__c, EffectiveDate__c, GroupNum__c, CopayAmount__c, CoveragePercentage__c, and FeeSchedule__c fields, linked to Contact via Contact__c lookup. Primary plan is also stored as Insurance_Plan_Primary__c pick-list on Contact.
Open Dental
Provider
Salesforce Sales Cloud
User / Provider__c (Custom)
1:1Open Dental provider names are free text. FlitStack matches providers by email to Salesforce User records. For providers without email in Open Dental, we create a custom Provider__c object to store ProvNum, Name, Specialty, NPI__c, and License__c, then use a Provider__c lookup on Dental_Appointment__c and Dental_Procedure__c.
Open Dental
Referral
Salesforce Sales Cloud
Referral__c (Custom)
1:1Open Dental tracks incoming and outgoing referrals with referral source, date, and status. Salesforce has no native referral object. We create a custom Referral__c object linked to Contact (patient), with RefSource__c, RefDate__c, RefStatus__c, and RefProvider__c fields. Referring dentist contact details stored as RefName__c and RefPhone__c.
Open Dental
ProcedureLog
Salesforce Sales Cloud
Dental_Procedure__c (Custom)
1:1Open Dental procedure codes (ADA D####), tooth information, surfaces, and clinical notes have no Salesforce equivalent. We create a custom Dental_Procedure__c object with Code__c, Description__c, Tooth__c, Surfaces__c, ProcStatus__c, ProvNum__c, AptNum__c (lookup), ProcFee__c, and Notes__c fields, linked to Contact (patient). Planned vs. completed procedures mapped via ProcStatus__c pick-list.
Open Dental
RxPat
Salesforce Sales Cloud
Prescription__c (Custom)
1:1Open Dental prescriptions with medication name, dosage, frequency, and pharmacy routing have no Salesforce equivalent. We create a custom Prescription__c object linked to Contact, with Medication__c, Dosage__c, Frequency__c, Pharmacy__c, RxDate__c, and ProvNum__c lookup fields. Controlled substance fields preserved as PrescriptionNotes__c.
Open Dental
LabCase
Salesforce Sales Cloud
Lab_Case__c (Custom)
1:1Open Dental lab cases with lab name, prescription date, due date, tracking status, and instructions require a custom Salesforce object. We create Lab_Case__c with LabName__c, PrescriptionDate__c, DueDate__c, Status__c, Instructions__c, and AptNum__c lookup. Lab contact information stored as LabName__c and LabPhone__c text fields.
Open Dental
Document
Salesforce Sales Cloud
ContentDocument / Attachment
1:1Open Dental documents and scanned files are re-uploaded to Salesforce Files (ContentDocument) or Attachments linked to the patient Contact. File size limits apply — Salesforce default is 25MB per file. Inline images in notes are extracted and re-hosted as Salesforce Files.
Open Dental
Payment / PayPlan
Salesforce Sales Cloud
Payment__c (Custom)
1:1Open Dental payment history and payment plans with amounts, dates, and methods do not map to standard Salesforce fields. We create a custom Payment__c object linked to Contact with PaymentDate__c, Amount__c, PayMethod__c, PayPlanNum__c, and Adjustment__c fields. Full accounting capabilities require Salesforce Revenue Cloud post-migration.
Open Dental
PatField
Salesforce Sales Cloud
Custom fields on Contact
1:1Open Dental PatFields (custom fields in patient info, account, and chart modules) support text, pick-list, date, checkbox, and currency field types. Each PatField migrates as a Salesforce custom field of the matching type on Contact, with FieldName__c preserved as the API name. Formula PatFields are noted for manual rebuild as Salesforce formula fields.
| Open Dental | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Patient | Contact1:1 | Fully supported | |
| Patient.Guarantor | Account1:1 | Fully supported | |
| Appointment | Dental_Appointment__c (Custom)1:1 | Fully supported | |
| InsPlan | Insurance_Plan__c (Custom)1:1 | Fully supported | |
| Provider | User / Provider__c (Custom)1:1 | Fully supported | |
| Referral | Referral__c (Custom)1:1 | Fully supported | |
| ProcedureLog | Dental_Procedure__c (Custom)1:1 | Fully supported | |
| RxPat | Prescription__c (Custom)1:1 | Fully supported | |
| LabCase | Lab_Case__c (Custom)1:1 | Fully supported | |
| Document | ContentDocument / Attachment1:1 | Fully supported | |
| Payment / PayPlan | Payment__c (Custom)1:1 | Fully supported | |
| PatField | Custom fields on Contact1: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.
Open Dental gotchas
X-ray images do not migrate between systems
Scanned documents require a separate image conversion with additional cost
Server must run MySQL with myISAM engine, not InnoDB
API pagination is limited to 100 records per request
Custom sheets use proprietary XML that only imports to Open Dental
Salesforce Sales Cloud gotchas
Workflow Rules and Process Builder are retired
Bulk API batch quota exhaustion during large imports
Storage overage billing is non-obvious
Account-Contact many-to-many relationship mapping
Territory and team member import ordering dependencies
Pair-specific challenges
Migration approach
Stand up Salesforce custom schema first
Before any data moves, FlitStack creates the Salesforce custom objects and fields required for the Open Dental data model. This includes Dental_Appointment__c, Dental_Procedure__c, Insurance_Plan__c, Provider__c, Referral__c, Prescription__c, Lab_Case__c, and Payment__c objects, plus all custom fields on Contact and Account (Source_PatNum__c, PatientBalance__c, BillingType__c, Original_Create_Date__c, Insurance_Plan_Primary__c, etc.). We deliver a schema setup plan with API names, field types, and pick-list values so your Salesforce admin can pre-approve the configuration before data lands.
Resolve Open Dental providers to Salesforce Users
FlitStack extracts all Open Dental provider records and attempts to match them by email address against existing Salesforce Users. Matched providers link directly to Salesforce User records. Providers without an email get a custom Provider__c record with their ProvNum, name, specialty, NPI__c, and License__c preserved. Unmatched providers are flagged for your team to either create Salesforce User accounts or confirm the custom Provider__c approach. This step must complete before appointment and procedure records can resolve their provider lookups.
Migrate patients, guarantors, and family links
FlitStack extracts all Open Dental patients and their guarantor relationships. Each patient becomes a Salesforce Contact with Source_PatNum__c, Original_Create_Date__c, BillingType__c, and PatientBalance__c preserved. The guarantor patient record becomes both a Contact and an Account (for financial responsibility). Family members link to the guarantor Account via AccountId. For practices with clinic locations, we create a Clinic__c custom object and link each Contact to their primary clinic via Clinic__c lookup. This step creates the parent records that appointments, procedures, and insurance plans reference.
Run a sample migration with field-level diff
A representative slice of 50–100 records — spanning patients, appointments, procedures, insurance plans, and referrals — migrates first. FlitStack generates a field-level diff report comparing source values against destination field values so your team can verify mapping correctness. The report checks Contact names, appointment times and providers, procedure codes and fees, insurance plan fields, and lookup resolution. You review the diff, confirm mapping accuracy, and FlitStack addresses any field mapping corrections before the full migration runs.
Execute full migration with delta-pickup and rollback
The full Open Dental export runs via the REST API (paginated at 100 records per call) with writes to Salesforce via Bulk API. After the initial load, a delta-pickup window of 24–48 hours captures any records created or modified in Open Dental during the cutover period. FlitStack maintains an audit log of every record created, updated, or skipped. If reconciliation fails, one-click rollback reverts the Salesforce org to its pre-migration state. You can continue working in Open Dental throughout the migration window — FlitStack uses read-only API access only.
Platform deep dives
Open Dental
Source
Strengths
Weaknesses
Salesforce Sales Cloud
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 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 Open Dental and Salesforce Sales Cloud.
Object compatibility
1 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
Open Dental: Remote mode: 1,000 elements; Local/Service mode: 10,000 elements; Enterprise tier doubles Remote mode limits.
Data volume sensitivity
Open Dental 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 Open Dental to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Open Dental to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Open Dental
Other ways to arrive at Salesforce Sales Cloud
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.