Migrate from Factoreal to Odoo CRM

Factoreal contacts map to Odoo res.partner records. We determine partner_type (individual vs company) by checking Factoreal's contact type or company association field. If a contact is associated with a Factoreal Company record, we link it via parent_id to the corresponding partner. The Factoreal contact ID is stored in a custom field (x_factoreal_id) as a dedupe key. The original HubSpot lifecycle stage analog (if used) is preserved in a custom stage field on the partner for audit and segmentation continuity. Email, phone, address, and custom field values migrate per the field mapping defined during discovery.

Factoreal company records map to Odoo res.partner with company_type set to company. The domain name from Factoreal becomes the partner's website field and serves as a dedupe key. Companies are imported before contacts so that the parent_id lookup is satisfied at the moment of contact insert. If two Factoreal companies share the same domain, they are deduplicated and consolidated into one partner record with a note documenting the merge.

Factoreal deals map to Odoo crm.lead records with type set to opportunity. The deal name becomes the lead name, the deal amount maps to expected_revenue, and dealstage maps to the nearest Odoo stage_id via a stage mapping table built during discovery. Owner assignment migrates by email-to-user resolution. Closed-won and closed-lost status from Factoreal maps to the equivalent Odoo stage in the target pipeline.

Factoreal campaigns have no direct Odoo CRM equivalent; we reconstruct them as crm.lead records with utm_source, utm_medium, and utm_campaign fields set from the campaign name, and a tag (e.g., campaign-name) applied for grouping. Campaign send history and aggregate engagement metrics are stored as a custom field block on each lead so that individual open and click records can be referenced in reporting. This approach preserves campaign context but not the granular per-campaign engagement analytics that Factoreal's campaign dashboard provides.

Factoreal automation workflows define trigger conditions and multi-step action sequences across email, SMS, and WhatsApp channels. Odoo automated actions are scoped to single-record triggers (on-create, on-write, on-delete) and do not support the branching, delays, and cross-channel orchestration that Factoreal workflows implement. We capture the full workflow graph — triggers, conditions, delays, and actions — in a written specification document with an Odoo automated-action and Studio rule recommendation per workflow. The customer's Odoo admin rebuilds the workflow logic post-migration; we do not write Odoo automated actions as part of the migration scope.

Factoreal email templates with HTML content and merge field placeholders migrate to Odoo mail.template. We extract template HTML and convert Factoreal merge field syntax (e.g., {{contact.first_name}}) to Odoo's QWeb field interpolation format (object.partner_id.name or {{object.partner_id.name}} depending on the template engine version). Visual rendering differences between Factoreal's email builder and Odoo's QWeb renderer are documented as a post-migration review item. Static assets (logos, images) embedded in templates are exported as file attachments and re-uploaded to Odoo's document management system.

Factoreal contact tags are stored as comma-separated values in a custom Char field (x_factoreal_tags) on the res.partner record. A dedicated Odoo tags infrastructure (mail.followers or crm.tag) requires additional module installation and configuration and is not included in the base CRM migration scope unless scoped during discovery. The customer chooses between plain-text storage and a formal tag model before migration begins.

Factoreal custom fields on contact and company records require pre-creation in Odoo before their values can be imported. We identify all Factoreal custom field definitions during discovery, select the nearest Odoo field type (Char, Selection, Integer, Float, Date, etc.), create the field via Odoo Studio or XML during the schema design phase, then import values per record during the data import phase. Fields with a many-to-many relationship (e.g., a contact tagged with multiple categories) are stored as Char with comma-separated values unless the customer requests a dedicated Many2many field setup.

Factoreal SMS and WhatsApp message logs — send timestamp, direction, content, and recipient — migrate to Odoo mail.message records with a custom subtype (sms or whatsapp) so that channel history is visually distinguishable in the Odoo Discuss timeline. Delivery status from Factoreal (sent, delivered, failed) is stored as a custom field on the message record because Odoo mail.message does not expose a standard delivery status field. Inbound and outbound direction is preserved. Message content is stored as body text in mail.message.

Factoreal social campaign metrics (impressions, engagement, clicks per post) are mapped to Odoo crm.lead records with utm_source set to the social channel name and utm_medium set to social. Individual post performance is stored as a custom field block because Odoo CRM does not have a native social post performance object. The customer reviews post-level metrics in Odoo's CRM reporting by filtering on the UTM source and date range.

Factoreal order records and product SKUs migrate to Odoo sale.order and product.template only if the Odoo Sales and Inventory apps are in scope for this migration. The sale.order partner_id links to the corresponding res.partner contact; order lines map to sale.order.line with product_id, product_uom_qty, and price_unit preserved. Odoo CRM does not include order management by default, so the need for Sales app activation is confirmed during discovery scoping. If the Sales app is not activated, order and product records are excluded from migration scope with a written rationale delivered to the customer.

Factoreal segments are defined by filter rules on contact attributes and behavioral events. We export the full segment definition — name, filter criteria, and contact count at migration time — and store it as a custom text field (x_segment_notes) on each contact record that belonged to the segment. A companion Segment Definitions document lists each segment name, its rule logic, and the Odoo CRM filter or segmentation tool the admin can use to reproduce the segment in Odoo. Segments are not migrated as live segmentation rules.

Factoreal website visitor session data — page views, visit frequency, browsing behavior — is cookie-based and tied to its own JavaScript embed. Session records cannot be exported as structured data and are not portable to Odoo or any external platform. We scope this as a known gap and recommend exporting aggregate metrics manually from Factoreal's reporting UI if historical web engagement data is needed in the destination. The customer documents the aggregate figures in Odoo's custom fields or a reporting spreadsheet post-migration.