Migrate from Constructor to Odoo CRM

Constructor contacts map to Odoo crm.lead records with type='lead' by default. The contact's name splits into firstname and lastname on the Odoo partner; if the contact has no firstname the full name lands in the partner's display_name field. Constructor company_id resolves to an Odoo res.partner record with is_company=True before the contact is written.

Constructor companies map directly to Odoo res.partner records with is_company=True set. The partner's address fields (street, city, state, zip, country) are written from Constructor's address block. Parent-company relationships in Constructor map to Odoo's parent_id on res.partner, requiring the parent partner to be migrated first to avoid orphaned links.

Constructor deals map to Odoo crm.lead with type='opportunity'. The deal's name becomes crm.lead name, amount maps to planned_revenue, close_date becomes date_deadline, and the Constructor owner resolves to crm.lead user_id by email match. Pipeline stage values map to Odoo stage_id via a value-mapping table built during the discovery phase, preserving stage order and probability.

Constructor pipelines become Odoo crm.team records, each containing its own ordered stage sequence via crm.stage. Stage names and probabilities map value-by-value. If Constructor has multiple pipelines, each generates a separate crm.team in Odoo so the Kanban board view is scoped correctly. Team assignment on leads must resolve after the team records exist.

Constructor custom properties on contacts require Odoo custom fields to be created as ir.model.field records on res.partner before data can be loaded. The field name is derived from the Constructor property slug, and field type (char, selection, float, boolean, date) is inferred from the property value type. We generate a field-creation manifest during planning so Odoo is schema-ready before the migration run.

Constructor custom properties on deals migrate to Odoo custom fields on crm.lead. Priority, rating, or selection-type properties become selection fields with value maps defined in the field definition. Numeric properties become float fields. Text blobs become char or text depending on expected length. We validate all custom fields are created before opportunity records are written to avoid silent field-missing errors.

Constructor tasks, calls, and logged activities map to Odoo project.task records linked to the parent crm.lead via res_id and res_model='crm.lead'. Task type is set from the Constructor activity kind (call, email, meeting, note). Original create_date and write_date are preserved on the task record. Owner resolution uses the same email-match logic as all other objects.

Constructor notes map to Odoo note.note records. The note's body text and title are written to the note.note fields. If the Constructor note is attached to a specific contact or deal, the Odoo note is linked via res_model and res_id pointing to the corresponding crm.lead or res.partner record. Create and write timestamps are preserved.

Constructor file attachments are downloaded from the source platform and re-uploaded to Odoo's ir.attachment table with the correct res_model (crm.lead or res.partner) and res_id pointing to the migrated parent record. The original filename and MIME type are preserved in the attachment's name and mimetype fields. Inline images embedded in notes are extracted and stored as separate attachments.

Constructor owner_id values are resolved by matching the owner's email address against Odoo res.users records. Unmatched owners are flagged before the migration run; the team either creates Odoo user accounts first or nominates a fallback user to own unmapped records. No record lands in Odoo without a valid user_id — the migration halts on unresolved owners rather than orphaning data.

Constructor custom objects beyond the standard set map to Odoo custom models created via the Odoo framework (ir.model + ir.model.fields). The migration plan includes the model name, the target model ID, and the full field-list mapping so Odoo is configured before records are written. Associations between custom objects map to Odoo many2one or one2many relations as applicable.