Migrate from Kinabase to Odoo CRM

Person-type Kinabase Collections map to Odoo res.partner records with contact_type set to contact and address=False. We create the partner schema in Odoo (name, email, phone, custom fields) during the schema design phase before any records are loaded. The Kinabase Collection name becomes the Odoo model and field set. Each Collection requires its own field mapping because Kinabase schema is per-Collection rather than global.

Organisation-type Kinabase Collections map to Odoo res.partner with contact_type=company, creating the parent record that individual contacts attach to via the child_id one2many relationship. If the original Kinabase Collection held both people and organisations, we split records by a type field or naming convention into company and contact partners during the transform phase.

Deal-type Kinabase Collections map to Odoo crm.lead with type=opportunity. The crm module must be installed in the target Odoo database for crm.lead and crm.stage to exist. Pipeline stage values from Kinabase map to crm.stage records ordered by sequence, with probability percentages preserved as stage_properties. Closed-won and closed-lost outcomes are set via the crm.lead stage.kanban_state field.

Collections representing unqualified prospects, inbound inquiries, or pre-sales records map to Odoo crm.lead with type=lead. If the original Kinabase Collection contains both qualified and unqualified records, we split them by a status or stage field: leads map to type=lead, records with a deal value or signed scope map to type=opportunity. The customer decides the split rule during scoping.

Individual Kinabase Records map row-by-row to Odoo partners or crm.lead records depending on their parent Collection's classification. We handle null values, empty strings, and multi-select dropdowns by mapping them to Odoo's equivalent field types (char, text, selection, many2many). Multi-select values migrate to Odoo tags (ir.attachment with res_model=res.partner) or many2many fields if the schema is pre-configured.

Kinabase field types map to Odoo field definitions: text to char or text, number to float or integer, date to date, datetime to datetime, dropdown to selection, file attachment to binary. Custom fields are created on the Odoo model via XML-RPC before import. All non-standard fields require a field-level mapping because Kinabase has no global field registry — each Collection has its own independent schema.

A Kinabase linked collection field (e.g., a Projects Collection with a Client field pointing to a Clients Collection) creates a cross-collection reference that Odoo must represent as a many2one foreign key on the child object. We export linked records in dependency order — parents first — and resolve the foreign key ID during the child load phase. Many-to-many linked fields (e.g., a Contact in multiple Teams) map to Odoo many2many relation tables. Orphaned references (linked record no longer exists) are preserved as a text field storing the original record identifier.

Kinabase computed Fields evaluate a formula at display time. Since Odoo Studio does not expose computed field formulas (computed fields require Python module development), we evaluate the formula at migration time and write the resulting value as a static stored field in Odoo. The formula logic is lost; only the computed result transfers. We flag every computed field in the pre-migration field audit and document the original formula for the customer's developer if they want to rebuild it as an Odoo computed field.

Kinabase activity records (engagement history on a record) map to Odoo mail.activity with activity_type_id set from the standard Odoo activity types (Email, Call, Meeting, Todo). Activity dates migrate as date and create_date; assigned user migrates as res.users by email match. The mail.thread mechanism on res.partner and crm.lead surfaces activities in Odoo's chatter UI automatically.

Kinabase standalone Tasks map to Odoo project.task if the project module is active and a project exists to host them. Without the project module, Tasks migrate as mail.activity records with activity_type_id=Todo. We verify whether the project module is installed during discovery and configure the mapping accordingly.

Kinabase email engagements migrate to Odoo mail.message records linked via mail.thread (res.partner, crm.lead, project.task) with message_type=email. Body content and subject line migrate as the message body; sender and recipient are mapped from the Kinabase engagement contact references. Email attachments migrate as ir.attachment records linked via mail.message.attachment.

Kinabase call engagements map to Odoo mail.activity with activity_type_id=Call. Call duration, disposition, and recording URL migrate to custom activity fields if pre-configured on the Odoo model. The activity date reflects the original call timestamp to preserve the chronological timeline in Odoo's chatter.

Kinabase meeting engagements map to Odoo calendar.event with start_datetime, stop_datetime, and location preserved. Attendee links are created as calendar.attendee records pointing to the resolved res.partner and res.users records. The event is linked to the parent record (crm.lead, res.partner, project.task) via the calendar.event.res_id and res_model fields.

Kinabase engagement Notes migrate to Odoo mail.message with message_type=comment. The note body becomes the message body; attachments become ir.attachment records linked via mail.message.attachment. Notes are linked to the parent record via mail.thread, making them visible in the Odoo chatter pane for the corresponding partner or lead.

Kinabase documents attached to records migrate as Odoo ir.attachment records. If the source document is a URL reference, we store the URL in the ir.attachment.url field. If the source provides a file blob via API, we download and upload it as binary. Actual file content transfer depends on whether the source export includes binary data; URL references are always migrated regardless of blob availability.

Kinabase pipeline stages map to Odoo crm.stage records ordered by sequence. The stage name, probability percentage, and is_won flag transfer. Kinabase automation triggers and approval gates are captured as a written inventory separate from the stage record; they do not migrate as executable code because Odoo automation requires a separate Studio or Python configuration.

Kinabase workflows (stage progression rules, triggers, role-based permissions, scheduled actions) are captured as a structured written inventory during discovery. We document each workflow's trigger condition, actions, and stage mapping. Odoo CRM automations (server actions, automated actions on stage change) require configuration in Odoo Studio or Python development; the inventory provides the requirements spec for the customer's admin or Odoo partner to rebuild. Workflow execution logic does not migrate as functional code.

Kinabase tags stored as multi-checkbox custom properties migrate to Odoo res.partner.category (the built-in partner tag system) via ir.model.data references. If the Kinabase tag vocabulary is large or used across multiple object types, we recommend a custom tag model rather than the standard partner category to avoid scope confusion.