Migrate from Listrak to Twenty CRM

Listrak Contacts map to Twenty People. We extract email address, full name, opt-in status, opt-in date, and lifecycle stage from Listrak's unified contact profile. Behavioral data (last click, last open, purchase history reference) migrates to custom fields on the Person record. We preserve the original opt-in timestamp in a custom field listrak_opt_in_date__c for compliance audit. The contact's email address is the dedupe key during import.

Listrak Mobile Subscribers map to Twenty People with a mobile_number__c custom field. Listrak requires explicit written confirmation that the export list has been scrubbed of opted-out contacts before mobile export—any opted-out contact in the file will import as active into Twenty. We validate this condition before processing mobile loads and surface any records with ambiguous opt-in status for manual review. Phone numbers must be stored as text (not numeric string) to avoid truncation of leading zeros and country codes.

Listrak Companies (if used) map directly to Twenty Company. We extract company name, domain, and address fields. Company name is the dedupe key; domain becomes the Website field. Listrak does not have a formal Company object for all accounts—some deployments store company data only within Contact records. We audit the Listrak account to determine whether Companies exist as separate records or as embedded contact properties and adjust the migration scope accordingly.

Listrak Suppression and Unsubscribe Lists export separately from active contacts. We load suppressions into Twenty first by setting a custom boolean field opt_out__c = true on the matching Person record, or by setting an email opt-out custom field if Twenty supports it at migration time. This prevents the platform from sending to opted-out addresses after cutover. Suppression loading must complete before any active contact import to guarantee compliance posture is intact at cutover.

Listrak Segments filter by email behavior, SMS engagement, and channel subscription status. We map these filter definitions to Twenty custom picklist fields on Person (segment_email_activity__c, segment_sms_status__c) and create corresponding Views in Twenty filtered to match each Listrak segment. Segment names migrate as picklist values; filter criteria are documented as a written mapping for the customer's admin to configure as Twenty Views post-migration.

Listrak supports custom contact properties but not all are accessible via standard export—some fields exist only in the UI and require API enumeration to identify. We flag which custom fields appear in the Listrak API versus only in the UI and adjust the migration scope to include API-accessible fields. Fields that are UI-only are documented with a data request note for manual extraction or API script pre-migration. Custom fields in Twenty must be created in Settings → Data Model before the CSV import runs because the import creates records, not fields.

Listrak email templates export as raw HTML or must be manually rebuilt in the destination's editor. We do not import raw HTML templates into Twenty because Twenty does not have a native email template builder. We export the HTML and document the template structure (header, body, footer, CTA blocks, imagery) as a written handoff with recommendations for rebuilding in the customer's chosen email sending tool (e.g., Klaviyo, Postmark, SendGrid) that integrates with Twenty.

Listrak Journey Hub automations (cart abandonment, replenishment, browse recovery sequences) represent complex multi-step, multi-channel logic that does not export as a transferable object. We document the full automation tree—triggers, conditions, time delays, channel sequence (email → SMS → push), and exit criteria—for each active Journey. The customer's admin rebuilds these in their chosen automation tool post-migration. This documentation delivery is included in the migration scope; the rebuild itself is outside scope.

Listrak's historical campaign performance data exports as flat CSV files on the nightly SFTP schedule. We capture the scheduled export configuration and extract all historical reports that exist before cutover. We deliver these as a named archive (campaign_history_[date].csv) rather than importing them into Twenty, which does not have a native campaign analytics object. The customer's BI team or data warehouse integrates these CSV files as needed.

Listrak tracks acquisition channel and keyword campaign sources for mobile subscribers. This attribution data may live in a separate export joined on mobile number. We extract acquisition_source__c (keyword, campaign, referrer) and preserve it as a custom field on the corresponding Person record during mobile subscriber migration. If the acquisition source export requires a separate join, we include it in the mobile migration phase and flag any unmatched records for reconciliation.

Listrak engagement records (calls, emails, meetings, tasks, notes) from the unified contact timeline can be mapped to Twenty Task and Note records. We link each activity to the corresponding Person record by email match. TaskSubtype = Call for call records; Task for task records; Note for freeform notes. Activity timestamps preserve the original Listrak timestamp for timeline ordering. Engagement data volume determines whether we use the Twenty GraphQL API batch endpoint or CSV import for this phase.

Listrak Owner records (assigned contacts, campaigns, and journeys) map to Twenty WorkspaceMembers. We match by email address. Any Listrak Owner without a matching Twenty WorkspaceMember is held in a reconciliation queue—Twenty requires users to be invited and to accept their invitation before Owner lookups can be resolved during import. We flag this dependency and coordinate with the customer's admin to provision missing users before record import begins.