CRM migration

Migrate from Open Dental to Odoo CRM

Field-level mapping, validation, and rollback between Open Dental and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.

Open Dental logo

Open Dental

Source

Odoo CRM

Destination

Odoo CRM logo

Compatibility

92%

12 of 13

objects map 1:1 between Open Dental and Odoo CRM.

Complexity

BStandard

Timeline

5–10 business days

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Open Dental organizes dental-practice data around the Patient record — a composite object holding demographics, family-group membership, insurance plans, procedure history, prescriptions, and PatField custom fields. The platform exposes this data through a REST API that paginates at 100 records per request and returns Pascal-cased JSON fields. Odoo CRM models its sales side around crm.lead (unsourced pipeline entries) and res.partner (contacts/companies), with opportunity tracking via crm.lead itself once a lead converts. The two models share the concept of a named contact with contact details, but Open Dental's clinical fields — insurance carrier, Rx lists, recall schedule, treatment notes, PatFields — have no native equivalent in Odoo's standard crm module and require Odoo custom field creation before migration values can land. We extract Open Dental patients via the API using /patients endpoints with optional PatNum and SecDateTEdit filters for delta runs, resolve family-group heads using guarantor relationships, then map each record into Odoo res.partner (for existing patients) or crm.lead (for unsourced referrals). Appointment history, recall dates, and treatment notes migrate as Odoo mail.message or crm.activity records linked to the partner. Insurance plan data, Rx lists, and PatField custom values go into Odoo custom fields on res.partner — Odoo requires either Studio GUI access or a custom module with Python/XML for field creation, so we deliver a setup plan before data lands. No Open Dental workflow, automation, or practice-configuration data transfers: those constructs are destination-side schema in Odoo and must be rebuilt.

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

Odoo CRM logo

Odoo CRM

What's pulling them in

  • Teams choose Odoo CRM for its modular architecture — one base install with one-click app additions means they can adopt CRM alone and add accounting, inventory, or sales later as the business grows.
  • Small businesses pick Odoo because the Community edition is free and open-source, with no per-user or contact limits, allowing full evaluation before committing to a paid Enterprise tier.
  • The drag-and-drop Kanban pipeline and AI lead scoring are highlighted across G2 reviews as concrete features that make lead management faster and more visual than spreadsheet-based workflows.
  • Odoo's native integration with email, live chat, SMS, VoIP, and WhatsApp means inbound leads from multiple channels feed into a single pipeline without third-party middleware.
  • Companies in retail, supply chain, and construction value that Odoo's CRM module shares the same PostgreSQL database and UI as its ERP modules, eliminating data silos between sales and operations.

Object mapping

How Open Dental objects map to Odoo CRM

Each row shows how a Open Dental object lands in Odoo CRM, 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

Odoo CRM

res.partner

1:1
Fully supported

Open Dental's Patient record maps to Odoo res.partner as the primary contact entity. The patient name, birthdate, address, phone, and email fields align directly. Family-group members share one res.partner record per patient; guarantor relationships are preserved via custom field or parent_id if the family head is set as a company-type partner.

Open Dental

Patient (referral source only)

maps to

Odoo CRM

crm.lead

1:many
Fully supported

Open Dental patients that exist purely as referral sources (no appointment history, no insurance, no billing) route to Odoo crm.lead so they enter the sales pipeline without creating a full res.partner record. Any referral with actual treatment history lands as res.partner to preserve clinical context.

Open Dental

Patient (Guarantor / SuperFamilyHead)

maps to

Odoo CRM

res.partner (parent_id or custom family link)

1:1
Fully supported

Open Dental's guarantor field identifies the family-group head. Odoo res.partner has parent_id for company hierarchies only, not family groups. We map guarantor to a custom field Family_Guarantor__c on res.partner, or set the guarantor as a separate company-type partner with child partners for each family member — your admin chooses the model before migration runs.

Open Dental

Appointment

maps to

Odoo CRM

crm.activity + mail.message

1:1
Fully supported

Open Dental appointment history (date, provider, operatory, procedure codes, confirmed status) maps to Odoo crm.activity records linked to the res.partner. The appointment Note field migrates as a mail.message note attached to the activity. Original appointment timestamps are preserved in Odoo's date and create_date fields.

