Migrate from Reach to Odoo CRM

Reach Contact records map to Odoo res.partner with partner_type set to contact. We capture every column from the Reach CSV export during extraction and validate each against the baseline Reach contact schema. Any column not matching a known standard field (name, email, phone, address) is treated as custom and mapped to an Odoo custom field on res.partner created before import. Email addresses serve as the primary dedupe key. If a Reach contact contains company information in a company_name column, we extract that as a separate Company record first so the Contact can reference it via parent_id.

Reach does not document a distinct Company or Account object; company data is likely stored as properties on Contact records. We identify company_name, company_domain, company_phone, and similar columns during extraction, de-duplicate the unique company values, and create Odoo Company partners first. The Reach Contact records are then imported as Contact-type partners with parent_id pointing to the merged Company partner. This preserves the relationship structure in Odoo that Reach stored implicitly.

Reach label columns from the export map to Odoo res.partner.category records. We extract every unique tag value from the export, create the corresponding Odoo tags before partner import, and populate the tag many-to-many relationship on each partner record during import. If tags contain hierarchical information (e.g., carrier:geico, segment:vip), we store them as plain tags and recommend the customer build a structured custom field in Odoo Studio post-migration if needed.

Reach's custom property model is not documented, so we discover it at export time by comparing the full column set of each customer export against a baseline Reach contact export. Each non-standard column becomes an Odoo custom field on res.partner with an appropriate field type (char, selection, date, float, boolean). We create the custom fields in Odoo Studio before migration begins, then map each Reach column to its corresponding custom field during the partner import phase.

Reach supports playlists and screen management tied to contacts or accounts, but no structured export for media files exists in available documentation. Where a manual Reach export produces file attachments or media URLs, we attach them to the nearest Odoo res.partner record using Odoo's ir.attachment model. If exported files are unavailable (no manual export completed within the 7-day expiration window), media content is documented as not migratable and flagged for manual re-upload post-migration. Odoo Documents can manage these assets at scale if the customer enables the Documents app alongside CRM.

Reach Enterprise tier documents a seat-license model with reassignable admin accounts. User records (name, email, role status) migrate to Odoo res.users. We resolve by email match against the destination Odoo instance. Any Reach owner without a matching Odoo User goes to a reconciliation queue for the customer's admin to provision before partner import begins. Active and inactive status maps directly; archived Reach users become Odoo portal users if the customer wants external access, or remain inactive if the seat is no longer in use.

If the Reach customer has been using any deal or pipeline-like data (deal name, stage, amount, close date, owner), we map these to Odoo crm.lead as Opportunities. The Reach pipeline column maps to an Odoo sales team (crm.team), and the stage column maps to an Odoo stage within that team's pipeline. We create the Odoo pipeline stages and sales teams before migration. Closed-won and closed-lost reasons map to Odoo's Lost Reason and Won Reason fields. If no pipeline data exists in the Reach export, this object is skipped and the migration scope is confirmed as contact-only.

If the Reach export includes a notes or comments column, we import those as Odoo note.note records linked to the corresponding partner. Long-text note content that exceeds Odoo's default note field limit is stored as a separate attachment on the partner record. If notes were exported as separate files rather than inline columns, each file becomes an ir.attachment linked to the partner.

The Reach export documentation makes no mention of activity history, but some customers may have tracked calls or tasks in a custom field or related table. We check every exported column for date, duration, call_disposition, or task_status patterns during extraction. Any activity-like data discovered is mapped to Odoo project.task records with the appropriate subtype (call, task) and linked to the parent partner via res_id and res_model. Activity timelines in Odoo appear on the partner form view, preserving the historical record for sales reps.

Reach supports multi-currency for international payment workflows, and if deal amounts were recorded in multiple currencies, we preserve the original currency symbol on the Odoo Opportunity amount field. Odoo's multi-currency feature must be enabled in settings before import; we coordinate with the customer's Odoo admin to activate it and ensure the appropriate currencies are installed in the res.currency table.

If the Reach customer has been managing products or service offerings within Reach (not just contact management), we import those records as Odoo product.template entries. Product name, SKU, list price, and cost map directly. Products are imported before Opportunities so that Opportunity lines can reference them via the product_id field. If no product data exists in Reach, this object is skipped.

If the Reach customer has been capturing inbound leads or contacts from web forms, these may be stored as Reach Contacts with a specific tag or lead status field. We identify lead-type contacts during scoping by checking for lead_source, lead_status, or similar columns in the export. These records are imported as Odoo crm.lead with type = lead (as opposed to Opportunity which uses type = opportunity) so they enter the Odoo sales funnel at the unqualified stage. The customer's admin assigns the lead qualification workflow post-migration.

Reach has no documented integration endpoints, webhook documentation, or third-party connector schema. We treat integrations as out of scope. Any Odoo integrations the customer wishes to build post-migration use Odoo's XML-RPC or REST API and are scoped separately from the migration project.