CRM migration
Field-level mapping, validation, and rollback between Ready_ and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Ready_
Source
Odoo CRM
Destination
Compatibility
7 of 12
objects map 1:1 between Ready_ and Odoo CRM.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from Ready_ to Odoo CRM is a cross-platform structural migration. Ready_ uses separate Contact and Company objects with sequential REST API reads required because no bulk export endpoint is documented. Odoo CRM stores leads and contacts as res.partner records using a company_type field to distinguish persons from organizations, which means Ready_ Companies map to res.partner with company_type=company and Ready_ Contacts map to res.partner with company_type=person, linked via parent_id. Deals attach to named Pipelines and Stages that we must enumerate and map explicitly during scoping. Owner assignments in Ready_ use internal Team Member IDs that are meaningless in Odoo; we resolve those IDs to email addresses first, then match or provision the corresponding res.users records before assigning ownership. Odoo's XML-RPC API enforces a 1-call-per-second throttle on external API access, so we batch records into groups of 50 with deliberate delays during insert. We do not migrate automations, sequences, or workflow rules; we deliver a written inventory of these for the customer's admin to rebuild in Odoo Studio or via server actions.
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 Ready_ 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.
Ready_
Contact
Odoo CRM
res.partner (company_type = person)
1:1Ready_ Contact records map to Odoo res.partner with company_type = 'person'. Standard fields (name, email, phone, street, city, state, country, zip) migrate directly to the corresponding Odoo partner fields. If the Ready_ Contact is associated with a Company record, we set parent_id on the res.partner to point to the corresponding company-type partner. Custom fields on the Contact migrate to res.partner custom fields created in Odoo via Studio or module definition before import. Email uniqueness is enforced as a partner dedupe key during insert.
Ready_
Company
Odoo CRM
res.partner (company_type = company)
1:1Ready_ Company records map to Odoo res.partner with company_type = 'company'. The company name maps to name, domain to website, and firmographic fields (industry, employee_count, annual_revenue) migrate to custom fields on the company partner record. Related Contacts import after the parent Company partner so that parent_id references resolve at insert time. We create the company partner first in every batch to satisfy the foreign key constraint.
Ready_
Deal
Odoo CRM
crm.lead
1:1Ready_ Deals map to Odoo crm.lead records. The deal value maps to planned_revenue, expected_close_date maps to date_deadline, and owner_team_member_id resolves to the res.users id via the email lookup table we build during owner reconciliation. Pipeline and Stage assignment requires a pre-migration mapping table because Ready_ allows fully custom pipeline and stage names. We create an Odoo Sales Team per unique Ready_ pipeline and map the stage names to Odoo stage sequence values.
Ready_
Activity
Odoo CRM
mail.activity
1:1Ready_ Activities (calls, emails, tasks) map to Odoo mail.activity records. The activity type (call, email, task) maps to activity_type_id, which we configure as custom activity types in Odoo CRM before migration. The timestamp, notes, and linked Contact or Deal reference migrate to the corresponding Odoo fields. We resolve the activity's linked record reference to the Odoo res.partner or crm.lead id before insert. Activity chaining and sequence order are preserved in the Odoo activity's note or in a custom sequence field if the customer's workflow depends on ordering.
Ready_
Pipeline Stage
Odoo CRM
crm.stage
lossyEach unique pipeline name in Ready_ becomes a Sales Team in Odoo, and each stage name within that pipeline becomes a crm.stage record attached to that team. Stage sequence order migrates from Ready_ to Odoo's sequence integer. If the customer uses multiple pipelines with overlapping stage names, we scope the stage to the team to prevent collisions. Odoo's stage wizard_states (draft, open, won, lost) are assigned based on the stage name semantics collected during scoping.
Ready_
Custom Fields (Contacts)
Odoo CRM
res.partner custom fields
lossyReady_ custom fields on Contacts (text, number, date, picklist) migrate to Odoo res.partner custom fields. We create the field definitions in Odoo before importing any Contact data, matching field type (char for text, integer for number, date for date, selection for picklist). Picklist values in Ready_ map to Odoo selection option tuples. Custom field values migrate as part of the Contact partner insert.
Ready_
Custom Fields (Companies)
Odoo CRM
res.partner custom fields (company type)
lossyReady_ custom fields on Companies migrate to res.partner custom fields using the same type-mapping logic as Contact custom fields. Because company-type partners and person-type partners share the same res.partner model, both Contact and Company custom fields live on the same Odoo model. We distinguish them during scoping by recording which fields apply to which company_type so that the Odoo admin knows which fields appear on which partner view.
Ready_
Custom Fields (Deals)
Odoo CRM
crm.lead custom fields
lossyReady_ custom fields on Deals migrate to Odoo crm.lead custom fields. We create the field definitions in Odoo via Studio or module XML before importing any lead data. The type mapping follows the same rules as Contact custom fields. Custom field values migrate as part of the crm.lead insert.
Ready_
Team Member
Odoo CRM
res.users
1:1Ready_ Team Members represent users and store name and email. We extract every distinct Team Member ID referenced on Deals, Activities, and Contacts, resolve the ID to the email address, then match against the destination Odoo res.users table. If a matching User does not exist, we flag it in the owner reconciliation queue and the customer's Odoo admin provisions the User before migration continues. Owner assignments on crm.lead and mail.activity reference res.users id.
Ready_
Note
Odoo CRM
mail.message
1:1Ready_ Notes attached to Contacts or Deals migrate to Odoo mail.message records as internal notes (message_type = 'comment', subtype = 'note'). The note body migrates as the message body, the linked record resolves to the corresponding res.partner or crm.lead id, and the original timestamp preserves the activity date. Attachments on Notes migrate as ir.attachment records linked via the res_model and res_id to the mail.message.
Ready_
Deal Stage
Odoo CRM
crm.stage sequence position
lossyThe Ready_ Deal Stage is extracted from the Deal record and maps to the sequence integer on the corresponding Odoo crm.stage within the appropriate Sales Team. Stage probability percentages from Ready_ map to Odoo's optional stage_hardness or a custom probability field if the customer uses stage-based forecasting. We build the complete stage sequence map during scoping before any Deal records are imported.
Ready_
Contact-Company Association
Odoo CRM
res.partner parent_id link
1:1Ready_ maintains an association between Contact and Company records. During migration, we read the association table, extract the Company ID and Contact ID for each pair, then set parent_id on the Contact's res.partner record to reference the Company partner's res.partner id. This establishes the Odoo partner hierarchy used for displaying child contacts under the parent company in Odoo's partner views and reporting.
| Ready_ | Odoo CRM | Compatibility | |
|---|---|---|---|
| Contact | res.partner (company_type = person)1:1 | Fully supported | |
| Company | res.partner (company_type = company)1:1 | Fully supported | |
| Deal | crm.lead1:1 | Fully supported | |
| Activity | mail.activity1:1 | Fully supported | |
| Pipeline Stage | crm.stagelossy | Fully supported | |
| Custom Fields (Contacts) | res.partner custom fieldslossy | Fully supported | |
| Custom Fields (Companies) | res.partner custom fields (company type)lossy | Fully supported | |
| Custom Fields (Deals) | crm.lead custom fieldslossy | Fully supported | |
| Team Member | res.users1:1 | Fully supported | |
| Note | mail.message1:1 | Fully supported | |
| Deal Stage | crm.stage sequence positionlossy | Fully supported | |
| Contact-Company Association | res.partner parent_id link1: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.
Ready_ gotchas
No documented bulk export endpoint
Pipeline and stage names require explicit mapping
Owner assignments rely on Team Member IDs that do not persist across systems
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 source Ready_ account for record counts across Contacts, Companies, Deals, Activities, Notes, and custom fields. We collect the full pipeline configuration: all pipeline names, stage names per pipeline, and stage sequence order. We extract all Team Member records (name and email) for owner reconciliation. We review any custom field definitions including field type, picklist values, and which object each field attaches to. The discovery output is a written migration scope document covering record counts, a preliminary object mapping, a pipeline-to-Sales-Team mapping table, and an owner reconciliation list.
Odoo schema preparation
Before importing any records, we create the destination schema in the Odoo instance. This includes creating custom fields on res.partner (for Contact and Company custom fields) and crm.lead (for Deal custom fields) via Studio or module XML. We create Sales Teams mapped to the Ready_ pipeline names and create crm.stage records within each team with names and sequence values mapped from the Ready_ stage configuration. We create custom activity types in Odoo CRM to match the Ready_ activity types (call, email, task). All schema creation happens in a staging or sandbox Odoo environment first for validation.
Owner reconciliation and user provisioning
We extract every distinct Team Member ID referenced on Deals and Activities, resolve the ID to the email address from the Team Member record, and match against the destination Odoo res.users table. Any Team Member without a matching Odoo User is added to a reconciliation queue. The customer's Odoo admin provisions the missing Users (active status determined by whether the original Team Member is still active in Ready_). Owner reconciliation must be complete before we begin importing Deals and Activities because OwnerId is a required reference on crm.lead and mail.activity.
Sequential extraction from Ready_ with pagination
We extract data from Ready_ using sequential REST API reads in batches of 200 records. We read Contacts and Companies first, then Deals, then Activities, then Notes. Each object type uses pagination tokens to resume on timeout. We apply a read delay between batches to avoid triggering any undocumented throttling on the Ready_ side. The extracted data is staged in a CSV format with a manifest of record counts per object type for reconciliation against the destination Odoo record counts.
Sandbox migration and validation
We run a full migration into an Odoo sandbox environment using production-like data volume. We import Company partners first (res.partner with company_type = company), then Contact partners (res.partner with company_type = person with parent_id resolved), then crm.lead records with stage_id resolved from the pipeline mapping table, then mail.activity records with owner_id resolved from the user lookup table. Each phase emits a row-count reconciliation report. The customer's Odoo admin spot-checks 20-30 records against the Ready_ source and signs off the mapping before production migration begins.
Production migration with rate-limit batching
We run production migration in dependency order: Companies (res.partner company_type = company), Contacts (res.partner person type with parent_id), Custom Fields definitions (if not created earlier), Leads (crm.lead), Activities (mail.activity), Notes (mail.message). Each insert batch is limited to 50 records with a 60-second delay between batches to respect the Odoo 1-call-per-second API limit. We use Model.create() with record lists to reduce the per-record call overhead. Activities import after the parent Contacts and Deals so that the res_model and res_id references resolve.
Cutover, final validation, and automation inventory handoff
We freeze writes on the source Ready_ account during cutover, run a final delta migration of any records modified during the migration window, then enable Odoo CRM as the system of record. We deliver a written inventory of every Ready_ automation, workflow, and custom field configuration with Odoo equivalents noted for the customer's admin to rebuild in Odoo Studio. We support a one-week hypercare window for reconciliation issues raised by the customer's team. Workflow rebuilds, automation rebuilds, and training are outside the standard migration scope.
Platform deep dives
Ready_
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Moderate CRM migration. 4 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Ready_ and Odoo CRM.
Object compatibility
4 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
Ready_: Not publicly documented.
Data volume sensitivity
Ready_ 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 Ready_ to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Ready_ 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 Ready_
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.