Migrate from Highrise to Odoo CRM

Highrise's flat People object must be split against Odoo's lifecycle model. People with active Deals attached, or tagged with qualification markers (e.g., customer, client, active), map to Odoo res.partner Contact records linked to an Account. All remaining People map to Odoo crm.lead records. We determine the split rule during scoping by analyzing deal association, tag patterns, and the customer's business definition of a qualified contact. The original Highrise contact name, email, phone, address, and social links migrate directly. Notes and email history attached to each People record migrate as mail.message records via Odoo's mail.thread interface on the target record.

Highrise Companies (Parties with company_type=company) map directly to Odoo res.partner records with company_type=company. We resolve the party-contact association using Highrise's partymember relationship and create the Odoo Account before any linked Contact records insert, satisfying the contact_id foreign key. Company address, domain (for Website field), and any custom fields migrate as Odoo partner fields or custom fields via Odoo Studio.

Highrise Deals migrate to Odoo crm.lead records with type=opportunity and the pipeline_stage mapped to Odoo's stage_id. The TXT export parsing extracts deal name, stage label, monetary value, responsible user, and linked party. Value transfers to Odoo's expected_revenue field. Odoo's crm.lead team_id maps from the Highrise deal owner. If the customer uses Odoo multiple pipelines (crm.team), the deal's pipeline determines the team assignment. Closed-Lost and Closed-Won status from Highrise map to Odoo's probability=0 and probability=100 with stage_id set to the corresponding Lost/Won stage.

Highrise Cases map to Odoo project.task records. Cases linked to a Highrise Deal can optionally migrate as task records within a project created from the Deal, preserving the deal-task hierarchy. Cases without a deal link migrate as standalone tasks in a generic Support project. Case status (open, resolved, archived) maps to Odoo task stage_id. We parse the TXT Case export to extract title, description, status, and linked party, and migrate any embedded task assignments to Odoo user_ids on the task.

Highrise Tasks with a due date, assignee, and linked party migrate to Odoo calendar.event records (for time-bound meetings or calls) or project.task records (for to-do items). Completed status maps to Odoo stage_id completion. Tasks without a linked party migrate to a generic internal project. We preserve the original due date as Odoo's date_deadline and assignee as user_ids by resolving the Highrise owner email against Odoo res.users.

Highrise Recordings (notes and emails) link to People or Companies. We migrate them as Odoo mail.message records attached via mail.thread to the target crm.lead or res.partner record. HTML formatting is stripped from emails during TXT parsing, so plain-text body migrates as mail.message body. Author (Highrise user) resolves to Odoo res.users by email match. The original recording date becomes mail.message date. Attachments (if any exist in Highrise's 5-100 GB storage cap) migrate as ir.attachment records linked to the same mail.message.

Highrise's flat tag system (applied to People, Companies, Deals, and Cases) maps to Odoo's res.partner.category (for contact tags), crm.tag (for lead/opportunity tags), or mail.message.tag (for activity-level tags). We detect all unique tag values during scoping and create the corresponding Odoo tag records before migration. The many-to-many relationship is preserved via Odoo's standard tag_ids fields on res.partner and crm.lead. Customers choose tag strategy during scoping based on whether they prefer a flat tag namespace or scoped per object type.

Highrise custom fields on People, Companies, and Deals export via the custom_field_subjects API endpoints. We detect all custom field definitions (name, type, applicable object) during scoping, then provision matching custom fields in Odoo via Odoo Studio before migration. Field types map to Odoo field types (char, selection, relational, date, float). For custom fields on Deals that hold structured values like dropdown selections, we create Odoo selection fields with the same option set.

Highrise Users export with name and email. We resolve each Highrise owner by email against the Odoo res.users table in the destination instance. Any Highrise Owner without a matching Odoo User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Owner-based Deal assignments (Highrise responsible_user) map to Odoo user_id on crm.lead.

Highrise's deal pipeline stages (typically New, Contacted, Qualified, Won, Lost) map to Odoo crm.stage records within the destination crm.team pipeline. We extract the full stage configuration during scoping and create Odoo stages with matching names, probability percentages, and sequence order. Stage probability maps to Odoo's stage_id probability field. The pipeline kanban layout is configurable in Odoo Studio post-migration.

Highrise SMS conversations linked to contacts retrieve via the contact recording history API. We capture message text and timestamp and insert as Odoo mail.message records on the target res.partner, with subtype comment to distinguish from email. Odoo's SMS gateway integration is outside migration scope; the messages appear as a plain activity log in the partner's chatter.

If the customer uses Highrise Products linked to Deals (product name and price associated with a deal line item), we migrate product.product records into Odoo with name, list_price, and standard_cost. Price Book entries are not applicable in Odoo's base CRM; product pricing is set directly on the product record and referenced in crm.lead.quote_ids if the customer enables Odoo Sale Quotation workflow.