CRM migration

Migrate from Open Dental to Salesforce Sales Cloud

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 logo

Open Dental

Source

Salesforce Sales Cloud

Destination

Salesforce Sales Cloud logo

Compatibility

100%

12 of 12

objects map 1:1 between Open Dental and Salesforce Sales Cloud.

Complexity

BStandard

Timeline

48–72 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Open Dental logo

Open Dental

What's pushing teams away

  • Open Dental runs on a local Windows server that the practice must maintain; offices without dedicated IT staff experience server crashes, slowdowns, and update failures as operational risk.
  • The interface and feature set have a dated UX that newer staff find unintuitive compared to cloud-first alternatives, leading to training overhead and reduced staff satisfaction.
  • Scaling beyond two or three locations requires significant configuration work (Replication, CEMT, Enterprise features) that demands technical expertise most solo or small-group practices lack.
  • Performance degrades with large patient bases and years of transaction history stored in the same database, causing slow queries and screen delays during peak hours.

Choosing

Salesforce Sales Cloud logo

Salesforce Sales Cloud

What's pulling them in

  • The AppExchange marketplace with 5,000+ prebuilt apps gives enterprises integrations for nearly every business workflow without custom development.
  • Native Einstein AI for lead scoring, opportunity insights, and predictive forecasting adds intelligence without a separate platform purchase.
  • Territory management, multi-currency support, and advanced forecasting satisfy the needs of complex B2B sales organizations with structured revenue teams.
  • Slack, Tableau, and CPQ are deeply integrated into the core platform, keeping the sales stack unified for teams already in the Salesforce ecosystem.
  • Organizations with a large, established Salesforce implementation choose it because switching costs — integrations, custom code, trained admins — are prohibitive.

Object mapping

How Open Dental objects map to Salesforce Sales Cloud

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

maps to

Salesforce Sales Cloud

Contact

1:1
Fully supported

Open 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

maps to

Salesforce Sales Cloud

Account

1:1
Fully supported

Open 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

maps to

Salesforce Sales Cloud

Dental_Appointment__c (Custom)

1:1
Fully supported

Salesforce 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

maps to

Salesforce Sales Cloud

Insurance_Plan__c (Custom)

1:1
Fully supported

Open 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

maps to

Salesforce Sales Cloud

User / Provider__c (Custom)

1:1
Fully supported

Open 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

maps to

Salesforce Sales Cloud

Referral__c (Custom)

1:1
Fully supported

Open 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

maps to

Salesforce Sales Cloud

Dental_Procedure__c (Custom)

1:1
Fully supported

Open 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

maps to

Salesforce Sales Cloud

Prescription__c (Custom)

1:1
Fully supported

Open 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

maps to

Salesforce Sales Cloud

Lab_Case__c (Custom)

1:1
Fully supported

Open 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

maps to

Salesforce Sales Cloud

ContentDocument / Attachment

1:1
Fully supported

Open 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

maps to

Salesforce Sales Cloud

Payment__c (Custom)

1:1
Fully supported

Open 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

maps to

Salesforce Sales Cloud

Custom fields on Contact

1:1
Fully supported

Open 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.

Gotchas + challenges

What specifically takes care here

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 logo

Open Dental gotchas

High

X-ray images do not migrate between systems

Medium

Scanned documents require a separate image conversion with additional cost

High

Server must run MySQL with myISAM engine, not InnoDB

Medium

API pagination is limited to 100 records per request

Medium

Custom sheets use proprietary XML that only imports to Open Dental

Salesforce Sales Cloud logo

Salesforce Sales Cloud gotchas

High

Workflow Rules and Process Builder are retired

High

Bulk API batch quota exhaustion during large imports

Medium

Storage overage billing is non-obvious

Medium

Account-Contact many-to-many relationship mapping

Low

Territory and team member import ordering dependencies

