CRM migration

Migrate from The Dental System to Odoo CRM

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 logo

The Dental System

Source

Odoo CRM

Destination

Odoo CRM logo

Compatibility

100%

10 of 10

objects map 1:1 between The Dental System and Odoo CRM.

Complexity

BStandard

Timeline

48–72 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

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

The Dental System logo

The Dental System

What's pushing teams away

  • No public pricing means every evaluation requires a sales demo, slowing comparison against transparent competitors like DentiMax ($169/month) or MOGO ($250/month flat).
  • Newer product without the multi-decade install base of Dentrix or Open Dental, so the integration ecosystem with imaging vendors, payment processors, and lab partners is shallower.
  • Modern cloud-first design means it does not run offline; practices with unreliable internet (rural, multi-op high bandwidth needs) may prefer Open Dental's local-install model.
  • Limited third-party review presence on G2 and Capterra makes independent quality assessment harder than for legacy market leaders.
  • Marketing claims around AI/clinical intelligence ('thinks like a dentist') are not independently validated; capabilities depth must be confirmed during demo rather than from public materials.

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 The Dental System objects map to Odoo CRM

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

maps to

Odoo CRM

res.partner

1:1
Fully supported

Patient 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

maps to

Odoo CRM

crm.activity / calendar.event

1:1
Fully supported

Appointments 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

maps to

Odoo CRM

custom: crm.lead (dental treatment) / custom module

1:1
Fully supported

Treatment 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

maps to

Odoo CRM

custom: dental.insurance (linked to res.partner)

1:1
Fully supported

Insurance 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

maps to

Odoo CRM

crm.note / ir.attachment

1:1
Fully supported

Clinical 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

maps to

Odoo CRM

custom: dental.prescription (linked to res.partner)

1:1
Fully supported

Prescription 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

maps to

Odoo CRM

custom: dental.treatment_plan (linked to res.partner)

1:1
Fully supported

Treatment 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

maps to

Odoo CRM

res.users

1:1
Fully supported

Staff 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

maps to

Odoo CRM

res.company

1:1
Fully supported

If 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

maps to

Odoo CRM

ir.attachment

1:1
Fully supported

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

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.

The Dental System logo

The Dental System gotchas

High

No documented public API

Medium

Custom field discovery requires manual audit

Medium

Insurance carrier and payer data may require re-credentialing

Medium

Document storage may not be directly accessible for bulk export

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

  • Odoo has no native dental data model — custom fields and module planning are required before data lands

    Odoo CRM ships with a generalized res.partner and crm.lead schema. The Dental System's clinical fields (allergy flags, blood type, insurance metadata, ADA procedure codes, tooth-number references) have no native Odoo equivalent. We create custom fields on the res.partner record for patient-level clinical data and a custom treatment record model for procedure-level data. If your team uses an OCA dental module or a custom-built dental add-on in Odoo, those models must be installed and active before migration data is written — otherwise the custom field names will not resolve. We deliver a custom-field and module checklist as part of the pre-migration plan so the Odoo side is schema-ready before any data is extracted from The Dental System.

  • ADA/CPT procedure codes and diagnostic codes require custom field mapping and manual verification

    The Dental System stores procedure codes and diagnostic codes (ICD-10) natively as structured fields. Odoo CRM has no built-in clinical coding model — these codes must migrate as custom Char fields on the treatment record. ADA codes especially can be alphanumeric (D0120, D2740) and may not survive a simple text import if source formatting is inconsistent. We flag malformed or missing codes in the pre-migration validation report and map every code we can resolve automatically. Codes that fail validation are preserved in a raw_custom_codes__c fallback field for manual review in Odoo after migration — no code is silently dropped.

  • Odoo API rate limits on external API connections extend the migration window for large attachment batches

    Odoo's external XML-RPC API enforces a rate limit of approximately 1 request per second for some Odoo plans, and the batch import API has specific throttling behavior depending on your Odoo edition and hosting (Odoo Online, Odoo.sh, or self-hosted). The Dental System attachment data — patient forms, insurance card images, consent documents — often totals hundreds of megabytes. At 1 request per second for file creation and attachment linking, a 500-attachment batch alone can consume the better part of 10 minutes. We use Odoo's native bulk create via ORM where possible and throttle API calls to respect the rate limit, extending the cutover window accordingly. Self-hosted Odoo deployments can raise the limit via PostgreSQL configuration adjustments.

  • Multi-location dental groups must configure Odoo's multi-company setup before user assignments and data routing

    If The Dental System manages multiple practice locations and you intend to run those as separate Odoo company records (for reporting segregation and accounting multi-company configuration), the company setup must precede the migration. Odoo requires each company to have its own data sequences, fiscal years, and chart of accounts if the Accounting module is active. We deliver a multi-company routing plan before migration: which practices map to which Odoo company records, how patient records are distributed across companies, and how staff users are assigned to the correct Odoo company and security groups. Running the migration without this plan can result in patient records landing in the wrong company partition.

  • The Dental System recall and patient-reminder workflows do not migrate — Odoo automation rules must be rebuilt

    Recall intervals (6-month cleaning reminders, annual exam alerts) and patient-reminder workflows in The Dental System are automation constructs with no equivalent in Odoo's base CRM module. These rules are not data records — they are system-level automation logic that does not export. We provide a structured export of your active recall rules from The Dental System: trigger conditions, interval logic, and notification content. Your Odoo administrator uses this export as a rebuild reference when configuring Odoo CRM automation rules (IrCron triggers, activity templates, and mail templates). For practices with complex recall logic (conditional intervals based on treatment history), custom Odoo automation scripting or a Python module may be required.

Migration approach

Six steps for a successful The Dental System to Odoo CRM data migration

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

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

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

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

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

Context on both ends of the pair

The Dental System logo

The Dental System

Source

Strengths

  • Covers core dental practice workflows including scheduling, charting, and billing in one system
  • Patient record structure aligns with standard dental data conventions (CDT codes, insurance carriers)
  • Supports document attachments linked to patient records
  • Includes basic reporting for production and collections
  • Practice configuration is stored at the location level, making scoping straightforward

Weaknesses

  • No publicly documented API limits direct integrations and automated migration tooling
  • Limited public information on custom object schema and field-level definitions
  • Pricing and feature tiers are not publicly published, requiring direct inquiry
  • Smaller market footprint means fewer third-party migration resources and community references
  • No published rate-limit or bulk-export documentation found in research
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. 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 The Dental System and Odoo CRM.

  • 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

    The Dental System: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

Estimate your The Dental System 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 The Dental System to Odoo CRM data migrations

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

Can't find your answer?

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 consultation

Most The Dental System to Odoo CRM migrations complete in 48–72 hours of clock time for practices under 25,000 patient records. Larger practices or multi-location groups with 100,000+ records, extensive treatment history, and attachment-heavy patient files extend to 5–10 days. The Odoo schema design and custom-field setup is the longest planning step — it must complete before any source data is extracted. Odoo API rate limits on external connections also extend the cutover window when large file batches are involved.

Adjacent paths

Related migrations to explore

Ready when you are

Move from The Dental System.
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