Migrate from RedEye to Odoo CRM

RedEye's unified Contact record maps to Odoo CRM's Contact object as the primary record. Company linkage from RedEye (where present) maps to Odoo Account. For RedEye contacts with no company association, we infer an Account from the contact's domain using a domain-extraction rule during import, creating a linked Account record so that Odoo's CRM Opportunity lookups can reference it. The RedEye contact identifier is stored in the Odoo contact's external_id field for reconciliation. Custom contact properties from RedEye migrate as Odoo IrModelField custom fields on res.partner.

RedEye company records (lighter-weight in B2C context) map directly to Odoo res.partner records with partner_type = 'company'. The RedEye company name becomes the Account name and the domain becomes the Website field. Account is created before any linked Contact import so that the contact_id.partner_id lookup is satisfied at the moment of insert. If the source RedEye account has no company records, we skip this object and rely on the contact-to-account inference in the Contact mapping.

RedEye campaigns migrate as Odoo CRM tags (crm.lead.tag) with the campaign name as the tag label. Campaign timing rules (start date, end date, goal metrics) are documented in a campaign inventory spreadsheet rather than a native Odoo campaign object, since Odoo CRM does not have a native multi-channel campaign scheduler. The customer's admin assigns tags to Opportunities and Contacts post-migration for campaign attribution. Channel assignments from RedEye (email, SMS, push) require manual reconfiguration in Odoo's marketing automation modules or third-party tools.

RedEye journey logic (visual branching rules tied to contact behaviour and lifecycle stages) does not have a direct Odoo CRM equivalent. Odoo CRM has no native visual journey builder. We extract the full journey tree from RedEye as a structured rule document listing every trigger condition, branch, delay, and CRM action. We deliver this document to the customer's admin, who rebuilds equivalent logic in Odoo Studio, via a third-party Odoo marketing automation app, or in a standalone tool like Mautic if marketing automation is separated from the CRM layer.

RedEye behavioural events (website actions, email opens, purchase triggers) migrate as Odoo mail.message records linked to the parent res.partner Contact. Event type, timestamp, and source channel are stored in custom fields on the message record. Event volume can be significant for high-frequency senders, so we chunk the event migration into batches of 1,000 records per API call and validate record counts against the source export. Events without a resolved parent contact are flagged in the reconciliation report and held for manual resolution.

RedEye product catalogue records (SKU, name, pricing, category) migrate to Odoo product.product. ProductCode maps from RedEye's SKU field. Pricing migrates to lst_price (sales price) and standard_price (cost). Category maps to Odoo product.category via a name-match lookup. Unlimited product records migrate on both RedEye tiers; Odoo has no product count ceiling.

RedEye custom contact fields and custom event fields require explicit field-to-field mapping during scoping. We extract the full field schema from RedEye and match it against Odoo's field type model (char, integer, float, selection, many2one, etc.) before destination schema creation. Custom fields are deployed as Odoo IrModelField records via the XML-RPC API before any data import begins. Fields without a direct Odoo type equivalent (e.g., multi-value arrays) are stored as char fields with delimiter-separated values or as Odoo tag associations.

RedEye dynamic segments (behavioural rules and demographic criteria) migrate as Odoo CRM tags on the Contact record plus an Odoo domain filter stored as a custom char field describing the segment logic. The domain filter describes the rule rather than re-executing it, since Odoo CRM does not have a native dynamic segment engine. We document every segment definition in a segmentation inventory with its criteria, logic, and recommended Odoo equivalent (static tag, sales team filter, or campaign audience).

Contact and campaign tags from RedEye migrate as Odoo crm.lead.tag records. We map tag names exactly and flag any tag characters (special characters, spaces, non-ASCII) that are unsupported by Odoo's tag schema. Tags are linked to both Contact and Lead records post-migration, depending on whether the contact was mapped to a Contact or an Account.

Campaign assets (images, documents) attached to RedEye campaigns or emails migrate via file export and re-upload to Odoo's ir_attachment table. We preserve the file hierarchy and naming conventions to minimise manual re-linking in Odoo's document management view. Odoo's document management module (documents app) can be enabled if the customer requires a more structured asset library post-migration.

RedEye native reporting dashboards do not export because the visualisation components are platform-specific. We migrate all underlying data (contact attributes, event logs, campaign performance metrics) to Odoo so reports can be rebuilt from scratch. We flag this during scoping so the customer allocates time for the reporting rebuild phase in Odoo Reporting or in a connected BI tool. A reporting inventory document listing every source metric and its Odoo equivalent is included in the migration deliverables.

RedEye owners (sales and marketing team members with campaign access) map to Odoo res.users records. We resolve owners by email match. Any RedEye owner without a matching Odoo User is held in a reconciliation queue for the customer's admin to provision before record import resumes. Inactive Odoo users are created for historical owners who are no longer active so that owner attribution on historical records is preserved.