Migrate from Zoho CRM to Odoo CRM

Zoho Leads map to Odoo crm.lead records with type = lead. The Zoho Lead_Status picklist maps to Odoo's stage_id on the assigned crm.team. Lead_Source maps to a custom char or selection field since Odoo crm.lead does not include a native source field. Any custom fields on the Zoho Lead module are introspected via GET /settings/fields and mapped to ir.model.fields on the crm.lead model in Odoo before import. We flag that crm.lead in Odoo handles both leads and opportunities; the Zoho Lead-to-Deal relationship is handled by the separate Deals mapping.

Zoho Accounts map to Odoo res.partner records with is_company set to True. The Account_Name becomes the partner's name field, and Zoho's Phone, Website, and address subform (street, city, state, zip, country) map to the corresponding res.partner address fields. We import res.partner first in all migrations because Contacts have a parent_id lookup to res.partner that must be satisfied at insert time. Multi-address accounts in Zoho require separate res.partner address records (address_type = default, invoice, delivery) linked to the parent partner.

Zoho Contacts map to Odoo res.partner records with is_company = False and parent_id pointing to the Account's res.partner record. We sequence Account import before Contact import so the parent_id foreign key resolves cleanly. Zoho's Contact.Title maps to function, and email maps to email. Phone and Mobile map to phone and mobile respectively. Custom fields on Zoho Contacts migrate to ir.model.fields on res.partner.

Zoho Deals map to Odoo crm.lead records with type = opportunity. The Deal's Account lookup maps to crm.lead's partner_id pointing at the res.partner record created from the Zoho Account. Deal stage maps to stage_id within the assigned crm.team's pipeline. Amount, Closing_Date, and Owner map to planned_revenue, date_deadline, and user_id respectively. Multi-pipeline Deals in Zoho require crm.team pre-provisioning in Odoo so that we can assign the correct team_id at migration time.

Zoho Products map to Odoo product.product records. Product_Code maps to default_code, Unit_Price maps to list_price, and the Quantity_Unit maps to uom_id via Odoo's uom.uom lookup. Product active/inactive status maps to the product's active boolean. We import Products before any Quote or Sales Order import so that the product_id foreign key on sale.order.line resolves correctly.

Zoho Quotes map to Odoo sale.order records with state = draft. Quote line items are stored as subforms in Zoho and require a separate API fetch per quote; we reconstruct them as sale.order.line records with product_id, product_uom_qty, price_unit, and discount mapped from Zoho's corresponding fields. The Quote's Contact and Account map to sale.order's partner_id and partner_invoice_id / partner_shipping_id. Note: Odoo does not have a native PDF-quote versioning model at the CRM level; if Quote PDFs need preservation, we attach them as ir.attachment records linked to the sale.order.

Zoho activity modules (Tasks, Events, Calls) map to Odoo mail.message records linked to the parent crm.lead via res_id and model = crm.lead. Zoho's activity type maps to Odoo's activity_type_id via a mapping table. Subject, Due_Date, and Owner map to name, date_deadline, and user_id. Call duration and disposition map to custom fields on mail.message. Activity ordering is preserved by setting create_date to the original Zoho timestamp. Note: Odoo CRM's native activity model (crm.activity) is available in Enterprise; in Community we use mail.message as the activity record.

Zoho User records carry name, email, role, and profile assignments that map to Odoo res.users. We extract the Zoho Users module during discovery, build an email-to-user-ID mapping table, and match against Odoo's res.users email field at import time. Odoo's groups and access rights model differs from Zoho's roles and profiles; we flag any inactive Zoho users and recommend either activating a corresponding Odoo user or reassigning records to an active admin before migration. User provisioning in Odoo must happen manually before record import because Owner assignments require a valid user_id.

Zoho Tags are cross-module labels that map to Odoo crm.tag records. Tags export with their parent record in Zoho CSV but require separate API extraction for bulk migration. We parse tag arrays, create or match crm.tag records by name, and create crm.tag.rel junction table entries linking the tag to the target crm.lead record at migration time.

Zoho Attachments are stored as separate file records linked to parent modules via lookup IDs and do not appear in standard CSV exports. We fetch attachments via Zoho's Attachments API endpoint, download binary content, and upload to Odoo's ir.attachment model linked via res_model = crm.lead or res.partner and res_id = the target record's Odoo ID. We flag any attachments exceeding Odoo's default file size limit and note whether the customer has storage configuration planned in their Odoo deployment.

Zoho Custom Modules are supported via the Custom API endpoint and are introspected via GET /settings/fields to capture the full field schema before mapping. We pre-create equivalent custom fields on crm.lead or a custom Odoo model before migration. Schema varies per tenant, and custom module migration requires Python module development on the Odoo side (not a no-code operation). We scope custom module complexity during discovery and adjust timeline and pricing accordingly. Note: Odoo Community does not support Studio-level custom field creation without developer access; this is a planning constraint we surface at scoping.

Zoho Blueprints are workflow automation configurations stored as process rules, not data records. They do not export via API or CSV. We document every active Blueprint encountered during discovery: its trigger conditions, stage progression rules, and automated actions. The customer's Odoo administrator uses this inventory to rebuild equivalent automation in Odoo Studio (Enterprise) or as Python code (Community). We do not rebuild Blueprints as Odoo server actions inside the migration scope.