CRM migration
Field-level mapping, validation, and rollback between Dental-Exec and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Dental-Exec
Source
Odoo CRM
Destination
Compatibility
10 of 10
objects map 1:1 between Dental-Exec and Odoo CRM.
Complexity
BStandard
Timeline
48-72 hours
Overview
Dental-Exec stores dental practice data as patient-centric records with treatment plans, appointment schedules, and clinical notes. Odoo CRM models equivalent information across crm.lead (for treatment inquiries and case progress), res.partner (for patient and provider contacts), and custom fields for clinical metadata. The migration maps Dental-Exec patients to res.partner records with primary contact details, while open treatment cases route to crm.lead with pipeline stage mapping based on case status. We preserve appointment timestamps as Odoo mail.activity records, preserve treatment plan metadata in custom_char fields on res.partner, and surface custom dental properties (insurance carrier, recall frequency, treatment history) as custom fields that require Odoo developer-mode setup before import. Odoo's XML-RPC API handles the import; FlitStack sequences the load so foreign-key relationships resolve in the correct order. Automations, email templates, and reporting configurations do not migrate and require manual rebuild in Odoo's workflow builder. Post-migration validation ensures record counts match and data integrity checks confirm successful transformation of all dental-specific metadata across the new Odoo environment.
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 Dental-Exec 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.
Dental-Exec
Patient Record
Odoo CRM
res.partner
1:1Dental-Exec patient records map directly to Odoo res.partner. The primary contact fields (name, email, phone, address) transfer as-is. Custom patient properties (insurance carrier, recall interval) require pre-created custom fields in Odoo before import. The mapping preserves original create dates and owner assignments where available in the source system for audit continuity.
Dental-Exec
Treatment Case
Odoo CRM
crm.lead
1:1Open treatment cases in Dental-Exec become Odoo crm.lead records. Case status maps to crm.stage values per sales team. Completed cases can route to res.partner as historical notes or remain as closed crm.lead records based on your reporting preference. This flexible routing ensures treatment history is accessible in the format most useful for your practice management workflow.
Dental-Exec
Provider/Team Member
Odoo CRM
res.users
1:1Dental-Exec staff members map to Odoo res.users by email match. Role assignments (doctor, hygienist, admin) do not transfer automatically — these require Odoo security group configuration post-migration. FlitStack flags unmatched users for manual Odoo user creation before the cutover to prevent orphaned records from blocking the migration window.
Dental-Exec
Appointment
Odoo CRM
mail.activity
1:1Dental-Exec appointment records become Odoo mail.activity entries linked to res.partner. Activity type (checkup, procedure, consultation) maps to mail.activity.activity_type_id values. Original appointment timestamps and assigned provider are preserved in activity notes, maintaining complete scheduling history and provider accountability within the migrated records.
Dental-Exec
Insurance Carrier
Odoo CRM
res.partner (company)
1:1Dental-Exec insurance carrier references map to res.partner records with contact_type='invoice_address' for billing entities. Carrier name, address, and contact details transfer as company-type partners, enabling linking patients to their insurance providers while maintaining separate carrier records for multi-carrier scenarios and historical carrier information.
Dental-Exec
Clinical Note / Treatment Note
Odoo CRM
mail.message
1:1Dental-Exec clinical notes attach to res.partner records as mail.message entries with message_type='comment'. Original author and timestamp are preserved. Attachments (images, X-rays) migrate as ir.attachment records linked to the parent partner, maintaining complete clinical history for treatment continuity and regulatory compliance purposes.
Dental-Exec
Billing Record
Odoo CRM
account.move (draft)
1:1Dental-Exec billing and payment history does not map to Odoo invoicing directly — these records are preserved as custom fields on res.partner (Last_Balance__c, Total_Charges__c) for reference. Full accounting migration requires Odoo accounting module configuration separately, which is handled as a follow-on engagement to ensure complete financial continuity.
Dental-Exec
Custom Patient Property
Odoo CRM
ir.model.fields (custom)
1:1Dental-Exec custom patient properties (recall frequency, clinical flags, insurance group) require Odoo custom field creation via Settings > Technical > Database Structure > Models before import. FlitStack generates the field creation script as part of the migration plan, ensuring all custom data transfers correctly into properly configured destination fields.
Dental-Exec
Referral Source
Odoo CRM
crm.lead (source_id)
1:1Dental-Exec referral source metadata maps to Odoo crm.lead.source_id — the field links to crm.lost_reason or utm.source records depending on Odoo version. Source names transfer as-is; Odoo admin may need to create source records first to enable proper attribution tracking and marketing analytics post-migration.
Dental-Exec
Document / Consent Form
Odoo CRM
ir.attachment
1:1Dental-Exec file attachments (consent forms, insurance cards, treatment plans) migrate as ir.attachment records linked to the corresponding res.partner. File size and format are preserved during migration. Odoo attachment storage limits apply (typically 25MB per file), and files exceeding this threshold are flagged for manual handling as part of the migration plan.
| Dental-Exec | Odoo CRM | Compatibility | |
|---|---|---|---|
| Patient Record | res.partner1:1 | Fully supported | |
| Treatment Case | crm.lead1:1 | Fully supported | |
| Provider/Team Member | res.users1:1 | Fully supported | |
| Appointment | mail.activity1:1 | Fully supported | |
| Insurance Carrier | res.partner (company)1:1 | Fully supported | |
| Clinical Note / Treatment Note | mail.message1:1 | Fully supported | |
| Billing Record | account.move (draft)1:1 | Fully supported | |
| Custom Patient Property | ir.model.fields (custom)1:1 | Fully supported | |
| Referral Source | crm.lead (source_id)1:1 | Fully supported | |
| Document / Consent Form | 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.
Dental-Exec gotchas
No public API for automated exports
Recall and hygiene data embedded in task records
Drug interaction flags are binary, not structured
Thin vendor footprint raises continuity risk
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
Audit Dental-Exec data volume and custom property inventory
FlitStack AI connects to Dental-Exec via scoped API read access to enumerate all patient records, treatment cases, appointments, and custom patient properties. We generate a data inventory report listing record counts per object, custom field definitions, attachment file sizes, and user accounts. This audit identifies oversized files, unmapped custom properties, and provider accounts that need Odoo user creation before migration begins.
Configure Odoo custom fields and crm.stage values
Based on the data audit, FlitStack delivers a custom field creation script and crm.stage configuration guide for your Odoo admin to execute. This includes creating Char, Integer, Date, and Text fields on res.partner for dental-specific metadata, and setting up crm.stage values that map to Dental-Exec case statuses. The Odoo admin must complete this step before FlitStack can validate the field mapping during the test migration.
Resolve provider and staff accounts by email match
Dental-Exec staff members are matched to Odoo res.users by email address. FlitStack generates an unmatched-users report listing providers without existing Odoo accounts. Your team creates the missing Odoo users before the test migration runs. Records assigned to unmatched users default to a designated fallback owner during migration, with ownership re-assigned post-go-live. This prevents orphaned records and maintains proper audit trails throughout the migration process.
Run sample migration with field-level diff
A representative slice (typically 200-500 records spanning patients, treatment cases, appointments, and attachments) migrates to a staging Odoo environment. FlitStack generates a field-level diff comparing source values to destination field contents, highlighting any transformation issues in case status mapping, date formatting, or custom field population. You approve the diff before the full migration proceeds. This validation step catches mapping errors early, reducing risk before committing the complete dataset.
Execute full migration with delta-pickup and rollback readiness
The full dataset loads into Odoo CRM via XML-RPC API in sequenced batches (partners first, then leads, then activities, then attachments). A delta-pickup window of 24-48 hours captures any Dental-Exec records modified during the cutover window. FlitStack maintains an audit log of all operations and one-click rollback capability if reconciliation reveals unexpected data gaps. Post-migration, the audit report confirms record counts and highlights any attachment failures requiring manual re-upload.
Platform deep dives
Dental-Exec
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 Dental-Exec 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
Dental-Exec: Not publicly documented.
Data volume sensitivity
Dental-Exec 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 Dental-Exec to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Dental-Exec 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 Dental-Exec
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.
