CRM migration
Field-level mapping, validation, and rollback between Open Dental and Pipedrive. We move data and schema; workflows are rebuilt natively in Pipedrive.
Open Dental
Source
Pipedrive
Destination
Compatibility
10 of 10
objects map 1:1 between Open Dental and Pipedrive.
Complexity
BStandard
Timeline
48–72 hours
Overview
Open Dental and Pipedrive are fundamentally different tools: Open Dental is a practice management system built around patients, clinical procedures, insurance billing, and appointments. Pipedrive is a sales CRM built around people, organizations, deals, and activities. There is no native equivalent in Pipedrive for CDT procedure codes, insurance benefit tables, tooth charts, or billing ledgers — these must be surfaced as custom fields or declared out of migration scope. FlitStack AI sequences the migration so patient records land first, then insurance carriers resolve as Pipedrive Organizations, providers map as Person records with a provider-role tag, and appointment history converts to Pipedrive Activities. Family grouping uses a custom field (Family_Guarantor) to preserve guarantor relationships that Open Dental tracks natively. We handle Open Dental's 100-record pagination, PascalCase field names, and date-format conversion. Clinical procedure data, insurance benefit accruals, and billing ledgers have no Pipedrive equivalent and are migrated as custom fields or documented as out-of-scope. We run a sample migration against 200–500 patient records before the full run, with a 24–48h delta-pickup window capturing any records modified during cutover.
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 Pipedrive, 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
Pipedrive
Person
1:1Open Dental's Patient table maps directly to Pipedrive Person. Fields including FName, LName, Birthdate, Address, City, State, Zip, HmPhone, WkPhone, and Email map to Pipedrive's name, phone, and email fields. Open Dental's PatNum is stored as Source_System_ID__c for traceability. This mapping ensures that each patient appears as a unique Person record with all standard contact details and a reference to the original PatNum for later reconciliation.
Open Dental
Family / Guarantor
Pipedrive
Person (custom field)
1:1Open Dental tracks Family with a GuarantorPatNum link. Pipedrive has no family or guarantor concept. We create a custom field Family_Guarantor_PatNum__c on the Person record, preserving the guarantor link. Family members without a direct Pipedrive equivalent are cross-referenced via this custom field.
Open Dental
InsPlan (Primary)
Pipedrive
Organization + Custom Fields on Person
1:1Open Dental's InsPlan table holds insurance carrier name, plan name, subscriber ID, and group number. We map InsPlan.CarrierName to a Pipedrive Organization record. The subscriber ID and group number become custom fields on the Person record linking the patient to that insurance Organization.
Open Dental
InsPlan (Secondary)
Pipedrive
Organization + Custom Fields on Person
1:1A patient with secondary insurance in Open Dental follows the same pattern as primary — a second InsPlan resolves to a second Organization record. Subscriber relationship (self, spouse, child) is stored as a custom field Secondary_Subscriber_Rel__c on the Person record.
Open Dental
PatPlan
Pipedrive
Custom Fields on Person
1:1PatPlan links patients to insurance plans withordinal values (1=primary, 2=secondary). We surface plan ordinal, subscriber ID, and group number as custom fields on the Person: Insurance_Primary_Plan__c, Insurance_Secondary_Plan__c, SubscriberID__c, GroupNum__c. Each PatPlan entry also carries a relationship code indicating whether the subscriber is self, spouse, or dependent, which we store in Subscriber_Relationship__c for complete insurance context.
Open Dental
Appointment
Pipedrive
Activity
1:1Open Dental appointments (AptNum, ProvNum, Operatory, AptDateTime, Confirmed status) convert to Pipedrive Activities. Activity Type maps to 'Appointment'; Subject becomes the appointment date + provider name. Provider and operatory are stored as custom fields on the Activity since Pipedrive's Activity owner maps to the Open Dental provider.
Open Dental
ProcedureLog
Pipedrive
Custom Fields / Notes on Person
1:1ProcedureLog contains CDT codes, tooth numbers, surface, provider, treatment date, and fee. Pipedrive has no clinical object. We surface the last procedure date and a summary of recent CDT codes as custom fields; full procedure history is stored as a Pipedrive Note attached to the Person record.
Open Dental
Provider
Pipedrive
Person (with label)
1:1Open Dental Provider records (ProvNum, Abbr, FName, LName, Specialty) have no Pipedrive equivalent. We create a Person record for each provider, tagged with a custom field Provider_Role__c set to 'Dental Provider', and optionally link them as Activity owners when appointments migrate.
Open Dental
PatField (Custom Fields)
Pipedrive
Custom Fields on Person
1:1Open Dental PatFields (FieldName, FieldValue) store custom per-patient data. We read PatFieldDefs to identify all custom field types (text, picklist, date, checkbox, currency) and recreate equivalent custom fields on the Pipedrive Person object. FieldType mapping: date to date picker, checkbox to boolean, currency to number, picklist to options.
Open Dental
Referral
Pipedrive
Person (with label)
1:1Open Dental Referral source (RefNum, RefType, LName, FName) has no Pipedrive equivalent. We create a Person record for each referral source, tagged with Referral_Source__c = true, so the referral can be associated with patient records manually in Pipedrive. We also capture the original RefNum as a custom field (Source_System_RefNum__c) for audit traceability, allowing you to reference the original referral identifier in future reporting.
| Open Dental | Pipedrive | Compatibility | |
|---|---|---|---|
| Patient | Person1:1 | Fully supported | |
| Family / Guarantor | Person (custom field)1:1 | Fully supported | |
| InsPlan (Primary) | Organization + Custom Fields on Person1:1 | Fully supported | |
| InsPlan (Secondary) | Organization + Custom Fields on Person1:1 | Fully supported | |
| PatPlan | Custom Fields on Person1:1 | Fully supported | |
| Appointment | Activity1:1 | Fully supported | |
| ProcedureLog | Custom Fields / Notes on Person1:1 | Fully supported | |
| Provider | Person (with label)1:1 | Fully supported | |
| PatField (Custom Fields) | Custom Fields on Person1:1 | Fully supported | |
| Referral | Person (with label)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.
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
Pipedrive gotchas
Custom field hash keys differ per account
Export access gated by visibility groups
Token-based API rate limits since December 2024
Sequences and Automations not exposed via REST API
Cost escalates via workflow caps and add-ons
Pair-specific challenges
Migration approach
Audit Open Dental schema and export patient data in paginated batches
FlitStack AI authenticates against Open Dental's REST API using your practice credentials. We read the Patient table, InsPlan table, PatPlan link table, Provider table, Appointment table, ProcedureLog table, Referral table, and PatFieldDef / PatField tables. Because the API returns a maximum of 100 records per page, we run a paginated export loop across all pages, storing a session marker so interrupted exports can resume cleanly. We generate a schema inventory document listing every PatField, InsPlan, and Provider in your database before field mapping begins.
Pre-create Pipedrive custom fields and insurance Organization records
Before any data lands in Pipedrive, FlitStack AI creates the custom fields needed on the Person object: Insurance_Primary_Plan__c, Insurance_Secondary_Plan__c, SubscriberID__c, GroupNum__c, Subscriber_Relationship__c, Last_Visit_Date__c, Next_Appointment__c, Recent_CDT_Codes__c, Family_Guarantor_PatNum__c, Source_System_ID__c, and any custom PatField mappings identified in the audit. We also pre-create Pipedrive Organizations for each unique insurance carrier identified in InsPlan. We then configure field visibility and required flags for each custom property, record the field IDs in the migration manifest, and verify that downstream Pipedrive APIs can resolve fields by name before bulk loading begins.
Run a sample migration with field-level diff on 200–500 patient records
A representative slice of patient records — spanning patients with and without insurance, single and family records, and appointments — migrates to Pipedrive first. We generate a field-level diff between the Open Dental source record and the Pipedrive destination record, covering every custom field, insurance link, and activity. You verify that insurance carrier names collapsed correctly, appointment history created the expected Pipedrive Activities, and provider Person records resolved before dependent appointments are linked. We iterate on the mapping plan until the diff passes before the full run commits.
Execute the full migration and delta-pickup window for in-flight records
The complete patient dataset migrates: Patients → Pipedrive People with all custom fields, InsPlan → Pipedrive Organizations with carrier links, Providers → Pipedrive People with Provider_Role__c, Referrals → Pipedrive People with Referral_Source__c, and Appointments → Pipedrive Activities linked to the correct Person owner. A delta-pickup window (typically 24–48 hours) runs after the full migration completes, capturing any Open Dental records created or modified during the cutover. Every operation is logged in an audit trail, and a one-click rollback reverts Pipedrive to its pre-migration state if reconciliation fails.
Platform deep dives
Open Dental
Source
Strengths
Weaknesses
Pipedrive
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 3 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 Pipedrive.
Object compatibility
3 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 Pipedrive migration scoping. Not seeing yours? Book a call.
Walk through your Open Dental to Pipedrive 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 Pipedrive
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.