Open Dental

Recall

maps to

Odoo CRM

Custom field on res.partner (NextRecallDate__c) + crm.activity

1:1
Fully supported

Open Dental's Recall system tracks next cleaning or checkup dates per patient. Odoo CRM has no native recall concept. We create NextRecallDate__c and RecallType__c custom fields on res.partner and optionally schedule a crm.activity reminder for the recall date so front-office staff see it in the Odoo activity queue.

Open Dental

InsPlan + PatPlan + Benefit

maps to

Odoo CRM

Custom fields on res.partner + ir.attachment

1:1
Fully supported

Open Dental's insurance plan, patplan, and benefit tables contain normalized insurance data (carrier, group number, coverage percentages, annual maximums). Odoo CRM has no native insurance object. We map carrier name to InsuranceCarrier__c, group number to InsuranceGroup__c, and remaining benefit detail as an ir.attachment PDF or as a structured custom field depending on what your Odoo admin pre-creates.

Open Dental

RxPat (Prescription)

maps to

Odoo CRM

Custom field on res.partner (RxList__c, LastRxDate__c)

1:1
Fully supported

Open Dental prescription records list medications per patient. Odoo CRM has no native prescription object. We consolidate active prescriptions into a custom text or character field (RxList__c) and store the most-recent Rx date separately (LastRxDate__c). Full Rx history is preserved as an exported PDF attached to the partner record.

Open Dental

PatField (custom fields)

maps to

Odoo CRM

Odoo custom fields on res.partner

1:1
Fully supported

Open Dental PatFields support Text, PickList, Date, Checkbox, and Currency types. Each unique PatFieldDef in Open Dental requires a corresponding ir.model.fields entry in Odoo. We generate the Odoo custom field creation plan (field name, type, pick-list options for PickList types, and whether the field is required) so your Odoo admin can pre-create them before migration data is loaded.

Open Dental

Document (images, PDFs, scanned forms)

maps to

Odoo CRM

ir.attachment on res.partner

1:1
Fully supported

