Migrate from HighQ to Odoo CRM

HighQ File records map to Odoo ir.attachment. The file name becomes the attachment name field, file content migrates as a binary attachment, and the original HighQ storage path is preserved as a custom Char field on the attachment record. The migration also captures file size, mime type, and creation timestamps to maintain full metadata fidelity in Odoo.

HighQ contact information found in File metadata, Task assignee fields, or iSheet contact columns maps to res.partner. Email is the primary key used to match to existing Odoo partner records or create new ones during migration. When a matching email is found, the existing res.partner record is updated with additional HighQ-sourced data; if no match exists, a new partner record is created and linked appropriately.

HighQ company text fields are mapped to res.partner records with type='company'. When no matching company partner exists, one is created dynamically during migration. The original company name is stored in the partner name field. Additional company details such as address, phone, and website are mapped to the corresponding res.partner fields where available, ensuring the company record is fully populated in Odoo.

HighQ task records migrate to crm.activity entries on the related res.partner record. Task name becomes activity summary, due date maps to date_deadline, and priority maps to activity_type. Completion status and original assignee are preserved as custom fields. The migration also records the original task creation date and any task descriptions as notes on the crm.activity record for complete historical context.

HighQ user accounts are matched to Odoo res.users by email address. Unmatched users are flagged before migration so the team can create their Odoo accounts first. The original HighQ user ID is stored as a custom field for audit traceability.

HighQ iSheet columns are exported as CSV and mapped to custom fields on res.partner or crm.lead depending on the iSheet type. Each iSheet may require a separate custom field group and is validated for data type compatibility before import. The migration process also checks for pick-list values in the iSheet and creates corresponding selection fields in Odoo with mapped option labels, ensuring dropdown data translates correctly.

HighQ Sites are workspaces that group Files, Tasks, and Users. Since Odoo has no direct Site equivalent, Site membership is preserved as a custom Char or Many2many field on res.users, and Site name is stored as a custom field for reference.

HighQ folder hierarchy is stored as a custom Char field (File_Path__c) on each ir.attachment record. The flat attachment list in Odoo does not replicate the original folder structure — the path field preserves the original location context. This allows users in Odoo to search and filter attachments by the original HighQ folder path, maintaining navigational context even though the native Odoo attachment view does not display a folder tree.

HighQ Workflows with rule chains, conditional branching, and task reassignment automations have no direct Odoo equivalent. These must be rebuilt manually using Odoo Studio Automation Rules or server actions. FlitStack exports workflow definitions as a reference document for the Odoo admin.

HighQ permission levels (Viewer, Contributor, Admin per Site) are preserved as custom fields on res.users. Odoo's record-level security and access groups differ fundamentally, so the Odoo admin reviews and assigns appropriate res.groups based on the exported permission metadata. The custom fields store the original HighQ permission tier for each user, enabling the admin to map Viewer to internal/public groups, Contributor to user groups, and Admin to manager or administrator groups in Odoo.

HighQ Files and Contacts may carry an is_sensitive flag indicating restricted access. This maps to a custom Boolean field (Is_Sensitive_Source__c) on ir.attachment or res.partner for compliance reference in Odoo. The flag is set to True when the original HighQ object was marked sensitive, allowing Odoo users to identify restricted records and apply appropriate access controls or data handling procedures within the new system.

Every migrated HighQ record receives a Source_System_ID__c custom Char field storing the original HighQ object ID. This enables delta-run deduplication, audit traceability, and cross-referencing without relying on the newly assigned Odoo IDs. During subsequent migration runs, the Source_System_ID__c field is used to identify records that already exist in Odoo, preventing duplicate creation and ensuring that updates to HighQ data are correctly applied to the corresponding Odoo records.