Migrate from Loyalistic to Salesforce Sales Cloud

Loyalistic Contacts map to either Salesforce Lead or Contact depending on a qualification split we compute during scoping. Contacts with an associated Deal in Loyalistic or a lifecycle stage indicating a closed business relationship map to Salesforce Contact linked to an Account. Contacts with no associated Deal and no closed-won record map to Salesforce Lead. The original Loyalistic contact ID and any enrichment provenance fields migrate as custom fields on both Lead and Contact for audit and reconciliation.

Loyalistic Customer Profiles aggregate contact details with enrichment data. We migrate the underlying contact fields 1:1 to Salesforce Contact or Lead, and attach profile-level enrichment metadata (industry signals, company size, technology stack if present) as custom fields on the Contact with a lpc_profile_ prefix. Note that enrichment provenance (source of the data enrichment) is preserved as a text field; Salesforce's native enrichment APIs (Einstein Data Enrichment, ZoomInfo, Clearbit) handle live enrichment post-migration.

Loyalistic Company records map directly to Salesforce Account. Domain and website fields transfer as-is. The Account is created before any Contact import so that the AccountId Lookup relationship is satisfied at Contact insert time. Account is the parent in the relational model; no Contact in this migration should be orphaned without an AccountId unless the Company record is absent in Loyalistic.

Loyalistic Segments define group membership based on behavioural or demographic criteria. We export segment names and the full member list (Contact ID per member) and deliver these as Salesforce Campaign records with the segment name as Campaign Name, or as CampaignMember records for existing Campaigns. The dynamic segment logic (the rules that govern membership) cannot migrate as code; we document the rule criteria for the customer's admin to rebuild using Salesforce Flow filters, Audience criteria, or Campaign inclusion rules.

Survey definitions (question text, response options) and Survey Responses are distinct objects in Loyalistic. We migrate response records into a custom Salesforce object Survey_Response__c linked to the Contact via a Lookup relationship. Question branching logic (conditional paths based on prior answers) cannot migrate and requires manual reconstruction in Salesforce as a Flow or Survey builder. Survey response metadata (submission timestamp, completion status) migrates as custom fields on the Survey_Response__c record.

Loyalistic Campaign records (title, status, timing, type) map directly to Salesforce Campaign. Campaign type, status, and start/end dates migrate as-is. Engagement events (opens, clicks, conversions) are activity-level records that we attach to the Contact in Salesforce as Task or Event records, linked via the Campaign as WhatId. The Campaign's audience is reconstructed using the Loyalistic segment member lists mapped to Campaign Members.

Loyalistic engagement data tracks opens, clicks, conversions, and other event types against contact records. We extract event-level data per contact and attach them as Salesforce Activity records: email opens and clicks migrate as Task records with a custom engagement_type__c field; form submissions and conversions migrate as Task or Event depending on whether they represent a discrete timestamped activity. All activity records link to the Contact as WhoId and to the related Campaign or Account as WhatId. Activity ordering is preserved by setting ActivityDate to the original Loyalistic timestamp.

Loyalistic Tags are flat labels applied to contacts for grouping. We migrate tag names 1:1 to a Salesforce Multi-Select Picklist field on Contact (or Lead if the contact splits to Lead). Tag names with spaces or special characters are sanitized to conform to Multi-Select Picklist value formatting. The customer chooses whether to use a Multi-Select Picklist or a separate Tag (Topics) model during scoping.

Loyalistic supports custom fields on the Contact object. We perform field-level sampling during discovery to identify all active custom properties, map each to a Salesforce custom field of equivalent type (text, number, date, picklist, checkbox), and deploy the schema to the destination Salesforce org before data migration begins. Custom field naming follows Salesforce __c conventions with a lpc_ prefix to indicate provenance from Loyalistic.

Loyalistic Report configurations define saved views and filter criteria. We migrate report metadata (name, filter fields, sort order) as a written specification document rather than migrating rendered report data as live records. Rendered report data is extracted as CSV during discovery and re-imported as a custom Salesforce Report type or as a static Reference_Object__c record that the customer's admin can rebuild as a native Salesforce Report post-migration.

Email and workflow templates exist as reusable assets in Loyalistic. We export template content (HTML body, subject line, variable placeholders) and deliver it as a specification document for Salesforce Email Template recreation. Salesforce Email Templates use a different variable syntax (merge fields like {{Contact.FirstName}}) than Loyalistic, so template recreation is a manual step for the customer's admin or marketing team post-migration. We do not rebuild templates as Salesforce Content records inside the migration scope.

Loyalistic Owner records map to Salesforce User by email address match. We extract every distinct Owner referenced across Contact, Company, Campaign, and Engagement records and match by email against the destination Salesforce org's User table. Any Loyalistic Owner without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. OwnerId is required on most standard objects, so this step gates the production migration.