Migrate from Kylas Sales CRM to Odoo CRM

Kylas Lead records map to Odoo crm_lead. The Kylas lead_score and lead_source fields transfer to crm_lead's x_studio_lead_score and source_id (linked to crm.lead.lost_reason or crm.lead.tag.rel). Kylas Leads with status 'converted' land in Odoo's crm_lead with stage set to the corresponding pipeline stage equivalent; Kylas Leads with status 'open' land in Odoo's New or Qualified stage. We preserve Kylas lifecycle_stage as a custom Char field x_kylas_lifecycle_stage on crm_lead for audit. Kylas's lead_owner maps to crm_lead's user_id via email-matched User lookup.

Kylas Contact records map to Odoo res.partner with partner_type = 'contact'. Kylas custom fields on Contact transfer to res.partner as custom columns via Odoo Studio field creation before import. Email uniqueness validation in Kylas is preserved via a SQL UNIQUE constraint on the email_normalized column in Odoo; duplicate emails across Kylas Contacts are flagged in the pre-migration audit for manual resolution. The Kylas lifecycle_stage value is stored in a custom Char field on res.partner.

Kylas Company records map to Odoo res.partner with partner_type = 'company' and child contact partners for each linked Contact. Industry classification from Kylas transfers to a custom selection field x_industry on res.partner. Multi-currency settings on Kylas Company map to the currency_id field on res.partner if Odoo's multi-company configuration is active. Company size maps to x_company_size as a selection field.

Kylas Deal records map to Odoo crm_lead in the sale pipeline. Kylas deal_value maps to crm_lead's planned_revenue. Expected close date maps to date_deadline. Owner assignment maps to user_id via email resolution. Kylas pipeline stage maps to Odoo stage_id; see Pipeline Stage mapping for detail on the seven-stage ceiling and consolidation logic.

Kylas pipeline names map to Odoo crm.lead.pipeline records. Odoo CRM enforces a maximum of seven stages per pipeline. If a Kylas pipeline exceeds seven stages, we flag the surplus stages during scoping and recommend merging adjacent stages (e.g., combining Negotiation and Proposal into a single Proposal stage) before migration. Stage probability percentages from Kylas transfer to Odoo stage probability fields. The mapping document is reviewed and approved by the customer before any stage consolidation is applied.

Kylas custom fields on any object are exported with field type, picklist value IDs, and current values. We pre-create corresponding fields in Odoo via Studio (for simple types) or via XML data migration script (for relational, monetary, or computed fields) before any record data is written. Picklist value ID remapping is required because Kylas uses integer picklist IDs while Odoo selection fields use string keys. We generate a picklist translation table during the pre-migration audit and apply it during the transform phase.

Kylas activity records (Tasks, Calls, Notes, Meetings) attach to their parent record (Lead, Contact, Deal, Company) via Odoo's mail.message and crm.lead.activity model. Activity timestamps and owner assignments are preserved. Kylas field-sales check-in activities may not have a direct Odoo equivalent; we map them to generic crm.lead.activity records with activity_type set to 'other' and the original check-in notes stored in the activity note field for manual review post-migration.

Kylas document blobs export as binary files with parent record association metadata. We map each document to Odoo ir.attachment linked to the corresponding res.partner or crm.lead record via res_model and res_id. Very large document stores exceeding 5 GB total may require batched import with rescheduling between batches to avoid Odoo's worker timeout thresholds.

Kylas tag vocabulary (across all objects) exports as a unified tag list. We import tags into Odoo crm.lead.tag, then apply crm.lead.tag.rel entries to the corresponding crm_lead records during the Deal migration phase. Duplicate tag names from different Kylas objects are deduplicated and unified into a single Odoo tag vocabulary.

Kylas user records (name, email, role, profile) export and map to Odoo res.users via email lookup. Inactive Kylas users are created as Odoo users with active=False. The customer's Odoo admin provisions the actual Odoo users (email, password, access rights) before the production migration runs. Owner assignments on Kylas Deals and Leads resolve to Odoo user_id at migration time via the email match table.

Kylas Smart Lists are dynamic saved searches with query-based membership that does not produce a persistent record set. We export the Smart List filter criteria (field names, operators, values) as a documented inventory for manual recreation in Odoo as ir.filters. The records within each Smart List migrate as standard filtered exports against the base objects (Contact, Lead, Deal). Smart List recreation is out of scope for the data migration and is listed as a post-migration admin task.

Kylas workflow automation rules (triggers, conditions, action sequences) are not exposed via the Kylas export API. We deliver a written inventory of every active Kylas automation documenting trigger type, conditions, and action sequence with a recommended Odoo Studio or server action equivalent. The customer's Odoo admin or an Odoo implementation partner rebuilds the automations post-migration. This is a platform-level restriction and applies regardless of migration tooling choice.