Migrate from Omni.us to Twenty CRM

Omni Target Accounts map directly to Twenty Companies. We preserve company name, domain, and any workbook-level custom fields as Twenty Company custom fields. The domain field becomes the Company website URL. Target Accounts with no name but a valid domain are flagged during scoping for manual review before migration. Parent-account hierarchy, if modeled in Omni, maps to Twenty's self-referential Company relationship field.

Omni Scripts contain the full outreach sequence text, placeholders, and branching logic. Since Twenty has no native Script or Sequence object, we migrate script content as Note records linked to the relevant Company or Contact. The Note title carries the script name; the Note body carries the full text. For scripts with branching logic, we document the branching structure in the Note and flag it for the customer's admin to rebuild as a Twenty workflow if needed. Placeholder variables are preserved as bracketed tokens in the Note body.

Omni Responses are the primary mechanism for reconstructing the contact layer. Each Response is tied to a Script and a Target Account. We extract any email address, name, phone, or company data from the Response payload, create a corresponding Twenty Contact record, and attach the Response content as a Note linked to that Contact. Responses that contain no identifiable contact information are attached as Company-level Notes. We run a deduplication pass on extracted email addresses to avoid creating duplicate Contact records. Responses with no associated script are flagged separately.

Omni Automatic Pausing rules govern outreach sequence pauses based on prospect actions. Twenty does not have an equivalent automated pausing feature in its workflow engine at this time. We document each Automatic Pausing rule in a written inventory that includes the trigger condition, the pause action, the affected script, and a recommended Twenty workflow equivalent using Twenty's available trigger and action types. The customer's admin rebuilds these manually in Twenty's workflow builder post-migration.

Omni Case Studies are content attachments linked to accounts or scripts. Twenty has no native Case Study object, so we migrate Case Study content as Note records linked to the associated Company. The Note title carries the Case Study name; the body carries the content and metadata. We flag Case Studies that reference external URLs or file attachments separately for manual re-upload because Omni's attachment storage requires API-based retrieval not covered by standard CSV export.

Omni's three-layer modeling (schema, shared, workbook) means custom fields can exist at different abstraction levels. We perform a pre-migration schema audit via the Omni model IDE to enumerate all active custom fields, their types (text, number, date, duration, checkbox, dropdown), and the object they are attached to. Duration fields and calculated fields require type mapping to Twenty field types. Nested custom properties are flattened to top-level custom fields in Twenty. We build a custom field map before writing any records and validate field type compatibility against Twenty's supported field types.

Omni user records map to Twenty User accounts. We extract user email addresses, names, and any associated owner IDs from Omni. Role and permission structures in Omni are minimal and do not have a direct Twenty equivalent, so we create baseline User records with standard access and flag permission configuration for the customer's admin to set post-migration. Users referenced as owners on Target Accounts or Scripts are mapped to the Twenty User by email match.

Response metadata in Omni—reply status, reply date, channel type, and engagement indicators—does not map to a native Twenty object. We migrate these as custom fields on the reconstructed Contact record (e.g., first_response_date__c, last_reply_date__c, reply_channel__c). These fields enable the customer's team to preserve engagement context without rebuilding from scratch in Twenty. Fields are created during schema setup and populated during the contact import phase.

Omni script placeholders (e.g., {{first_name}}, {{company_name}}, {{custom_field}}) are variable tokens that get populated at send time. We extract any placeholder names that reference custom fields or data points not present in the standard Response payload and create corresponding custom fields on the Contact or Company object in Twenty. This ensures that if the customer wants to re-use scripts in Twenty or a connected outreach tool, the required data fields exist on the record.

File attachments associated with Omni Case Studies and Scripts are not included in Omni's CSV export. We retrieve attachment metadata and content via the Omni API where available and upload them to Twenty as linked Attachments on the relevant Note or Company record. If an attachment URL is broken or the file is inaccessible via API, we flag it for manual re-upload by the customer's admin and document the complete list of flagged files in the migration report.

Omni does not expose a dedicated Activities API object, meaning historical engagement records (opens, clicks, replies, meetings logged outside of scripts) are not queryable for migration. We document this gap in the migration report and note that teams should continue using Omni or their email platform for historical activity lookups. Any response-level data that can be extracted (reply timestamps, channel indicators) migrates as custom fields on Contact as described above. Future activity tracking begins in Twenty from the cutover date.

Omni has no Deal or pipeline concept. We create a default Opportunity pipeline in Twenty with standard stages (Prospecting, Qualification, Proposal, Negotiation, Closed Won, Closed Lost) and configure it before migration. If the customer has pipeline expectations from their outreach work (e.g., stages based on reply rate or meeting set), we map these to the Twenty Opportunity stages during scoping. The Opportunity object provides the deal tracking capability that Omni entirely lacks.