CRM migration
Field-level mapping, validation, and rollback between Nookal and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Nookal
Source
Odoo CRM
Destination
Compatibility
12 of 12
objects map 1:1 between Nookal and Odoo CRM.
Complexity
BStandard
Timeline
48–96 hours
Overview
Nookal stores patient records, appointment schedules, clinical notes, Medicare/DVA claiming data, and practitioner assignments as a unified practice-management stack oriented around the clinical workflow. Odoo CRM separates contacts (res.partner), sales opportunities (crm.lead), and accounting records (account.move) into distinct models within its modular ERP architecture, where CRM is one app among dozens and custom fields live on each model independently. We map Nookal patients directly to Odoo res.partner records with the patient flag set via a custom is_patient__c boolean, practitioner assignments map to Odoo res.users with team assignment on crm.lead records, appointment history becomes a custom activity log linked to the partner record, and Medicare claiming fields migrate as custom fields on both partner and invoice records. The migration reads Nookal's API or export files, transforms patient-treatment associations into Odoo's partner-opportunity relationship model, and loads through Odoo's xmlrpc/JSON-RPC API or direct PostgreSQL insertion for high-volume datasets. Workflows, automations, Medicare 2.0 configuration, and Xero/QuickBooks sync settings do not migrate — those require Odoo-side configuration from scratch using our rebuild-reference export. Delta-pickup captures any appointments or invoices created during the cutover window so the final Odoo state reflects Nookal's last operational moment.
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 Nookal 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.
Nookal
Patient
Odoo CRM
res.partner
1:1Nookal patient records map directly to Odoo res.partner contacts. We set a custom is_patient__c boolean field to distinguish patient partners from supplier/company partners in Odoo. Address fields (street, city, state, zip, country) map field-for-field. Medicare number and date-of-birth fields migrate as custom columns on the partner record.
Nookal
Practitioner
Odoo CRM
res.users
1:1Each Nookal practitioner becomes an Odoo res.users account so appointments can be assigned to the correct staff member. Practitioner email, name, and active status map directly. If the Nookal practitioner is also a patient, we create both a user record and a partner record linked by partner_id.
Nookal
Appointment
Odoo CRM
crm.lead (as activity log)
1:1Nookal appointments do not map to Odoo calendar events (crm.event) because Odoo's native calendar is tied to project/resource scheduling rather than patient appointment history. Instead, we create crm.lead records for each appointment with the appointment date as date_deadline, practitioner as user_id, patient as partner_id, and service type stored in a custom appointment_type__c field. The lead_type field is set to 'opportunity' to indicate a booked appointment rather than a sales prospect.
Nookal
Invoice
Odoo CRM
account.move
1:1Nookal invoices migrate to Odoo account.move records with move_type='out_invoice'. Invoice number maps to name, total amount to amount_total, and status (draft/sent/paid/cancelled) maps to state. Line items (service descriptions, Medicare item numbers, quantities, unit prices) migrate to account.move.line records with the appropriate account_id for revenue recognition.
Nookal
Medicare Claim
Odoo CRM
account.move (custom fields)
1:1Nookal Medicare and DVA claiming data has no native equivalent in Odoo. We create custom fields on the account.move model to capture the full claim lifecycle: claim_status__c stores the submission state using a picklist of pending, submitted, approved, or rejected values. Provider number, Medicare item number, and bulk-bill indicator fields are added as provider_number__c, item_number__c, and bulk_bill__c respectively. The patient res.partner record receives separate custom fields for medicare_number__c and dva_number__c sourced from Nookal patient records.
Nookal
Insurance Provider
Odoo CRM
res.partner (parent or related)
1:1Nookal insurance providers map to Odoo res.partner records with partner.role set to 'insurance_company' via a custom partner_type__c field. If the insurance provider is also a referring practitioner, we link it to the patient as a child partner via partner_id. Insurance policy numbers and provider IDs migrate as custom fields on the patient partner record.
Nookal
Referral Source
Odoo CRM
crm.lead.source_id
1:1Nookal records referral sources such as advertising channels, GP referrals, and word-of-mouth recommendations using a label stored on the patient or appointment record. These labels map to Odoo's crm.lead.source_id lookup field on the opportunity. We create corresponding crm.tracking.mixin.source records in Odoo when the referral label does not already exist in the system, using the exact Nookal referral label as the source name for consistent reporting across both platforms.
Nookal
Treatment / Clinical Note
Odoo CRM
mail.message / custom.note model
1:1Nookal clinical notes attached to patient records have no direct Odoo equivalent. We create a custom clinical_note__c field (html type) on res.partner to store the most recent clinical note, and attach historical note content as mail.message records linked to the partner for full audit history. Treatment plans and appointment summaries migrate as structured text in these fields.
Nookal
Location / Practice
Odoo CRM
res.company / stock.warehouse
1:1Nookal practices operating across multiple locations each correspond to a separate Odoo res.company record, enabling independent fiscal year configuration, chart of accounts setup, journal assignments, and practitioner team assignments per site. For locations requiring inventory capabilities, we generate matching stock.warehouse records linked to each company entity, providing complete operational separation while maintaining cross-company reporting options within Odoo's multi-company framework.
Nookal
Custom Patient Fields
Odoo CRM
res.partner custom fields
1:1Nookal custom fields on patients (e.g., emergency contact, next of kin, NDIS plan number) map to Odoo custom fields on res.partner created during the Odoo schema setup phase. Field types are matched (text, date, boolean, selection) and validation rules are preserved as Odoo field constraints where supported.
Nookal
SMS / Communication Log
Odoo CRM
mail.message
1:1Nookal SMS history and patient communications map to Odoo mail.message records linked to the res.partner. Message direction (inbound/outbound), timestamp, and content are preserved. Odoo's mail.channel integration can recreate a patient communication thread if the practice uses Odoo's Live Chat or Discuss module.
Nookal
Xero / QuickBooks Sync Settings
Odoo CRM
No equivalent
1:1Nookal's Xero and QuickBooks sync configuration (chart of accounts mapping, tax settings, invoice numbering conventions) has no Odoo equivalent and must be rebuilt in Odoo's accounting app configuration. We export the source mapping as a reference document for the Odoo accountant.
| Nookal | Odoo CRM | Compatibility | |
|---|---|---|---|
| Patient | res.partner1:1 | Fully supported | |
| Practitioner | res.users1:1 | Fully supported | |
| Appointment | crm.lead (as activity log)1:1 | Fully supported | |
| Invoice | account.move1:1 | Fully supported | |
| Medicare Claim | account.move (custom fields)1:1 | Fully supported | |
| Insurance Provider | res.partner (parent or related)1:1 | Fully supported | |
| Referral Source | crm.lead.source_id1:1 | Fully supported | |
| Treatment / Clinical Note | mail.message / custom.note model1:1 | Fully supported | |
| Location / Practice | res.company / stock.warehouse1:1 | Fully supported | |
| Custom Patient Fields | res.partner custom fields1:1 | Fully supported | |
| SMS / Communication Log | mail.message1:1 | Fully supported | |
| Xero / QuickBooks Sync Settings | No equivalent1: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.
Nookal gotchas
Medicare 2.0 migration deadline is hard-gated
No public API forces reliance on built-in exports
Custom clinical note templates are account-specific
Medicare claiming groups tied to Provider Numbers restrict bulk migrations
Accounting sync does not export raw ledger data
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
Inventory Nookal data objects and map to Odoo schema
We connect to Nookal via its API (or export files if API access is restricted) and enumerate all patients, practitioners, appointments, invoices, insurance providers, referral sources, and SMS logs. We produce a data inventory report listing record counts per object, identify any custom Nookal fields not in the standard schema, and flag missing or orphaned records (e.g., appointments with deleted patients). This report drives the Odoo schema setup plan that we deliver before data loading begins.
Design Odoo custom fields and company/location structure
Based on the data inventory, we create the Odoo custom field plan: custom fields on res.partner (is_patient__c, medicare_number__c, dva_number__c, etc.), custom fields on account.move (claim_status__c, provider_number__c, bulk_bill__c, item_number__c), and custom fields on crm.lead (appointment_type__c, planned_hours__c). For multi-location practices, we also deliver the location-to-company mapping plan. Your Odoo admin applies the custom field creation and company setup before migration data is loaded; we verify the schema via a test record insertion.
Run sample migration with field-level diff
A representative slice of approximately 100–500 records — covering at least 10 patients, 50 appointments, and 20 invoices spanning different practitioners and locations — migrates first. We generate a field-level diff report comparing each Nookal field value against the corresponding Odoo field value so you can verify Medicare field mapping, practitioner assignment, appointment status translation, and invoice state mapping before the full run commits. Any mapping adjustments are made before the production migration begins.
Execute full migration with delta-pickup window
All Nookal records migrate to Odoo using the validated mapping. Patients load first as res.partner records (resolving duplicate emails via a merge preference rule), then practitioners as res.users, then appointments as crm.lead opportunities, then invoices as account.move records with line items. A delta-pickup window of 24–48 hours after the full migration begins captures any appointments or invoices created in Nookal during the cutover so Odoo reflects the final operational state at go-live. An audit log records every record inserted, updated, or skipped.
Deliver reconciliation report and rebuild-reference export
We generate a reconciliation report listing all Nookal record IDs, their corresponding Odoo record IDs, and any records that were skipped, merged, or flagged. The rebuild-reference export delivers the Nookal workflow definitions, Xero/QuickBooks sync settings, and Medicare 2.0 configuration as structured CSV and JSON files so your Odoo administrator can rebuild automations and integrations from a documented reference rather than reconstructing them from memory. One-click rollback is available if reconciliation reveals unexpected discrepancies.
Platform deep dives
Nookal
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 Nookal 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
Nookal: Not publicly documented.
Data volume sensitivity
Nookal 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 Nookal to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Nookal 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 Nookal
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.