CRM migration

Migrate from Core Practice to Odoo CRM

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 logo

Core Practice

Source

Odoo CRM

Destination

Odoo CRM logo

Compatibility

92%

11 of 12

objects map 1:1 between Core Practice and Odoo CRM.

Complexity

BStandard

Timeline

48–72 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

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

Core Practice logo

Core Practice

What's pushing teams away

  • Excessive clicks and overcomplicated workflows frustrate staff and slow down appointment booking.
  • Patients are reported lost due to poor data integrity and unreliable patient record management.
  • The platform scores poorly on ease of use, value for money, and customer service compared to competitors.
  • Low review volume (6 verified reviews) suggests limited adoption and a lack of community resources.
  • Users report the software is useless at making appointments, directly undermining core dental practice operations.

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 Core Practice objects map to Odoo CRM

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

maps to

Odoo CRM

res.partner

1:1
Fully supported

Core 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

maps to

Odoo CRM

crm.lead

many:1
Fully supported

Core 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

maps to

Odoo CRM

mail.activity

1:1
Fully supported

Core 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

maps to

Odoo CRM

crm.lead (description field)

1:1
Fully supported

Core 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

maps to

Odoo CRM

res.partner (custom field)

1:1
Fully supported

Core 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

maps to

Odoo CRM

res.partner (custom field)

1:1
Fully supported

Core 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

maps to

Odoo CRM

mail.message

1:1
Fully supported

Core 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

maps to

Odoo CRM

account.move

1:1
Fully supported

Core 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)

maps to

Odoo CRM

res.users

1:1
Fully supported

Core 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

maps to

Odoo CRM

crm.team

1:1
Fully supported

Core 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

maps to

Odoo CRM

mail.activity (custom type)

1:1
Fully supported

Core 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

maps to

Odoo CRM

ir.model.data / custom fields

1:1
Fully supported

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

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.

Core Practice logo

Core Practice gotchas

High

No publicly documented public API for direct data extraction

High

Proprietary patient archiving logic can silently drop records

Medium

Appointment booking reliability is a documented weakness

Medium

Limited review volume limits migration confidence

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 crm.lead splits leads and opportunities — Core Practice has no equivalent

    Odoo separates crm.lead into 'Lead' (raw inbound) and 'Opportunity' (qualified) states controlled by the type field. Core Practice stores all patients as a single flat record without this qualification concept. FlitStack AI routes all Core Practice patients to crm.lead type='opportunity' by default since they represent existing patients, not raw inbound leads. If your team uses a lead-qualification workflow, you must define Odoo lead stages before migration so records land in the correct pipeline state. This split affects reporting visibility — leads not converted to opportunities do not appear in sales pipeline dashboards.

  • Core Practice appointment procedure codes require Odoo activity type mapping

    Core Practice uses ADA dental procedure codes (D0120, D0150, D2750) on appointments. Odoo activity types are free-text labels with no standard dental procedure vocabulary. FlitStack AI creates a value-mapping table between Core Practice procedure codes and Odoo activity type names during migration planning. Unrecognized codes fall back to a generic 'Dental Procedure' activity type. If your team relies on procedure-code-based reporting in Core Practice, the report definitions must be rebuilt in Odoo using the mapped activity type names.

  • Insurance carrier data has no native Odoo CRM field

    Odoo res.partner has no built-in fields for insurance carrier, policy number, or group number references. Core Practice stores these data points on every patient record. FlitStack AI creates custom Char fields on res.partner named Insurance_Carrier__c and Insurance_Policy_Number__c to capture this information during migration. If your practice requires automated eligibility verification integrations, those must be configured separately in Odoo using Odoo's API connectors or third-party insurance verification applications from the Odoo Apps Store after the migration completes. Custom field data remains available for manual verification workflows.

  • Odoo Community lacks native workflow automation — Core Practice automations do not transfer

    Odoo Community does not include the automation features available in Odoo Studio (Enterprise). Core Practice appointment reminders, recall notifications, and treatment plan alerts are built-in automations that have no Odoo equivalent without Enterprise. FlitStack AI migrates data only — we export Core Practice automation definitions as a rebuild reference document. Your Odoo administrator must recreate these automations in Odoo Studio (if on Enterprise) or via server actions and ir.cron jobs (Community edition). This is the most common post-migration gap in dental practice migrations.

  • Billing records require Odoo Accounting app to map directly

    Core Practice billing records (invoices, payments, adjustments) map cleanly to Odoo account.move entries only if the Odoo Accounting app is installed. Many dental practices run Odoo CRM without Accounting. If the Accounting app is absent, FlitStack AI exports billing data as a structured reference file attached to the patient res.partner record and as a separate CSV for reconciliation. The patient financial history will be accessible but not integrated with Odoo's accounts payable or receivable dashboards until Accounting is added and the module is configured.

Migration approach

Six steps for a successful Core Practice to Odoo CRM data migration

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

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

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

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

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

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

Context on both ends of the pair

Core Practice logo

Core Practice

Source

Strengths

  • Cloud-based with no server maintenance or upfront capital costs.
  • No lock-in contracts allow month-to-month commitment.
  • Australian-hosted infrastructure for local data residency compliance.
  • All-in-one bundling of commercial, clinical, and clerical functions.
  • Real-time access from any device for multi-location practices.

Weaknesses

  • Extremely low review rating (2.7/5) indicating widespread user dissatisfaction.
  • Only 6 verified reviews exist, making independent evaluation difficult.
  • Poor ease-of-use scores (3.0/5) reflect overcomplicated workflows.
  • Weak customer service ratings (2.6/5) from the small reviewer base.
  • Minimal third-party integrations and limited API documentation published.
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 Core Practice and Odoo CRM.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Core Practice and Odoo CRM.

  • Object compatibility

    A

    All 8 core objects map 1:1 between Core Practice 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

    Core Practice: Not publicly documented.

  • Data volume sensitivity

    B

    Core Practice doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Core Practice 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 Core Practice to Odoo CRM data migrations

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

Can't find your answer?

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 consultation

Most Core Practice to Odoo CRM migrations complete in 48–72 hours for under 50,000 records. Larger practices with 500k+ records across patients, appointments, treatment plans, and billing extend to 5–7 days. The longest phase is planning the Odoo custom field schema and activity type mapping before any data moves. We deliver a fixed timeline estimate after auditing your Core Practice export volume.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Core Practice.
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