Migrate from Levitate to Salesforce Sales Cloud

Levitate's single Contact object maps to a Salesforce split: Contacts that represent qualified prospects with a business relationship map to Salesforce Contact tied to an Account; Contacts representing early-stage or unsourced prospects map to Salesforce Lead. We determine the split using Levitate's Tag taxonomy (contacts with tags indicating active client or policyholder map to Contact under Account; untagged or inquiry-tagged contacts map to Lead) and any Levitate owner assignment data. The original Levitate contact ID is preserved in a custom field levitate_contact_id__c on both Lead and Contact for audit and reconciliation.

Levitate Tags are the primary segmentation mechanism and drive automation triggers. We map the full tag taxonomy to Salesforce multi-select picklist fields on Contact and Lead. During scoping we confirm whether the customer wants tags consolidated into a single Levitate_Tags__c multi-select field or distributed across multiple semantic fields (e.g., Policy_Type__c, Client_Segment__c). Tags that represent automation enrollment state (e.g., enrolled_in_renewal_sequence) are flagged as requiring separate handling since Salesforce automations do not inherit this state automatically.

Levitate Key Dates (birthday, renewal_date, policy_expiration, and any custom age milestones) are a Levitate-specific field type that drives date-triggered automations. We create equivalent custom date fields in Salesforce (e.g., Birthday__c, Renewal_Date__c, Policy_Expiration_Date__c) before import. These fields are populated during migration but do not trigger Salesforce automations — Salesforce Flow requires explicit scheduled triggers rather than date-field-change events. We document every Key Date field and recommend the customer's admin set up Salesforce Flow scheduled triggers on these dates post-migration.

If Levitate contacts carry a Company field, we create Salesforce Account records for every distinct company value and resolve the AccountId on the mapped Contact during import. Levitate does not have a standalone Company object — company data lives as a property on the Contact record. We extract unique company values, deduplicate, and create Account records before Contact import so that the lookup relationship is satisfied at insert time.

Levitate Campaigns track email sends to segments with aggregated engagement stats (open rate, click rate, reply rate). We migrate campaign metadata and engagement aggregates as Salesforce Campaign records. The contact-to-campaign membership migrates as CampaignMember records linking the migrated Contact or Lead to the Campaign. Individual email performance logs (per-contact open and click timestamps) are not available in Levitate's export and are not migrated — only aggregate campaign stats transfer.

Levitate tracks email engagement events per contact per campaign. We migrate available engagement data as Salesforce Task records with a custom engagement_type__c field (EMAIL_OPEN, EMAIL_CLICK, EMAIL_REPLY) and ActivityDate set to the original Levivate timestamp. The most recent engagement date per contact migrates as a contact property (Last_Email_Engagement_Date__c). Raw per-event logs are not available via Levitate's export and are not migrated.

SMS message history is stored per contact in Levitate but export capability is limited to the contact's recent message thread view. We migrate available SMS logs as Task records with TaskSubtype = SMS and a custom sms_content__c field holding the message body. Long message threads that exceed Levitate's UI display limit may be truncated in export. We flag any SMS records that appear incomplete for the customer's review.

Levitate contact profile notes migrate as Salesforce Note records linked via ContentDocumentLink to the parent Contact or Lead. Note body preserves rich text formatting where present in the export. Profile notes are requested directly from Levitate Support since they are not available in the self-serve contact CSV export.

Levitate Owner records map to Salesforce User by email match. We extract every distinct Owner referenced on Contact, Campaign, and engagement records. Owners without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before record import resumes. Role and permission scope data is not available in Levitate's export and is flagged as requiring manual configuration in Salesforce.

Levitate automations themselves are server-side workflow definitions that cannot be exported as portable JSON. We preserve enrollment state (which contacts are currently enrolled in which automations) as custom boolean or multi-select picklist fields on Contact (e.g., Enrolled_In_Renewal_Sequence__c). This allows the customer's admin to re-enroll contacts in rebuilt Salesforce Flow automations without manual tagging.

We extract available automation template content (email subject, body text, delay durations, conditional branch logic) as a written inventory document. This is not migrated as executable code. The customer's admin or a Salesforce partner uses the inventory to rebuild equivalent automations in Salesforce Flow post-migration. Email template bodies migrate as Salesforce Email Template records during this inventory phase if the customer wants to reuse the content in Salesforce.

Levitate's Clio and Vertafore integration configurations (OAuth tokens, sync direction, field mappings) are stored server-side and not accessible for export. We deliver a written inventory of the active integration configurations for the customer's IT team to reconfigure in Salesforce using equivalent AppExchange apps (Clio for Salesforce, Vertafore AMS360 connectors) post-migration. This inventory is scoped during discovery.