Pair-specific challenges

  • Salesforce has no native appointment scheduling object — a custom Dental_Appointment__c object is required

    Open Dental's appointment module stores provider, operatory, assistant, length, status, and procedure codes in a structured appointment record. Salesforce Sales Cloud has no native scheduling object — Tasks and Events serve different purposes (activity logging vs. appointment scheduling). We create a custom Dental_Appointment__c object with lookups to Contact and a custom Provider__c object, plus Operatory__c, Status__c, AptDateTime__c, TimeEnded__c, and AppointmentType__c fields. The Open Dental AptNum is preserved as Source_AptNum__c for traceability. This custom object approach is the standard Salesforce pattern for dental, medical, and field-service scheduling migrations.

  • Open Dental supports multiple insurance plans per patient; Salesforce normally holds one billing contact per account

    Open Dental allows unlimited insurance plans per patient — primary, secondary, and tertiary plans each with subscriber ID, group number, coverage percentages, and fee schedules. Salesforce has no native insurance object and Salesforce Contacts typically hold one set of billing or insurance information. We create a custom Insurance_Plan__c object linked to Contact via a custom Contact__c lookup, enabling many-to-one insurance-to-patient relationships. The primary plan is also stored as a pick-list field on Contact for quick reference. This is a design decision with trade-offs: practices that need full multi-plan visibility use the custom object; practices that only need primary plan information use the custom field approach.

  • Open Dental tracks patient account balances and claims history; Salesforce Sales Cloud has no native accounting

    Open Dental's patient account module tracks balances, adjustments, payment plans, claim history, and aging reports — core to daily dental practice operations. Salesforce Sales Cloud has no native accounting, billing, or claims object. Patient balance migrates as a custom currency field (PatientBalance__c) on Contact, and claim history requires a custom Claims__c object with ClaimDate__c, ClaimAmount__c, and ClaimStatus__c fields. Full accounts-receivable management, claim tracking, and payment plan workflows require Salesforce Revenue Cloud or a dental billing software integration after migration — this is a material scope gap that should be discussed before migration scoping.

  • Open Dental provider names are free text; Salesforce requires structured User records

    Open Dental allows staff to enter provider names as free-text fields (FName + LName) attached to appointments and procedures. There is no enforcement that a provider has an email address, a license number, or a user account. Salesforce requires licensed User records to assign record ownership or to use as lookups. FlitStack resolves Open Dental providers by email address match against existing Salesforce Users. For providers without an email in Open Dental, we create a custom Provider__c object storing ProvNum, name, specialty, NPI__c, and License__c, then use a Provider__c lookup on Dental_Appointment__c and Dental_Procedure__c. Your team decides which providers need Salesforce User licenses before migration.

  • Open Dental PatFields use multiple data types; Salesforce custom fields must match exactly

    Open Dental PatFields support text, pick-list, date, checkbox, and currency field types defined at the PatFieldDef level. Salesforce custom fields must be created with matching data types — a pick-list in Open Dental cannot migrate to a text field in Salesforce without losing the structured values. FlitStack audits all PatFieldDef field types before migration and creates Salesforce custom fields of the identical type. Formula-based PatFields in Open Dental (calculated from other fields) have no Salesforce equivalent and are flagged for manual rebuild as Salesforce formula fields post-migration. The full PatField audit is included in the pre-migration schema plan.

Migration approach

Six steps for a successful Open Dental to Salesforce Sales Cloud data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

Context on both ends of the pair

Open Dental logo

Open Dental

Source

Strengths

  • One-time license fee with no per-seat recurring cost after the first year, making it the lowest total cost of ownership for stable practices.
  • Open-source codebase means the database schema is publicly documented and independent developers can build integrations without vendor dependency.
  • Multi-location support through Clinics, Replication, and CEMT scales from a single practice to a DSO with 30+ locations on a single database.
  • API with REST endpoints for Patients, Appointments, Claims, Payments, PayPlans, Documents, and Setup gives third-party tools a reliable integration surface.
  • Strong practitioner community and independent trainer ecosystem produce extensive documentation, forum support, and video walkthroughs for self-service learning.

Weaknesses

  • Server-based deployment requires the practice to own or rent server infrastructure and maintain Windows Server, MySQL, and .NET dependencies locally.
  • No cloud-hosted SaaS option built and supported directly by Open Dental Software; third-party hosting providers add variable cost and support tiers.
  • Interface design reflects its 2003 origins and has not undergone the UX modernization that cloud competitors have invested in heavily.
  • Performance degrades noticeably as the database grows to hundreds of thousands of patients and millions of procedure rows, requiring periodic database maintenance.
Salesforce Sales Cloud logo

Salesforce Sales Cloud

Destination

Strengths

  • Largest enterprise app ecosystem in CRM with 5,000+ AppExchange integrations covering nearly every vertical workflow.
  • Native Einstein AI delivers lead scoring, opportunity insights, and predictive forecasting without a third-party layer.
  • Advanced territory management, multi-currency, and flexible forecasting satisfy complex B2B revenue structures.
  • Deep platform extensibility: Custom Objects, Apex, Flow, and the Metadata API allow full schema customization.
  • Well-documented REST API, Bulk API, and Composite API with published rate limits for programmatic migration.

Weaknesses

  • Pricing model is layered and opaque in practice: per-seat fees plus storage overages, add-on subscriptions, and annual uplifts compound to 30–40% above sticker price.
  • Workflow Rules and Process Builder are deprecated, forcing all orgs onto Salesforce Flow — a migration task that catches many teams by surprise.
  • Steep administrative complexity: meaningful configuration requires a dedicated Salesforce admin or consultant.
  • API rate limits are edition-gated (100k/day base for Enterprise) and easily exhausted by large historical imports without throttling.
  • Data export is exportable via Data Loader but preserving relationship integrity across 30+ objects requires careful ETL sequencing.

Complexity grading

How hard is this migration?

Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Open Dental and Salesforce Sales Cloud.

  • Object compatibility

    B

    1 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Open Dental: Remote mode: 1,000 elements; Local/Service mode: 10,000 elements; Enterprise tier doubles Remote mode limits.

  • Data volume sensitivity

    B

    Open Dental doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Open Dental to Salesforce Sales Cloud migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Open Dental to Salesforce Sales Cloud data migrations

Answers to the questions buyers ask most during Open Dental to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most Open Dental to Salesforce migrations complete in 48–72 hours of clock time for under 50,000 patient records. Larger setups with 50,000–500,000 records extend to 5–10 days. Enterprise-grade migrations with multi-location clinic setups, extensive procedure histories, and multiple insurance plans per patient can run 10–21 days. The custom schema setup step is the longest planning phase — it requires Salesforce admin approval before data moves.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Open Dental.
Land in Salesforce Sales Cloud, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day