CRM migration
Field-level mapping, validation, and rollback between Core Practice and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Core Practice
Source
Odoo CRM
Destination
Compatibility
11 of 12
objects map 1:1 between Core Practice and Odoo CRM.
Complexity
BStandard
Timeline
48–72 hours
Overview
Core Practice stores dental practices as a combination of patient records, appointment schedules, treatment histories, and billing invoices. The platform groups patient demographics, insurance carrier details, clinical notes, and appointment outcomes into tightly coupled records. Odoo CRM separates these concerns: res.partner holds contact and address data, crm.lead represents leads and opportunities with stage-based pipeline tracking, and related models handle team assignments and scheduled activities. FlitStack AI maps Core Practice patients directly to Odoo res.partner records, treatment plans to custom opportunity descriptions, and appointment histories to crm.lead activity logs with original timestamps. Insurance carrier references migrate as custom fields on res.partner. Workflows, automations, and template configurations do not transfer — we export Core Practice workflow definitions as a rebuild reference for Odoo's Studio automation builder. We access Core Practice data via its export API and load into Odoo through XML-RPC, sequencing the migration so foreign-key relationships resolve correctly: partners first, then leads with partner_id lookups, then activities linked to their parent records.
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 Core Practice 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.
Core Practice
Patient
Odoo CRM
res.partner
1:1Core Practice patient records map directly to Odoo res.partner. Name fields split into partner name components; contact fields map to partner address and communication fields including email and phone. Insurance carrier data becomes custom fields on the partner record. Original patient ID is preserved in Source_System_ID__c for traceability during migration and future delta-sync operations.
Core Practice
Patient
Odoo CRM
crm.lead
many:1Core Practice treatment plans and recall schedules merge into Odoo crm.lead records representing patient opportunities. Each planned treatment becomes a lead description entry with original provider assignment preserved as user_id lookup. Recall intervals and treatment stages translate to custom fields on the lead record for ongoing patient engagement tracking.
Core Practice
Appointment
Odoo CRM
mail.activity
1:1Core Practice appointments map to Odoo mail.activity records linked to the corresponding crm.lead or res.partner. Activity type, scheduled datetime, and assigned provider (user_id) are preserved through the migration; procedure codes map to activity type names. Original appointment outcomes and status values convert to mail.activity state values.
Core Practice
Treatment Plan
Odoo CRM
crm.lead (description field)
1:1Core Practice treatment plan line items including procedure code, tooth number, and estimated cost are concatenated into the Odoo crm.lead description field as structured text entries. Planned treatment dates become activity scheduled_dates on the linked lead record for follow-up tracking and clinical workflow management.
Core Practice
Insurance Carrier
Odoo CRM
res.partner (custom field)
1:1Core Practice insurance carrier references have no direct Odoo equivalent in the standard res.partner model. We create an Insurance_Carrier__c custom Char field on res.partner and migrate the carrier name and policy reference as string values for insurance verification workflows and billing integrations.
Core Practice
Referring Dentist
Odoo CRM
res.partner (custom field)
1:1Core Practice referral source exists as a contact within the patient record structure. We migrate referring dentist names as a custom Referring_Dentist__c Char field on res.partner. Full referral contact records can be created as separate res.partner entries if your practice requires complete referral network tracking and communication history.
Core Practice
Clinical Notes
Odoo CRM
mail.message
1:1Core Practice clinical notes map to Odoo mail.message records attached to the corresponding crm.lead for clinical context and audit trail purposes. Original create date and author user are preserved as mail.message date and author_id. Note body is stored as mail.message body text for practitioner review.
Core Practice
Billing Record
Odoo CRM
account.move
1:1Core Practice billing records map to Odoo account.move entries if the Odoo Accounting app is installed and configured. Without Accounting installed, billing data exports as a structured reference file and is preserved as custom fields on the linked res.partner for future reconciliation when the Accounting module is activated.
Core Practice
Provider (Dentist)
Odoo CRM
res.users
1:1Core Practice provider and dentist records map to Odoo res.users for activity assignment and team membership. Email addresses are matched for user resolution across systems; unmatched providers are flagged in a pre-migration report for team assignment before data loads commence.
Core Practice
Practice Location
Odoo CRM
crm.team
1:1Core Practice location or office identifier maps to Odoo crm.team records representing each physical practice location. Team members including dentists, hygienists, and administrative staff are assigned as team member_ids derived from res.users for multi-location pipeline management and reporting.
Core Practice
Recall Schedule
Odoo CRM
mail.activity (custom type)
1:1Core Practice recall intervals such as 6-month cleaning have no Odoo native equivalent in the standard CRM model. We create a custom Recall_Schedule__c field on crm.lead and schedule follow-up mail.activity records with the calculated recall date for patient retention and preventive care follow-up workflows.
Core Practice
Custom Forms / Intake Data
Odoo CRM
ir.model.data / custom fields
1:1Any custom intake fields in Core Practice including medical history, consent forms, and special notes require Odoo custom fields created via Settings > Technical > Models. We document every custom field definition including field type, validation rules, and display labels. A setup plan is created before data loads to ensure the destination schema accommodates all patient intake information.
| Core Practice | Odoo CRM | Compatibility | |
|---|---|---|---|
| Patient | res.partner1:1 | Fully supported | |
| Patient | crm.leadmany:1 | Fully supported | |
| Appointment | mail.activity1:1 | Fully supported | |
| Treatment Plan | crm.lead (description field)1:1 | Fully supported | |
| Insurance Carrier | res.partner (custom field)1:1 | Fully supported | |
| Referring Dentist | res.partner (custom field)1:1 | Fully supported | |
| Clinical Notes | mail.message1:1 | Fully supported | |
| Billing Record | account.move1:1 | Fully supported | |
| Provider (Dentist) | res.users1:1 | Fully supported | |
| Practice Location | crm.team1:1 | Fully supported | |
| Recall Schedule | mail.activity (custom type)1:1 | Fully supported | |
| Custom Forms / Intake Data | ir.model.data / custom fields1: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.
Core Practice gotchas
No publicly documented public API for direct data extraction
Proprietary patient archiving logic can silently drop records
Appointment booking reliability is a documented weakness
Limited review volume limits migration confidence
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 Core Practice export and design Odoo custom fields
Before any data moves, we export a full Core Practice schema snapshot and identify every custom field, carrier reference, recall interval, and procedure code in use. We then create the Odoo custom fields (Insurance_Carrier__c, Recall_Interval__c, x_specialty__c, etc.) via the Odoo technical interface so the destination schema is ready before record imports begin. Your Odoo admin reviews the custom field list and approves the schema plan before we proceed.
Resolve providers to Odoo res.users by email
Core Practice provider and staff records are matched to Odoo res.users by email address. Unmatched providers are flagged in a pre-migration report — your team either creates the corresponding Odoo user accounts first or assigns a fallback provider for their records. No lead or activity lands without a valid Odoo user_id owner. This step also creates the crm.team records representing each practice location.
Migrate res.partner records first with foreign-key setup
Odoo enforces referential integrity requiring partners to exist before crm.lead records can reference them via partner_id foreign key. We sequence the migration so res.partner records representing patients load first, capturing the Core Practice patient ID in Source_System_ID__c for traceability. Insurance carrier and referral dentist custom fields populate during this initial phase. After all partners are committed to the database, the migration proceeds to crm.lead record creation.
Migrate crm.lead and mail.activity records with parent lookups
Core Practice treatment plans and recall schedules transform into crm.lead opportunities linked to their parent res.partner via partner_id foreign key. Appointment records map to mail.activity entries with user_id resolved to the assigned provider and activity_type_id set according to procedure code mapping tables. Clinical notes load as mail.message records attached to the parent lead record. We validate that every activity has a valid parent_id before committing the records to the database.
Run sample migration with field-level diff
A representative slice of 100–300 Core Practice records migrates first — covering at least one patient per provider, one appointment per procedure type, and one treatment plan with billing. We generate a field-level diff report showing source values against destination field contents so you can verify insurance carrier mapping, procedure code mapping, and recall interval handling before the full migration commits.
Execute full migration with delta-pickup window
The complete Core Practice dataset loads into Odoo with all object and field mappings applied from the planning phase. A 24–48 hour delta-pickup window runs concurrently to capture any records created or modified in Core Practice during the cutover period. An audit log records every database operation for compliance and debugging purposes. One-click rollback reverts all migrated records if post-migration reconciliation reveals data integrity issues before the Odoo system goes live for your team.
Platform deep dives
Core Practice
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. All 8 core objects map 1:1 between Core Practice and Odoo CRM.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Core Practice and Odoo CRM.
Object compatibility
All 8 core objects map 1:1 between Core Practice and Odoo CRM.
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
Core Practice: Not publicly documented.
Data volume sensitivity
Core Practice 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 Core Practice to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Core Practice 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 Core Practice
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.