Migrate from Listrak to Salesforce Sales Cloud

Listrak contacts with lifecycle_stage of Prospect or Subscriber without a purchase history map to Salesforce Lead. Contacts with a defined purchase history, account association, or lifecycle_stage of Customer map to Salesforce Contact attached to an Account. We compute the split using the Listrak contact properties lifecyclestage, total_order_count, and total_revenue. The original Listrak lifecycle stage and channel subscription flags migrate as custom fields (listrak_lifecycle_stage__c and listrak_email_subscribed__c, listrak_sms_subscribed__c) on both Lead and Contact for audit and segmentation rebuild.

Listrak contacts carry a company_name property that maps to Salesforce Account Name. The Listrak company domain becomes the Account Website field and serves as the dedupe key during import. Account records are created before Contact import so that the AccountId lookup is resolved at the moment of Contact insert. Any Listrak contact without a company value is held in a reconciliation queue for the customer's admin to resolve before the contact phase runs.

Listrak mobile subscribers migrate to Salesforce Contact with mobile_number stored as Phone or a custom text field (not string or varchar). Salesforce does not have a native mobile_number field; we create a custom Text(40) field listrak_mobile_number__c to store the original phone number in E.164 format. The original SMS opt-in date migrates to listrak_sms_optin_date__c. We validate that no opted-out mobile contacts are included in the export before loading.

Listrak email suppression records (unsubscribed, bounced, complained) load into Salesforce before any active Contact import. For each suppression record we set HasOptedOutOfEmail = true and record the original suppression date in listrak_suppression_date__c and listrak_suppression_reason__c. This sequence prevents the platform from inadvertently emailing contacts who explicitly opted out in Listrak. Suppression history is preserved as a custom field on the Contact rather than a separate suppression list object because Salesforce does not maintain a native suppression list equivalent.

Listrak mobile suppression records (opted-out mobile subscribers) load into Salesforce with HasOptedOutOfMobile = true and listrak_sms_optout_date__c set to the original Listrak opt-out timestamp. Mobile suppressions are loaded before mobile subscriber import to enforce TCPA compliance. Listrak's own onboarding documentation requires written confirmation that the export list has been scrubbed of opted-out contacts before mobile data is transferred.

Listrak behavioral properties (email_open_count, email_click_count, last_open_date, last_click_date, total_order_count, total_revenue, average_order_value) migrate as custom Number, Date, or Currency fields on the Salesforce Contact object. We create fields with the naming convention listrak_<property_name>__c. These fields are populated during the Contact import phase and used to seed any post-migration segmentation or scoring logic in Salesforce Flow.

Listrak segments do not export as transferable objects. We extract the full segment filter logic for each active Listrak audience—including filter criteria (email_behavior, channel_subscription, lifecycle_stage, order_history conditions), operator logic, and time windows—and document it as a written spec. The customer's admin uses this spec to build Salesforce Campaigns or List View filters. We also create a contact-level flag field (listrak_segment_<name>__c) during migration for each segment the customer identifies as business-critical so segment membership is preserved as a data attribute even if the dynamic filter logic is rebuilt.

Listrak email templates export as raw HTML or must be manually rebuilt. We export available HTML and recommend rebuilding in Salesforce Content Builder or Marketing Cloud Email Studio rather than importing raw HTML directly, because Listrak's drag-and-drop Experience Builder is not portable and raw HTML imports often carry rendering inconsistencies. We deliver a template inventory with HTML asset files organized by template name and send-time classification for the customer's admin to rebuild in the destination editor.

Journey Hub automations (cart abandonment sequences, replenishment reminders, browse recovery, win-back flows) represent multi-step, multi-channel logic that does not export as a transferable object. We document the full automation tree: entry trigger, each step's condition, time delay, channel (email or SMS), message content reference, and exit criteria. This document is delivered as a written handoff with a recommended Salesforce Flow (for sales CRM triggers) or Marketing Cloud Engagement Journey Builder (for cross-channel lifecycle automations) equivalent for the customer's admin or implementation partner to rebuild.

Listrak custom contact properties that exist only in the UI and are not accessible via the standard API are flagged during scoping. We test each custom field's API availability in a pre-migration probe and adjust the scope to include only API-accessible fields, or create a manual extraction task for UI-only fields. Field type mapping from Listrak's property types (text, numeric, date, boolean, multi-select) to Salesforce field types (Text, Number, Date, Checkbox, Multi-Select Picklist) is defined in the schema design phase before any data moves.

Historical campaign performance data exports from Listrak as flat CSV or flat file reports on a nightly SFTP schedule. We capture the scheduled export configuration, extract all historical reports that exist before the migration cutoff date, and deliver them as organized CSV files with a data dictionary mapping each column to its source field. Salesforce Reports are not populated from this data; the historical performance files are delivered for import into a BI tool or data warehouse if the customer requires historical reporting continuity.

Listrak tracks mobile acquisition channel and keyword campaign sources for SMS subscribers. This attribution data may live in a separate export from the main contact export. We join on mobile phone number to attach acquisition_channel__c and acquisition_keyword__c custom fields to the migrated Contact record. If the acquisition source data does not export cleanly by phone number, we flag it for the customer's admin to reconcile manually post-migration.