Migrate from Omni.us to HighLevel

Omni Scripts (outreach sequence templates with placeholders and branching logic) do not have a direct GoHighLevel equivalent as executable records. We export the full script text, placeholder structure, and branching conditions from Omni, then deliver a written playbook describing each script's trigger, steps, delay logic, and contact action. The customer's admin rebuilds these as GoHighLevel Workflows using the playbook as a configuration guide. Script metadata (name, created date, last modified) migrates as a Custom Object record for audit purposes.

Omni Target Accounts are company-level records (company name, domain, and associated metadata) with no native Contact object attached. We map each Target Account to both a GoHighLevel Company (account-level data) and a reconstructed Contact record for each associated Response. If no Response exists for a Target Account, we create a placeholder Contact with the company name as a fallback so the account is not orphaned. The Omni domain field becomes the Company website in GoHighLevel.

Omni Responses contain reply data tied to Scripts and Target Accounts. Because Omni has no standalone Contact object, we reconstruct the contact layer by extracting respondent email, name, and company from Response records, then linking them back to the matched Target Account. Response metadata (reply date, script reference, channel) migrates as Activity records on the Contact in GoHighLevel. Any Response without a resolvable email address is flagged in reconciliation.

Omni Case Studies are content attachments linked to accounts or scripts. GoHighLevel does not have a native Case Study object, so we create a Custom Object named CaseStudy with fields for title, content, linked account reference, and linked script reference. The content text migrates as rich text. If the customer uses Case Studies frequently, we recommend a naming convention and custom layout during scoping.

Omni Automatic Pausing rules govern when outreach sequences pause based on prospect actions (reply, click, meeting booked, etc.). We translate each pausing trigger into a GoHighLevel Workflow condition. For example, an Omni rule that pauses on reply becomes a GoHighLevel Workflow with a Contact Tag Updated trigger that adds a 'Paused' tag. We document each rule's original logic and the GoHighLevel equivalent in the automation handoff inventory.

Omni supports custom fields at schema, shared, and workbook levels. We perform a pre-migration field audit against the Omni model IDE to enumerate all active custom fields and their types before migration. Duration fields, calculated fields, and nested custom properties require type translation: Omni Duration maps to Number or Duration picklist in GoHighLevel depending on usage. We build a field map during scoping and apply it before any record import.

Omni user records map to GoHighLevel User accounts by email match. Role and permission structures from Omni are limited (Omni has no granular access control), so we create baseline GoHighLevel User records with standard access. Any Omni user referenced on a Script or Response that lacks a matching GoHighLevel User goes to a reconciliation queue for the admin to provision before contact migration begins.

Omni does not expose a dedicated Activities object in its API. We cannot migrate historical engagement activity records because the platform does not persist them as queryable objects. Any engagement timeline visible in Omni is derived from Response data, which we reconstruct as Activity records during the Response-to-Contact mapping. This limitation is disclosed during scoping and documented in the migration scope agreement.