Migrate from LionDesk to Odoo CRM

LionDesk's Contact object maps to Odoo res.partner. Standard name, email, phone, address, and job title fields translate directly. Custom fields on the contact migrate as Odoo custom fields on res.partner. The contact's primary company (stored as company_id on the LionDesk record) resolves to the target res.partner's partner_id self-reference.

LionDesk contacts associated with active Deals generate a crm.lead record in Odoo. This creates a partner + lead link so the opportunity is attached to the correct contact. Contacts without deal associations only migrate as res.partner — no crm.lead is created. This split is evaluated per contact during migration.

LionDesk Company maps to Odoo res.partner in B2B mode. The company's name, domain, industry, employee count, and annual revenue map to res.partner fields (name, website, industry, employee_count, annual_revenue). Parent-company hierarchies in LionDesk (if used) map to res.partner parent_id self-references in Odoo.

LionDesk allows a contact to have a primary company but stores it as a property on the contact record rather than a separate company object. During migration, the company property on the contact is resolved to an existing res.partner (or created if no matching company exists), and the contact's partner_id is set to that partner's id.

LionDesk Deal maps to Odoo crm.lead. The deal name becomes the lead's name field; amount maps to Odoo expected_revenue (or planned_revenue depending on stage). Deal stage names are mapped value-by-value to crm.stage records scoped to the target crm.team. Owner assignment runs via email match to res.users before the lead is written.

LionDesk pipelines are not a separate object — pipeline is a property on the Deal. Each unique pipeline name in LionDesk creates a corresponding crm.stage record in Odoo's crm.stage table, scoped to a specific team_id. The stage sequence, legend_priority, and fold state are configured based on the pipeline's position in LionDesk.

Stage names are mapped one-to-one from LionDesk to Odoo. If the stage name already exists in Odoo under the target team, the existing stage id is used. If not, a new crm.stage record is created. The stage probability and forecast category are re-applied in Odoo based on standard Odoo stage configuration after migration.

LionDesk custom fields (data_type: Text, Number, Date, Dollar Amt) are created in Odoo as custom fields on res.partner and crm.lead before data migration runs. Text → Char, Number → Float or Integer (based on field name context), Date → Date, Dollar Amt → Monetary. The field definition and values are migrated together so no post-migration data entry is required.

LionDesk logged calls, emails, and notes migrate as Odoo mail.activity records linked to the parent res.partner or crm.lead. Original timestamps, subject, and body content are preserved. For emails that are stored as plain text in LionDesk, they write to mail.message as notes on the partner record since Odoo does not have a native email activity type in the standard CRM model.

LionDesk drip campaigns store membership and sequence-step data as record properties on contacts. Odoo has email marketing (mass_mailing) and automation rules, but no drip-campaign membership model that mirrors LionDesk's. We export the campaign names and step definitions as a structured JSON reference file for your Odoo admin to rebuild using Odoo email marketing or custom automation rules.

LionDesk file attachments on contacts, companies, or deals are downloaded and re-uploaded to Odoo as ir.attachment records linked to the corresponding res.partner or crm.lead. File names and original create dates are preserved in the attachment record. Odoo's attachment size limit and storage backend (file system, S3) apply.

LionDesk owner_id on contacts and deals resolves to Odoo res.users by email address match. Unmatched owners are flagged before migration — your team either creates the corresponding Odoo user first or assigns records to a fallback user. The original LionDesk owner id is preserved in a custom field (Source_Owner_ID__c equivalent) for audit purposes.