CRM migration
Field-level mapping, validation, and rollback between Close and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Close
Source
Odoo CRM
Destination
Compatibility
9 of 13
objects map 1:1 between Close and Odoo CRM.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Close to Odoo CRM is a migration from a sales-first, communication-centric CRM into a unified ERP ecosystem where CRM is one module among many. Close uses three distinct record types — Leads, Contacts, and Opportunities — each with its own activity stream. Odoo CRM collapses the first two into a single Lead object that converts to a Contact and Opportunity at the point of sale qualification, with the conversion action creating the Contact and linking it to the Opportunity in one step. We map each Close record type against this design, preserve the full activity history through JSON export (CSV export drops activity data silently in Close), and configure Odoo pipeline stages with probability weights matching the source. Close Workflows — only available on Growth and Scale plans — do not migrate to Odoo server actions; we deliver a written inventory of every active Workflow with its trigger logic and recommended Odoo automated-activity equivalent. Teams moving to Odoo for its ERP breadth should note that inventory, accounting, and project modules expand the destination scope and require separate Odoo implementation work outside the CRM migration.
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 Close 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.
Close
Lead
Odoo CRM
Lead
1:1Close Leads map directly to Odoo CRM crm.lead records. Standard fields — name, email, phone, company name, status, owner — migrate 1:1. Close lead status labels (e.g. Potential, Contacted) map to Odoo stage names that we configure to match the source labels. The Odoo lead ID is generated at insert and is used as a parent reference for activity logs. Note that Odoo has no separate Contact object until a Lead is converted; contacts remain as partner_id fields on the Lead until the convert action is taken.
Close
Contact
Odoo CRM
Contact (created on Lead convert)
1:manyClose Contacts attached to a Company map to Odoo CRM Contacts (res.partner records with customer_rank set). Because Odoo does not maintain separate Contact and Lead records simultaneously, we stage Contacts as Lead records with a flag (e.g., is_contact__c) and convert them at migration time or post-migration using Odoo's lead-convert action, which creates the linked Contact and Opportunity. This approach preserves the relationship between Contact and Company that Close maintains explicitly.
Close
Opportunity
Odoo CRM
Opportunity
1:1Close Opportunities map to Odoo CRM Opportunities (crm.lead records with type='opportunity'). The Close opportunity value, expected close date, stage, and probability migrate to Odoo expected_revenue, date_deadline, stage_id, and probability fields. Each Close Pipeline becomes an Odoo CRM Pipeline (crm.team), and pipeline stages map to Odoo stage records with probability weights preserved from the source.
Close
Pipeline
Odoo CRM
Pipeline (crm.team)
1:1Close Pipelines map to Odoo CRM Teams. We create the Odoo team record first, then map each pipeline stage as an Odoo stage within that team's pipeline. Stage names and display order are preserved. Close pipeline custom columns carrying Opportunity-level data migrate as Opportunity custom fields in Odoo.
Close
Pipeline Stage
Odoo CRM
Stage
lossyClose pipeline stages map to Odoo CRM stage records. Each stage carries a name, sequence order, and probability percentage. We create these in Odoo during schema setup using the Odoo RPC API, setting the probability to match the Close stage probability value. Stage loss and won flags map from Close pipeline stage behaviour.
Close
Activities (Call, Email, SMS, Task)
Odoo CRM
Log activities on Lead/Opportunity
1:1Close activity records (calls, emails, SMS, tasks) migrate as Odoo mail.message and mail.tracking.value records attached to the corresponding Odoo crm.lead. Odoo stores these as Log a Note or Log an Activity on the lead. We map the Close activity type to Odoo's mail.message subtype (comment, email, call, sms) and set create_date to the original Close timestamp to preserve timeline ordering. This requires JSON export from Close because CSV exports silently omit activity data.
Close
Custom Fields (Lead, Contact, Opportunity)
Odoo CRM
Custom fields (ir.model.fields)
lossyClose Custom Fields on Lead, Contact, and Opportunity map to Odoo custom fields created via Odoo Studio or the res.config.settings API. We read the Close field definition (type, choices, required flag) via the Close API and create matching Odoo fields of equivalent type before importing any records. Picklist choices become selection fields or many2one relations depending on cardinality. Required flags are set on the Odoo field definition.
Close
Custom Activities
Odoo CRM
Custom activity subtype (mail.message subtype)
lossyClose Custom Activities require a three-phase migration: first we create the Odoo mail.message subtype that represents the custom activity type, then we create any type-scoped custom fields in Odoo, then we import activity instances linked to the subtype. The parent type must exist before any custom field scoped to it, and both must exist before activity records can be inserted. We sequence this as a dependency chain during the schema phase.
Close
Custom Objects
Odoo CRM
Custom model (ir.model)
1:1Close Custom Objects migrate to Odoo custom models created via the Odoo ORM. We pre-create the custom model with the matching API name (e.g., x_close_custom_object), add all custom fields with their types, create any many2one lookup relationships to standard Odoo models (crm.lead, res.partner), and then import the data. Custom object records are migrated last in the import sequence because they often reference Leads, Contacts, and Opportunities.
Close
Attachment
Odoo CRM
ir.attachment
1:1Attachments on Close Leads and Contacts are downloaded via the Close API as binary files and uploaded to Odoo as ir.attachment records linked to the corresponding crm.lead or res.partner record. The original filename, MIME type, and file content are preserved. Any attachment metadata (description, tags) migrates as attachment description fields.
Close
Call Recording
Odoo CRM
ir.attachment (linked to call log)
1:1Close call recordings are retrieved as audio files via the Close API and uploaded to Odoo as ir.attachment records attached to the matching call log (mail.message) on the crm.lead. The audio file format (typically MP3 or WAV) is preserved. Retention metadata from Close migrates to the attachment description.
Close
Smart Views
Odoo CRM
Filters and saved searches
1:1Close Smart Views are named saved searches scoped to the Leads tab. We export the filter configuration (field conditions, operators, values) from the Close API and deliver it as a written inventory of saved search definitions for the customer's Odoo admin to recreate as Odoo Filters. Smart Views cannot be exported and re-imported into Odoo; manual recreation in the Odoo UI is required. The Contacts-tab-only limitation in Close means we validate all Smart Views via API before planning the export.
Close
User / Team Member
Odoo CRM
User (res.users)
1:1Close Users map to Odoo res.users records. We resolve by email match. Any Close User without a matching Odoo User goes to a reconciliation queue for the customer's Odoo admin to provision before record import proceeds. Permissions, role-based access control, and team membership do not migrate; Odoo admin configures these post-migration in Settings > Users.
| Close | Odoo CRM | Compatibility | |
|---|---|---|---|
| Lead | Lead1:1 | Fully supported | |
| Contact | Contact (created on Lead convert)1:many | Fully supported | |
| Opportunity | Opportunity1:1 | Fully supported | |
| Pipeline | Pipeline (crm.team)1:1 | Fully supported | |
| Pipeline Stage | Stagelossy | Fully supported | |
| Activities (Call, Email, SMS, Task) | Log activities on Lead/Opportunity1:1 | Fully supported | |
| Custom Fields (Lead, Contact, Opportunity) | Custom fields (ir.model.fields)lossy | Fully supported | |
| Custom Activities | Custom activity subtype (mail.message subtype)lossy | Mapping required | |
| Custom Objects | Custom model (ir.model)1:1 | Mapping required | |
| Attachment | ir.attachment1:1 | Fully supported | |
| Call Recording | ir.attachment (linked to call log)1:1 | Fully supported | |
| Smart Views | Filters and saved searches1:1 | Mapping required | |
| User / Team Member | User (res.users)1: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.
Close gotchas
CSV exports drop all activity history silently
Smart Views can only export from the Leads tab
Workflows gatekept behind Growth and Scale plans
Custom Activities require strict dependency ordering
Rate limits enforced per endpoint group
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 Odoo instance audit
We audit the source Close account across plan tier (Solo, Essentials, Growth, Scale), active pipelines and stages, Custom Activity and Custom Object definitions, Custom Field schemas per object, engagement volume by activity type, active Workflows, and Smart View configurations. In parallel we audit the destination Odoo instance: version, installed apps (CRM, Project, Inventory), existing custom fields, existing pipeline configurations, and Odoo user count. We identify the Close plan tier to confirm whether Workflows are in scope. The discovery output is a written migration scope document with object counts, a field-level mapping draft, and an Odoo configuration checklist.
Schema design and Odoo pipeline configuration
We design the destination schema in Odoo before any records are touched. This includes creating custom fields via Odoo Studio or the XML-RPC API, defining pipeline stages with probability weights matching Close, creating CRM Teams for each Close Pipeline, and designing the Custom Activity subtypes and Custom Object models. Schema design is validated in an Odoo test database before production migration begins. Any Odoo Enterprise dependencies (Odoo Studio access, custom model limits on lower tiers) are flagged during scoping.
Sandbox migration and reconciliation
We run a full migration into an Odoo test environment using a representative data sample (at minimum 100 records per object). The customer's project lead reviews record counts, spot-checks field mappings against the source Close data, and validates that pipeline stages display correctly. Any mapping corrections — field type mismatches, missing picklist values, required field gaps — are resolved in this phase. Sandbox sign-off gates the production migration start date.
User reconciliation and Odoo provisioning
We extract every distinct Close User referenced on Leads, Contacts, Opportunities, and activity records and match by email against the Odoo destination's res.users table. Any Close User without a matching Odoo User goes to a reconciliation queue. The customer's Odoo admin provisions missing users and assigns appropriate access rights before record migration begins. Owner assignment on Leads and Opportunities cannot proceed without resolved user references.
Production migration in dependency order
We run production migration in record-dependency order: Odoo custom models first (to receive lookups from standard objects), then CRM Teams and pipeline stages, then Leads (from Close Leads and staged Contacts), then Opportunities with resolved Lead and Contact references, then activity history (calls, emails, SMS, tasks via Odoo mail.message API), then Custom Activities, then attachments and call recordings, then Smart View inventory delivery. Each phase emits a row-count reconciliation report before the next phase begins. We use Odoo's XML-RPC API with batch chunking and exponential backoff on rate-limit responses.
Cutover, validation, and Workflow rebuild handoff
We freeze Close writes during cutover, run a final delta migration of records modified during the migration window, then enable Odoo CRM as the system of record. We deliver the Close Smart View inventory (as written filter definitions for Odoo recreation) and the Workflow inventory (as a rebuild guide with Odoo automated-activity equivalents). We support a one-week post-cutover window to resolve data quality issues raised by the customer's team. We do not rebuild Close Workflows as Odoo server actions, configure VoIP integrations, or set up Odoo ERP modules beyond CRM within the migration scope; these are separate engagements.
Platform deep dives
Close
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 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 Close and Odoo CRM.
Object compatibility
2 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
Close: Per endpoint group with a lower limit on write operations; 429 response includes rate_reset value; limits enforced at the organisation level across all API keys.
Data volume sensitivity
Close 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 Close to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Close 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 Close
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.