CRM migration
Field-level mapping, validation, and rollback between The Dental System and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
The Dental System
Source
Odoo CRM
Destination
Compatibility
10 of 10
objects map 1:1 between The Dental System and Odoo CRM.
Complexity
BStandard
Timeline
48–72 hours
Overview
The Dental System stores patient demographics, treatment records, appointments, insurance policies, and clinical notes within a dental-specific data model that Odoo CRM does not replicate natively. The migration translates The Dental System's patient records into Odoo's res.partner model, maps treatment histories to custom fields on the contact record, and routes appointments into Odoo's activity logging system with preserved timestamps and provider assignments. Clinical procedure codes, tooth-number references, and ADA diagnostic codes have no native Odoo equivalent and require custom fields created before the migration runs. Dental-system attachments and files re-upload into Odoo Documents with a source-reference custom field. We handle the API extraction from The Dental System, the relational integrity checks across patients, appointments, and treatments, and the Odoo XML-RPC bulk write. Automations, appointment reminders, and recall workflows built inside The Dental System do not migrate — we export those definitions as a rebuild reference for your Odoo configuration. Pre-migration validation ensures data integrity, and post-migration support assists with Odoo configuration fine-tuning as your team adopts the new workflow.
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 The Dental System 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.
The Dental System
Patient
Odoo CRM
res.partner
1:1Patient records map to Odoo res.partner in the 'contact' mode. Patient name, date of birth, gender, phone, email, and address fields translate directly. Dental-specific fields (allergies, blood type, insurance metadata) create custom fields on the partner record. The source patient ID is stored as Source_Dental_System_ID__c for traceability.
The Dental System
Appointment
Odoo CRM
crm.activity / calendar.event
1:1Appointments from The Dental System migrate as Odoo CRM Activities (planned calls/meetings) with a custom Activity Type of 'Dental Appointment'. Procedure type, tooth number, operatory, and dentist assignment are stored as custom fields on the activity record. Original appointment start/end times are preserved. Multiple appointments per patient are linked via the partner_id field.
The Dental System
Treatment Record
Odoo CRM
custom: crm.lead (dental treatment) / custom module
1:1Treatment records map to a custom Odoo model or crm.lead record with a 'treatment' category. ADA procedure codes, diagnosis codes, prescribed medications, follow-up dates, and treatment cost migrate as custom fields. Each treatment record is linked to the patient partner as a related record. Status (completed, planned, cancelled) maps to the stage field.
The Dental System
Insurance Policy
Odoo CRM
custom: dental.insurance (linked to res.partner)
1:1Insurance carrier, policy number, group number, subscriber relationship, and coverage notes migrate as custom fields on a dental.insurance model or stored directly on the res.partner record via a dedicated Insurance tab. Subscriber name resolves to a related partner if the subscriber is also a patient in the system.
The Dental System
Clinical Note / Progress Note
Odoo CRM
crm.note / ir.attachment
1:1Clinical notes with short text migrate as CRM Notes linked to the patient partner, with a custom 'Clinical Note' category field and the original note date preserved. Long-form clinical notes with attachments (chart exports, imaging references) migrate as Odoo Attachments on the partner record with a source-reference custom field set to 'The Dental System'.
The Dental System
Prescription / Medication Record
Odoo CRM
custom: dental.prescription (linked to res.partner)
1:1Prescription records migrate as custom prescription objects linked to the patient partner. Medication name, dosage, frequency, prescribed date, and prescribing provider are custom Char and Date fields. Instructions text is stored in a Text field. The prescription record is linked to the treatment plan it accompanies via a Many2one relationship.
The Dental System
Treatment Plan
Odoo CRM
custom: dental.treatment_plan (linked to res.partner)
1:1Treatment plans (proposed procedures, phased treatment schedules) migrate as custom treatment-plan records linked to the patient partner. Each plan captures plan name, description, proposed ADA codes, estimated cost, and planned start date as custom fields. Individual planned procedures within the plan link to individual treatment-record custom objects.
The Dental System
User / Staff Member
Odoo CRM
res.users
1:1Staff records from The Dental System (dentist, hygienist, front desk, office manager roles) map to Odoo res.users by email match. Role-based permissions in The Dental System require manual Odoo group assignment post-migration — admin, manager, and user roles map to Odoo groups and record rules based on your Odoo profile configuration.
The Dental System
Company / Practice Entity
Odoo CRM
res.company
1:1If The Dental System holds a parent practice entity separate from patient records, that entity maps to Odoo res.company. Multi-location practices require separate company records in Odoo's multi-company configuration — we deliver a company-structure plan before migration data is written.
The Dental System
Attachment / File
Odoo CRM
ir.attachment
1:1File attachments (patient forms, insurance cards, consent documents) from The Dental System are downloaded and re-uploaded to Odoo ir.attachment linked to the corresponding partner record. Large imaging files (X-rays, CBCT exports) are flagged by file size — files over Odoo's default 25MB per attachment limit require manual relocation or Odoo Documents configuration.
| The Dental System | Odoo CRM | Compatibility | |
|---|---|---|---|
| Patient | res.partner1:1 | Fully supported | |
| Appointment | crm.activity / calendar.event1:1 | Fully supported | |
| Treatment Record | custom: crm.lead (dental treatment) / custom module1:1 | Fully supported | |
| Insurance Policy | custom: dental.insurance (linked to res.partner)1:1 | Fully supported | |
| Clinical Note / Progress Note | crm.note / ir.attachment1:1 | Fully supported | |
| Prescription / Medication Record | custom: dental.prescription (linked to res.partner)1:1 | Fully supported | |
| Treatment Plan | custom: dental.treatment_plan (linked to res.partner)1:1 | Fully supported | |
| User / Staff Member | res.users1:1 | Fully supported | |
| Company / Practice Entity | res.company1:1 | Fully supported | |
| Attachment / File | ir.attachment1: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.
The Dental System gotchas
No documented public API
Custom field discovery requires manual audit
Insurance carrier and payer data may require re-credentialing
Document storage may not be directly accessible for bulk export
Odoo CRM gotchas
Odoo.sh version gating blocks assisted migrations from trial
Enterprise modules fail to install on Community after database restore
Custom module view inheritance breaks between Odoo major versions
Custom fields risk losing their application context on Community
API access for Community is gated behind the Custom Plan
Pair-specific challenges
Migration approach
Extract and profile The Dental System data
We connect to The Dental System via its export or API interface and extract all patient records, appointment histories, treatment plans, insurance entries, prescription data, and attachment metadata. A data-profiling report is generated: field-by-field null rate, duplicate detection, date-range coverage, and attachment file-size summary. This report identifies the scope of custom fields required in Odoo before any schema work begins on the destination side.
Design Odoo CRM schema and custom fields
Based on the profiling report, we create a schema design document specifying every custom field on res.partner (allergy flags, insurance metadata, blood type, medical alerts), the activity custom fields for appointments (procedure type, tooth number, operatory), and the treatment-record custom model. If your practice uses an OCA dental module or a custom Odoo add-on, we confirm that module is installed and active before defining field names to avoid conflicts. The schema design document is reviewed by your Odoo administrator before any data mapping begins.
Map patient-to-partner relationships and resolve staff user accounts
We establish the primary patient record for each appointment and treatment history in The Dental System, linking multiple appointments to a single res.partner record. Staff dentist and hygienist IDs in The Dental System are matched to Odoo res.users by email address. Any staff member without an existing Odoo user account is flagged for your team to create or assign before the migration run — no appointment or treatment record is written without a resolved owner in Odoo.
Run sample migration with field-level diff
A representative slice — typically 200–500 patient records spanning several appointment histories, treatment records, and a sample of attachments — migrates to your Odoo instance first. We generate a field-level diff comparing the source values against the Odoo record values so you can verify that ADA codes, tooth numbers, insurance fields, and allergy data are all correctly populated in the custom fields. Any mapping gaps are corrected before the full migration is scheduled.
Execute full migration with delta-pickup window
The full dataset migrates to Odoo CRM with all custom fields populated. A delta-pickup window (24–48 hours) captures any new patient records, modified appointment statuses, or updated insurance information created in The Dental System during the cutover. All operations are logged to an audit trail, and one-click rollback is available if a mapping error surfaces during reconciliation. After validation, The Dental System is set to read-only and your team transitions to Odoo CRM.
Platform deep dives
The Dental System
Source
Strengths
Weaknesses
Odoo CRM
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 The Dental System and Odoo CRM.
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
The Dental System: Not publicly documented.
Data volume sensitivity
The Dental System 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 The Dental System to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your The Dental System to Odoo CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave The Dental System
Other ways to arrive at Odoo CRM
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.