Migrate from Kizen to Odoo CRM

Kizen Contacts map to Odoo res.partner records with partner_type = 'contact'. Standard Kizen fields (name, email, phone, address, lifecycle stage, owner) map to name, email, phone, street/city/country, category_id (as tags), and user_id respectively. Kizen custom Contact properties migrate as ir.model.fields on res.partner via a custom module deployed before migration. Owner resolution uses email match against Odoo's res.users table.

Kizen Companies map to Odoo res.partner records with partner_type = 'company'. Kizen's Primary relationship linking Contacts to Companies maps to Odoo's child_ids (one2many from the company partner to its contact children). Domain, industry, size, and revenue fields migrate as custom Char or Selection fields on res.partner. Company records are imported before Contact records to satisfy the parent partner lookup.

Kizen Deals map to Odoo crm.lead records with type = 'opportunity'. Deal stage maps to Odoo's stage_id using a stage-mapping table created during schema design. Deal amount, close date, and owner migrate to planned_revenue, date_deadline, and user_id respectively. Kizen's Primary relationship linking Deals to Companies and Contacts reconstructs as partner_id (many2one to res.partner) and contact_id on the crm.lead.

Kizen pipeline definitions (ordered stage lists with optional stage-specific defaults) map to Odoo crm.lead.plan records. We create one crm.lead.plan per Kizen pipeline and assign it to the corresponding crm.lead records during migration. Stage probabilities from Kizen are stored as custom Float fields on crm.lead for reporting use.

Kizen Activities are a generic interaction log linked to any Kizen Object. We split by activity_type at migration time: email activities map to Odoo mail.message records (via mail.thread convention), meetings map to calendar.event, tasks to project.task or crm.lead.calendar_event_ids, and generic notes to note.note. The parent Kizen Object reference resolves to the corresponding Odoo record ID using the migration ID cross-reference table.

Each Kizen custom Object requires a custom Odoo module with ir.model and ir.model.fields declarations. We run schema discovery against the Kizen API to enumerate all custom Objects and their fields, then generate the XML metadata for the custom module during the schema design phase. Relationship fields in Kizen custom Objects (Primary and Additional types) map to many2one or many2many field declarations in the custom module. This is the most time-intensive part of a Kizen migration because there is no fixed target schema.

Kizen custom fields of type text, number, date, choice, currency, and relationship migrate as Odoo custom fields via Studio (for immediate needs) or via ir.model.fields XML in the custom module (for production deployments). Choice/picklist fields in Kizen map to Odoo selection fields with the same value labels. Currency fields map to monetary fields with the Odoo currency_id context set at migration time.

Kizen Primary relationship fields link a parent Object to child Object records in a one-to-many structure. We map these to Odoo one2many fields declared on the parent model in the custom module. For example, a Kizen Company with a Primary relationship to Contacts becomes res.partner with a child_ids one2many pointing to contact-type partner records. The Odoo ORM enforces referential integrity automatically.

Kizen Additional relationship fields are many-to-many associations between Object records. We implement these as Odoo many2many fields declared on both participating models using the rel_table naming convention. If the many2many has additional attributes (e.g., a role field on the association), we create an intermediate Odoo model with two many2one fields, preserving the association metadata.

Kizen Forms and Surveys create and update Object records on submission. Form field definitions (names, types, conditional logic) are exported as a form structure document. Submitted form data (the resulting Object records) migrates as normal data into the mapped Kizen Object equivalents. The form definition itself is documented for manual rebuild in Odoo Survey or a custom module.

Kizen file attachments linked to Objects migrate as Odoo ir.attachment records. We preserve the original filename, MIME type, and binary content. The res_model and res_id on ir.attachment point to the migrated Odoo model and record ID. Document management capabilities (shared documents, portals) are not migrated; the file binary is preserved but the document management UI must be configured in Odoo separately.

Kizen tags applied to Object records migrate to Odoo res.partner.category (for partner tags), crm.tag (for opportunity tags), or a custom tag field depending on the target model. Tags stored as multi-checkbox custom properties in Kizen map to Odoo many2many tags. Tags without a clear Odoo equivalent are preserved as a multi-value Char field on the target record for the admin to classify post-migration.

Kizen Owners (users assigned to Object records) map to Odoo res.users by email match. We extract all distinct owner references from Kizen and match against the destination Odoo res.users table. Owners without a match enter a reconciliation queue for the customer to provision before record import resumes. Owner assignment on migrated records uses user_id on the Odoo model.

Kizen standard workflow automations (field updates, email triggers, task creation, stage changes) are exported as a plain-text inventory documenting the trigger event, conditions, action sequence, and recommended Odoo Studio equivalent. The customer's Odoo admin rebuilds these using Studio server actions, automated actions, or a custom module. AI-driven Kizen automations are documented separately with a note that Odoo has no LLM-driven execution layer.