Migrate from Omni.us to Odoo CRM

Omni Target Accounts map to Odoo res.partner records in company mode. We preserve company name, domain (stored as website), and any custom workbook fields as ir.model.data fields on the partner. Odoo's res.partner model serves as both Contact and Account depending on the is_company flag, so Target Accounts set is_company=True. Address enrichment (street, city, country) is attempted from domain-based lookups where available; missing fields are flagged in the reconciliation report.

Omni has no native Contacts object, so we reconstruct the contact layer by extracting respondent email addresses and names from Response records and associating them with the parent Target Account partner. Multiple responses from the same email address deduplicate to a single res.partner contact record. The original Omni Script association is preserved in a custom field script_reference__c for audit. Contacts without an associated Target Account are created as standalone partner records flagged as orphan=True in a custom field.

Omni Scripts are outreach templates with placeholders and branching logic that has no direct Odoo equivalent. We extract the full script text, placeholders, and step sequence and write them as a custom Text field script_template__c on crm.lead. The customer's Odoo admin assigns script content to new leads or uses it as a manual reference in follow-up activities. Script step sequencing and branching are not converted to automation; we document the structure in a written script inventory so the admin can rebuild it as a mail.activity plan or stage-based template if needed.

Omni Case Studies are content attachments linked to accounts or scripts. We export the text content, title, and metadata and write them as Odoo ir.attachment records linked to the corresponding res.partner via res_model='res.partner' and res_id pointing to the Target Account partner. Odoo does not have a native Case Study object, so the generic attachment model is the correct equivalent. PDF or document attachments are stored as binary attachments with the original filename preserved.

Omni Responses represent reply data tied to scripts and accounts. We map each Response to an Odoo mail.message record attached to the parent crm.lead (if the respondent was linked to a lead) or to the res.partner contact record. Response text, timestamp, and disposition status migrate. If the destination Odoo instance includes the Discuss (mail) module, messages appear in the chatter on the partner or lead record. Response records without a resolvable parent contact are attached to the corresponding Target Account partner and flagged as unmatched_response=True.

Omni Automatic Pausing rules govern when outreach sequences pause based on prospect actions (reply, bounce, opt-out). These are not automation code and do not migrate as Odoo server actions. We audit every active Automatic Pausing rule, document its trigger condition, action type, and target script, and deliver a written specification recommending equivalent Odoo mail.activity.plan entries and ir.actions.server rules. The customer's Odoo admin implements the recommended rules post-migration; we do not write automation code as part of the standard migration scope.

Omni's workbook-layer custom fields require schema discovery via the model IDE before migration. We enumerate all active custom field definitions (name, type, workbook scope) and create equivalent ir.model.field records in Odoo on the target model (res.partner or crm.lead). Duration fields, calculated fields, and nested custom properties are mapped to Odoo field types (Float, Integer, Char, Text, Selection) based on type analysis. Fields that cannot map directly (e.g., Omni Duration with branching logic) are documented in the field mapping appendix with a manual resolution recommendation.

Omni user records map to Odoo res.users. We resolve by email match against the destination Odoo instance. Any Omni user without a matching Odoo res.users record is placed in a reconciliation queue for the customer's admin to provision before record import resumes. Role and permission structures in Omni are limited, so we create baseline User records without granular access control preservation and flag this gap in the handoff documentation.

Omni has no native pipeline or deal stages. We create a default Odoo CRM pipeline with stages New, Qualified, Proposition, Won, and Lost, which are the Odoo CRM default stages. If the customer used Omni script status as a de facto pipeline proxy (e.g., Active, Paused, Completed, Cancelled), we map those statuses to crm.stage entries with matching sequence order and name. Lost reason configuration (lost_reason_id) is enabled on the stage form for post-migration rep entry.

Omni records timestamps for script sends, response receipts, and pausing events. We migrate these as mail.message records with a tracking field timestamp referencing the original Omni UTC timestamp. This preserves the activity timeline ordering in Odoo's chatter even though the engagement type is not a native Odoo activity. Historical timestamps are preserved to the second where available from the Omni API response payload.

Omni Target Account tags (e.g., Industry, Tier, Segment labels) map to Odoo res.partner.category records (the Tags model on partners). We extract distinct tag values from the source workbook, create matching res.partner.category entries, and assign them to the corresponding res.partner records during import. Tag rename or consolidation (e.g., two tags meaning the same thing) happens during the pre-migration data-cleanse phase.

Omni script steps carry metadata such as step order, delay between steps, channel (email/LinkedIn), and conditional branches. We extract this as a JSON blob stored in a custom Text field script_steps__c on crm.lead, preserving the full step metadata as a reference document. This is not rendered as Odoo activities or automation; it is a data-preservation pass so that the customer has the original sequencing information available for manual workflow reconstruction.