Migrate from Dashly to Odoo CRM

Dashly Leads map directly to Odoo crm.lead records. Standard properties (name, email, phone, company) map to crm.lead fields name, email_from, phone, and partner_name respectively. Custom Lead properties are inventoried during discovery and created as ir.model.field definitions on crm.lead before migration. The crm.lead type field defaults to lead for unqualified records and is set to opportunity when a deal amount or pipeline assignment exists. We use Odoo's XML-RPC API with create() calls to insert records in batches of up to 100, handling field type mapping (date fields, many2one lookups, char/text fields) per Odoo's ORM expectations.

Dashly Company records map to Odoo res.partner with is_company=True. Dashly's standard company fields (name, domain, industry) map to partner name, website, and industry_id respectively. Custom company properties migrate as custom fields on res.partner. The res.partner record is created before any Lead migration so that the crm.lead partner_id lookup (many2one) is satisfied at insert time. If a Dashly Lead references a Company, we create the partner first, then link the lead via partner_id on crm.lead.

Dashly Conversations attached to a Lead map to Odoo mail.thread records linked to the corresponding crm.lead. Odoo does not have a native conversation object; instead, each crm.lead gets a mail.thread record that accumulates mail.message child records. Conversation metadata (status, assignee, source channel, created timestamp) is stored as mail.thread custom fields or crm.lead extension fields. Multiple Dashly conversations per Lead become multiple thread entries within the same lead's conversation history in Odoo.

Dashly Messages within Conversations map to Odoo mail.message records as child records of the crm.lead's mail.thread. Each message preserves sender attribution (agent name or visitor identifier), body content, timestamp, and delivery channel via mail.message body, author_id, date, and subtype fields. We reconstruct thread ordering by setting mail.message date to the original Dashly timestamp. Messages from Dashly that reference a deleted or unmigrated Lead are held in a dead-letter queue for manual review.

Dashly User accounts (agents and admins) map to Odoo res.users by matching on email address. We extract Dashly user records including name, email, role, and availability status. Inactive Dashly users map to Odoo Portal users or inactive res.users records depending on whether the customer wants historical attribution preserved. The Odoo res.users records must exist before any crm.lead owner assignment because crm.lead user_id is a many2one to res.users.

Dashly Contacts nested under Companies in Dashly map to Odoo res.partner records with is_company=False and parent_id pointing to the company partner record. Dashly contact records (name, email, phone, job title) map to res.partner name, email, phone, and function respectively. This creates the Odoo standard partner hierarchy: company as the parent partner with individual contacts as child records. If Dashly stored contacts without a parent company, they migrate as standalone res.partner records without a parent_id.

Tags applied to Dashly Leads and Companies map to Odoo crm.tag records attached via crm.lead.tag_ids (many2many). Dashly tag names become crm.tag names, deduplicated at migration time to avoid duplicate Odoo tags. If a Dashly tag name conflicts with an existing Odoo crm.tag, we merge them under the existing tag ID. Tags on Companies map to res.partner category_id (many2many to res.partner.category) for consistency.

Dashly custom fields on Leads and Companies are inventoried during discovery, including data type, required status, and all unique values for picklist fields. We create corresponding custom fields on crm.lead and res.partner via Odoo's ir.model.data before migration begins. Char fields map to char, text areas to text, dates to date, numbers to float or integer, and multi-select or checkbox fields to char or many2many depending on Odoo version. All custom field values migrate as part of the Lead and Company insert phases.

Dashly Leadbots are structured automation configs with trigger conditions, dialogue trees, and action sequences stored as JSON. Odoo does not share this schema. We export the full bot configuration as structured JSON files (one per Leadbot) and deliver a written rebuild guide mapping each Dashly trigger condition to an Odoo Automated Action or Server Action with the equivalent logic. The automation rebuild itself is manual and not within standard migration scope. The exported JSON files are delivered as part of the migration handoff package.

Dashly triggered message rules define automated outbound sequences tied to visitor behavior or time delays. The trigger rules and message content are exported as structured automation data. Odoo's Automated Actions support time-based triggers and write actions but do not have native email sequence cadence logic. We deliver an exported JSON file of all triggered message configurations and a written mapping guide recommending the closest Odoo Automated Action equivalent for each rule. The rebuild is a manual admin task post-migration.

Dashly Knowledge Base articles (title, body content, category associations) map to Odoo document.page records. Article body content migrates as document.page content. Dashly article categories map to document.folder or parent document.page hierarchy depending on the target Odoo version. SEO settings (meta title, meta description, URL slug) are preserved in document.page custom fields since Odoo's document.page does not have native SEO fields. The customer should review and republish migrated articles in Odoo's document management module after migration.

Dashly conversation assignee data and team routing rules map to Odoo crm.team records and crm.lead.team_id / user_id assignments. We extract Dashly team inbox assignments and map them to Odoo crm.team structure (name, member_user_ids). Dashly assignee agents map to res.users and are linked to crm.team as member_user_ids. Conversation routing rules are exported as configuration data and delivered as a written mapping document; the actual crm.team setup is configured in Odoo during migration setup.