Open Dental Documents (images, PDFs, radiographs) are stored in the Open Dental folder with a DocNum reference. We re-upload all document types except x-rays (which Open Dental's own conversion docs note are best bridged rather than imported) as ir.attachment records linked to the res.partner. File size limits and MIME type handling follow Odoo's ir_attachment constraints.

Open Dental

Provider / Referring Dentist

maps to

Odoo CRM

res.partner (type=contact, customer=False)

1:1
Fully supported

Open Dental's Provider table (referring dentists, in-network providers) maps to Odoo res.partner records with customer=False so they appear in the Odoo contact directory without entering the sales pipeline. Provider specialty and NPI number map to custom fields ReferrerSpecialty__c and NPI__c.

Open Dental

ClaimProc (procedure claim history)

maps to

Odoo CRM

ir.attachment on res.partner

1:1
Fully supported

Open Dental ClaimProc records track insurance claim status per procedure. Odoo CRM has no native claims-processing module. We export claim history as a CSV and attach it to the res.partner as an ir.attachment for reference. If your Odoo setup includes the Odoo Accounting app, claim payment history can map to account.move records in a separate accounting migration.

Open Dental

ProcedureLog (completed procedures)

maps to

Odoo CRM

mail.message on res.partner

1:1
Fully supported

Open Dental procedure logs (ADA codes, tooth surfaces, surface notes, provider, date) migrate as mail.message records on the res.partner so the treatment history is visible in the Odoo chatter. Each procedure is logged as a separate message with the procedure code and description in the body.

Open Dental

Adjustment / PayPlan (billing ledger)

maps to

Odoo CRM

Custom note field or ir.attachment

1:1
Fully supported

Open Dental account module holds adjustments, payment plans, and ledger entries. Odoo CRM does not include billing ledger functionality. We export the patient ledger as a CSV and attach it to the res.partner. If you activate Odoo Accounting alongside CRM, the ledger can map to account.move and account.move.line records in a follow-on accounting migration.

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

Odoo CRM logo

Odoo CRM gotchas

High

Odoo.sh version gating blocks assisted migrations from trial

High

Enterprise modules fail to install on Community after database restore

Medium

Custom module view inheritance breaks between Odoo major versions

Medium

Custom fields risk losing their application context on Community

Low

API access for Community is gated behind the Custom Plan

Pair-specific challenges

  • PatField custom fields require Odoo custom-field creation before data lands

    Open Dental's PatFields (PatFieldDef table) define Text, PickList, Date, Checkbox, and Currency fields per patient. Odoo CRM has no PatFields analogue — each unique PatFieldDef requires an ir.model.fields entry in Odoo before migration values can write. Odoo custom fields can be created via the Studio GUI (Settings > Studio > Custom Fields on res.partner) for simple types, but PickList PatFields require a custom module with Python/XML that defines selection options. We deliver a PatField-to-Odoo-custom-field mapping plan so your Odoo admin pre-creates the schema before we load data. If custom fields are not in place at migration time, values land as null or are held in a staging table until the fields are created.

  • Family-group guarantor links do not map 1:1 to Odoo's parent_id

    Open Dental's guarantor field links each patient to their family-group head. Odoo res.partner has a parent_id field, but it is designed for company hierarchies (parent company → subsidiary), not family groups. A patient who is the guarantor for three family members cannot use parent_id for all three because Odoo enforces a single parent per partner. We surface two options before migration: (1) store guarantor as a custom many2one field (Family_Guarantor__c) pointing to the res.partner record of the family head, or (2) create a separate 'Family' res.partner (type=company) as the parent for all family members and link each patient via parent_id. Your admin chooses the model — if the wrong model is selected, all family links require a post-migration correction run.

  • Open Dental insurance plan data has no Odoo equivalent — must be manually restructured

    Open Dental's InsPlan, PatPlan, and Benefit tables are normalized insurance data (carrier, group number, subscriber relationship, coverage percentages, annual maximums, remaining benefits). Odoo CRM has no native insurance construct — these tables have no direct Odoo object. We map carrier name and group number to custom fields on res.partner, and export the full normalized benefit structure as a CSV attached to the partner as an ir.attachment. Practices that need to track insurance eligibility at the point of scheduling must activate the Odoo Field Service or custom module approach separately; this is not handled by the standard CRM migration.

  • Open Dental API pagination and field casing require ETL transformation before Odoo write

    Open Dental's REST API returns Pascal-cased field names (FName, LName, Birthdate, SecDateEntry) and paginates at 100 records per request with an optional SecDateTEdit filter for delta runs. Odoo's XML-RPC/jsonp API accepts snake_case field names (firstname, lastname, birthdate) and accepts batch writes. Our ETL layer transforms Pascal to snake_case, resolves Open Dental's date/datetime format to Odoo's UTC-aware datetime, and handles the 100-record pagination window during extraction. If Open Dental is self-hosted on a slow network, API response times can extend beyond expected pagination cycles — we add retry logic and rate-limit back-off for Enterprise-mode API limits.

  • X-ray and radiograph files cannot be migrated through the standard document flow

    Open Dental stores radiographic images (periapical, panoramic, CBCT scans) in the Documents table and references them in the Imaging module. Open Dental's own conversion documentation explicitly notes that x-ray bridges to third-party imaging software are the preferred path, not direct document migration. We skip radiographic image binary data and migrate all other document types (PDFs, consent forms, intraoral photos) as ir.attachment records. The imaging bridge recommendation is documented in the migration plan so your team can re-establish the x-ray integration in Odoo's imaging module post-migration without a data gap.

Migration approach

Six steps for a successful Open Dental to Odoo CRM data migration

  1. Audit Open Dental PatField schema and insurance table structure

    We connect to the Open Dental API (or database directly if self-hosted) and enumerate all PatFieldDef records, InsPlan records, and PatPlan relationships. We extract a full patient export including guarantor relationships, recall dates, Rx lists, and procedure history. This audit produces a PatField-to-Odoo-custom-field mapping plan with field names, Odoo field types, and pick-list options that your Odoo admin must pre-create. We also flag any patient with more than 5 active PatFields so you can decide whether to migrate all of them or prioritize a subset.

  2. Build Odoo custom field schema and family-group mapping plan

    Based on the audit, we deliver a step-by-step schema setup plan: which custom fields to create on res.partner via Odoo Studio (for simple Text/Date/Checkbox fields) and which require a custom Python module (for PickList fields with defined options). We also deliver the family-group mapping plan — for each patient with a guarantor, we specify whether the family maps via a dedicated Family partner (company-type parent) or via a custom Family_Guarantor__c field. Your Odoo admin creates the fields before we proceed to data load. We validate the schema before migration runs by doing a dry-run write on a test partner.

  3. Extract and transform patient data with ETL layer

    We extract Open Dental patients via the /patients API endpoint, paginating at 100 records per request with optional SecDateTEdit filters for delta runs. Our ETL layer transforms Pascal-cased JSON field names to Odoo's snake_case conventions, converts date formats to UTC-aware datetime, resolves guarantor PatNum values to Odoo partner IDs, and splits patients into res.partner (existing patients) and crm.lead (referral-only patients) based on appointment history. Appointment history, procedure logs, and recall dates are extracted as separate record sets linked to the patient by PatNum.

  4. Run sample migration with field-level diff and owner resolution

    A representative sample — typically 200–500 patient records spanning different clinics, family groups, and PatField configurations — migrates first. We generate a field-level diff showing source value, destination field, and mapped value for every field on each record. Owner and provider resolution is validated: Open Dental provider numbers are matched by email or name to Odoo res.users; any unmatched providers are flagged for admin review before the full run. You verify the family-group mapping and insurance field landing before we commit the full dataset.

  5. Execute full migration with delta-pickup window and rollback readiness

    The full patient dataset loads into Odoo via the XML-RPC API in sequenced batches (patients first, then appointments as activities, then documents as attachments). A delta-pickup window — typically 24–48 hours from the start of the full run — captures any patient records modified in Open Dental during cutover (new appointments, insurance updates, Rx additions). Our audit log records every write operation. If reconciliation finds discrepancies, one-click rollback reverts all Odoo records written during the migration run so you can correct the mapping and re-execute without data contamination.

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.
Odoo CRM logo

Odoo CRM

Destination

Strengths

  • Modular open-source architecture lets teams start with CRM and add ERP apps as needs grow, all sharing one PostgreSQL database.
  • Free Community edition with no contact limits and full source code access means zero licensing cost for evaluation and small deployments.
  • Drag-and-drop Kanban pipeline with AI lead scoring gives a visual, prioritized view of the sales funnel without requiring custom configuration.
  • Native integrations with email, live chat, SMS, VoIP, WhatsApp, and social media feed all inbound leads into a single unified inbox.
  • Active Odoo Community Association (OCA) maintains dozens of community-maintained modules on GitHub for extended functionality.

Weaknesses

  • Gmail and email integration reliability is a recurring complaint — threads drop and conversations scatter across inboxes, disrupting sales team workflows.
  • Enterprise edition pricing stacks quickly: multiple apps at per-user rates ($25–$50/user/month) plus Odoo.sh hosting costs more than many SMBs anticipate.
  • Setup and configuration complexity increases significantly once custom fields, automation rules, and multiple installed modules are in play.
  • Odoo.sh trial databases run on a version (e.g., 18.3) that is not directly migratable to Odoo.sh, blocking the assisted migration path Odoo advertises.
  • Version upgrades between major Odoo releases (e.g., 17→18) frequently break custom module view definitions and XPath expressions, requiring manual remediation.

Complexity grading

How hard is this migration?

Standard CRM migration. All 8 core objects map 1:1 between Open Dental and Odoo CRM.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Open Dental and Odoo CRM.

  • Object compatibility

    A

    All 8 core objects map 1:1 between Open Dental and Odoo CRM.

  • 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 Odoo CRM 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 Odoo CRM data migrations

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

Can't find your answer?

Walk through your Open Dental to Odoo CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most Open Dental to Odoo CRM migrations complete in 5–10 business days of clock time for under 25,000 patient records. Practices with more than 100,000 records, extensive PatField schemas, or multi-location Open Dental setups (using CEMT or replication) extend to 3–5 weeks. The longest single step is Odoo custom-field schema creation — your admin must pre-create PatField-equivalent fields before data can land. FlitStack AI sequences the migration so schema setup and data extraction run in parallel where possible.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Open Dental.
Land in Odoo CRM, 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