Migrate from Omni.us to Pipedrive

Omni Target Accounts map directly to Pipedrive Organizations. We preserve company name, domain, and any workbook-level custom fields as Pipedrive custom fields on the Organization record. Target Account is the anchor object in this migration—all other records (Scripts, Responses, reconstructed Contacts) link back to it. We establish the Organization as the parent record before importing any Persons or activity data.

Omni does not store contacts as standalone records. We reconstruct the contact layer by extracting distinct email addresses from Response records and linking them to the parent Target Account (now Organization). Any contact email appearing in a Response without an existing Person record is created in Pipedrive. We flag contacts present in multiple Responses as potential duplicates and surface them in a reconciliation report before final import.

Omni Scripts are outreach sequence templates with placeholders and branching logic. Pipedrive has no native Script object, so we store Scripts as a custom entity or as linked documents attached to the relevant Organization or Person. We preserve full script text, placeholder tokens, and step sequence order. Branching logic is documented as a text field annotation because Pipedrive's workflow builder handles branching natively if the customer rebuilds the automation.

Omni Responses are the engagement record between a Script and a prospect. Each Response is mapped to a Pipedrive Activity—reply emails map to Note or Email activity type, manual follow-up actions map to Task, and any recorded call outcomes map to Call activity. Response timestamp migrates as the Pipedrive Activity's due_date or completed_date. We reconstruct the activity timeline against the correct Person record by tracing the Response-to-Script-to-Account relationship.

Omni Case Studies are content attachments linked to accounts or scripts. Pipedrive has no native Case Study object, so we map content to Note records attached to the relevant Organization. We preserve the title, content text, and any metadata. The customer's admin can apply a custom field (e.g., case_study_type) to distinguish case studies from general notes.

Omni Custom Workbook fields exist at schema, shared, and workbook levels. We perform a pre-migration schema audit via the Omni model IDE to enumerate every active custom field name, type, and workbook assignment. Duration fields, calculated fields, and nested properties require type mapping to Pipedrive equivalents (text, numeric, date, or dropdown). We create Pipedrive custom fields before importing any data and map them during the Organization and Person import phases.

Omni Automatic Pausing Rules govern sequence behavior based on prospect reply, bounce, or manual pause actions. Pipedrive's Workflow Automation (Advanced tier and above) supports trigger-action rules that can replicate this logic. We do not migrate rules as code. We deliver a written inventory of every Active Pausing Rule with its trigger condition, target script, and pause duration, plus a recommended Pipedrive Workflow Automation equivalent. The customer's admin rebuilds these in Pipedrive's automation builder post-migration.

Omni User records map to Pipedrive Users by email address. Role and permission structures are not natively represented in Omni, so we create baseline User records in Pipedrive without granular access control preservation. Any Omni user not yet provisioned in Pipedrive goes to a reconciliation queue for the customer's admin to set up with the appropriate seat before record import resumes.

Omni outreach sequences (the ordered set of Scripts sent over time) do not have a direct Pipedrive equivalent. Pipedrive's Sales Automation features handle individual workflow actions but not multi-step cadence sequencing. We deliver a written cadence map documenting every Omni sequence with its steps, timing, and conditions. The customer's admin rebuilds sequences using Pipedrive's Workflow Automation, a third-party sales engagement tool (such as Salesloft, Outreach, or Instantly), or a Zapier-based sequencing workaround.

Omni does not expose a dedicated Activities object in its API. Historical call logs, meeting records, and task completions that exist outside the Script-Response model cannot be queried or exported from Omni. We inform the customer of this gap during scoping and note that any activity data to be preserved must exist within a Script or Response record in Omni before migration begins. This is a structural limitation of the source platform, not a migration failure.