CRM migration
Field-level mapping, validation, and rollback between Basic Online CRM and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Basic Online CRM
Source
Odoo CRM
Destination
Compatibility
10 of 12
objects map 1:1 between Basic Online CRM and Odoo CRM.
Complexity
BStandard
Timeline
2-4 weeks
Overview
Moving from Basic Online CRM to Odoo CRM is a structural upgrade for teams that have outgrown a staging CRM and need a full business suite. Basic Online CRM exports data as flat CSV with Deals referencing Contacts by internal numeric ID rather than name or email, which requires a cross-reference pass before Odoo import. Odoo uses the crm.lead model (which doubles as both lead and opportunity) and res.partner for contacts, with many2one relationships that must resolve to existing record IDs at insert time. We split the migration into contact-first and company-first import phases, create all custom fields in Odoo Studio before data arrives, and flag orphaned Deals (those referencing deleted Contacts) for customer resolution before cutover. Workflows, automation rules, and any configured email BCC rules do not migrate; we deliver a written inventory of these for the customer's admin to rebuild in Odoo Studio.
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 Basic Online CRM 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.
Basic Online CRM
Contact
Odoo CRM
res.partner
1:1Basic Online CRM Contact records map to Odoo res.partner. The source name, email, phone, and address fields map directly. Basic Online CRM custom fields migrate as char, selection, or float fields on res.partner, created in Odoo Studio before import. Partners flagged as company contacts in Basic Online CRM set the is_company checkbox on the Odoo partner record. Email address uniqueness is the dedupe key during import; duplicate emails trigger a skip with a flag for manual review.
Basic Online CRM
Company
Odoo CRM
res.partner (company type)
1:1Basic Online CRM Company records map to Odoo res.partner with is_company = True. The source company name maps to the partner name field, domain/website to website, and any company-level custom fields to partner fields. If a Basic Online CRM Company shares a name with an existing Odoo partner record, we flag it as a potential duplicate for customer resolution before committing the import.
Basic Online CRM
Deal
Odoo CRM
crm.lead
1:1Basic Online CRM Deal records map to Odoo crm.lead in the Opportunity stage (not the Lead stage). The Deal name becomes crm.lead name, amount becomes planned_revenue, and pipeline stage maps to stage_id via a stage-name lookup we run against the Odoo pipeline configuration before import. Closed-won Deals set the probability to 100 and stage to the Odoo closed-won stage; closed-lost sets probability to 0.
Basic Online CRM
Deal-Contact association
Odoo CRM
crm.lead.partner_id (many2one)
1:1Basic Online CRM exports Deals with Contact linked by internal numeric ID, not by email or name. We run a dual extraction: Contacts first (capturing id and email/name), then Deals (capturing id and contact_id). During the transform phase, we cross-reference every contact_id against the extracted contact list, resolving to partner_id. Deals where contact_id references a deleted or absent Contact are flagged as orphaned Deals and held in a reconciliation queue; we do not create them without a resolved partner.
Basic Online CRM
Deal-Company association
Odoo CRM
crm.lead.partner_id (many2one)
1:1If Basic Online CRM Deal records also reference a Company by internal ID, we resolve both associations during the same transform pass. Odoo crm.lead allows only one partner_id (Contact) and one partner_assigned_id (salesperson), so Company is informational and stored in a custom char field if it does not align with the Contact's company partner.
Basic Online CRM
Note
Odoo CRM
crm.lead.description (text) or mail.message
1:1Basic Online CRM Notes are free-text and untyped with no explicit timestamp. We map them to the description field on the related crm.lead. If the Note has an explicit creation date, we store it as a custom date field and note it in the migration report. If the customer requires threaded note history, we optionally create mail.message records with note subtype, linked to the crm.lead via res_id and model fields.
Basic Online CRM
Custom Field (string-stored)
Odoo CRM
ir.model.fields (via Studio)
lossyBasic Online CRM custom fields are stored as untyped strings on export. We ask customers to confirm intended data types (date, number, dropdown, text) during scoping. We pre-create the fields in Odoo Studio with the confirmed types before any data import. Date fields in particular may export with inconsistent formatting (Jan 15 2024 vs 15/01/2024); we apply a standardisation transform pass before writing.
Basic Online CRM
Owner/User
Odoo CRM
res.users
1:1Basic Online CRM does not surface Owner assignment in its exports. We ask customers upfront which team member should own migrated records in Odoo. If multiple Basic Online CRM users exist, we extract unique user references from Deal and Note records and match them to Odoo res.users by email during the transform phase. Unmatched users are held in a reconciliation queue for the customer's Odoo admin to provision before the write-back phase continues.
Basic Online CRM
Activity/Task
Odoo CRM
mail.activity
1:1If the Basic Online CRM instance contains task records (title, status, no assignee), we migrate them to Odoo mail.activity linked to the related crm.lead. activity_type_id maps to Odoo's standard activity types (Email, Call, Meeting, To Do). Odoo requires an activity_type_id and a res_model reference; we set res_model to crm.lead and resolve the res_id from the parent Deal mapping.
Basic Online CRM
Pipeline configuration
Odoo CRM
crm.stage
lossyBasic Online CRM pipeline stages (up to 5 on Free, more on paid tiers) map to Odoo crm.stage records within the default CRM team. We query the existing stage configuration in the destination Odoo database, map each source stage name to the nearest matching Odoo stage, and create any missing stages via the Odoo interface or XML-RPC before Deal import begins.
Basic Online CRM
Tags/Labels
Odoo CRM
crm.tag
1:1Basic Online CRM tag values stored on Contacts, Companies, or Deals migrate to Odoo crm.tag records. Tags are created on-demand during the transform phase (deduped by name), then linked via crm.lead.tag_ids many2many field. If Basic Online CRM tags are free-text without a dedicated tag field, we create a custom many2many field on crm.lead for them.
Basic Online CRM
Company-Contact hierarchy
Odoo CRM
res.partner.parent_id
1:1If Basic Online CRM stores a Contact's parent Company as a linked Company record (rather than a field on the Contact), we resolve that relationship during the partner import pass and set the child Contact's parent_id to the company partner ID. Odoo enforces that parent_id points to an is_company partner; we validate this constraint before writing and flag any violations.
| Basic Online CRM | Odoo CRM | Compatibility | |
|---|---|---|---|
| Contact | res.partner1:1 | Fully supported | |
| Company | res.partner (company type)1:1 | Fully supported | |
| Deal | crm.lead1:1 | Fully supported | |
| Deal-Contact association | crm.lead.partner_id (many2one)1:1 | Fully supported | |
| Deal-Company association | crm.lead.partner_id (many2one)1:1 | Fully supported | |
| Note | crm.lead.description (text) or mail.message1:1 | Fully supported | |
| Custom Field (string-stored) | ir.model.fields (via Studio)lossy | Fully supported | |
| Owner/User | res.users1:1 | Fully supported | |
| Activity/Task | mail.activity1:1 | Fully supported | |
| Pipeline configuration | crm.stagelossy | Fully supported | |
| Tags/Labels | crm.tag1:1 | Fully supported | |
| Company-Contact hierarchy | res.partner.parent_id1: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.
Basic Online CRM gotchas
CSV export silently truncates large contact lists
Deal-Contact associations are stored by internal ID only
Custom field data types are not preserved on export
No native attachment storage means files are not migrated
User/owner structure is not explicit in exported 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
Discovery and scoping
We audit the Basic Online CRM instance: record counts (Contacts, Companies, Deals, Notes, Tasks), custom field definitions, pipeline stage count, and any multi-file export requirement triggered by the 5,000-row cap. We also identify any orphaned Deals (those referencing deleted Contacts) from the CSV headers. The discovery output is a written scope document with a record-count table, a custom field type confirmation request sent to the customer, and a flag for any Deals without resolvable Contact associations.
CSV extraction in batches
For instances with more than 5,000 contacts, we extract in multiple CSV files: a base export of records 1-5,000, then a second export for 5,001 onward. We run a reconciliation check comparing total extracted rows against Basic Online CRM's reported record count. If the counts match, we merge the files in the staging environment. If they diverge, we request a manual re-export or flag the discrepancy for customer investigation.
Contact-to-partner resolution and orphan handling
We run the dual-extract resolution pass: Contacts export first (capturing id, email, name), then Deals export (capturing id and contact_id). The transform script cross-references every contact_id against the contact list and replaces the numeric ID with a resolved partner name or email. Deals where contact_id has no match enter the orphan queue. We deliver the orphan list to the customer and do not create those Deals until the customer either creates the missing Contact or assigns the Deal to an existing Contact in the destination.
Odoo Studio schema pre-creation
Before any data write-back, we create all confirmed custom fields in Odoo Studio on the crm.lead and res.partner models using the data types confirmed by the customer during scoping. We set field labels to match the source Basic Online CRM labels for admin recognition. We validate that stage names in the destination Odoo pipeline match the source Deal stages or create the missing stages in Odoo before the Deal import phase begins.
Staged import into Odoo
We import in dependency order: res.partner (Companies first, then Contacts with parent_id resolved), crm.lead (Deals with resolved partner_id, stage_id, and planned_revenue), mail.activity (Tasks linked to crm.lead), and crm.tag (tags created on-demand then linked to crm.lead via tag_ids). Each phase emits a row-count reconciliation report showing records attempted, records written, and records skipped with reason codes. The customer reviews the reconciliation report before the next phase begins.
Cutover, delta migration, and automation inventory handoff
We freeze Basic Online CRM writes during the cutover window, run a final delta pass for any records modified during the migration, then enable Odoo as the system of record. We deliver the written automation inventory document listing every Basic Online CRM workflow and automation rule that requires rebuild in Odoo Studio, with a recommended equivalent action in Odoo for each. We support a one-week post-cutover window for reconciliation issues. We do not rebuild automations inside the migration scope; that is a separate engagement or internal admin task.
Platform deep dives
Basic Online CRM
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 3 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 Basic Online CRM and Odoo CRM.
Object compatibility
3 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
Basic Online CRM: Not publicly documented.
Data volume sensitivity
Basic Online CRM 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 Basic Online CRM to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Basic Online CRM 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 Basic Online CRM
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.