Migrate from Levitate to Twenty CRM

Levitate Contacts map directly to Twenty People. The primary fields (name, email, phone, company, address) migrate 1:1. Custom fields from Levitate (including the 25 maximum) map to Twenty custom fields pre-created in Settings > Data Model before import. We handle the Levitate Key Date field type separately — these are custom date fields that must exist in Twenty before the People import so that dates land as typed fields rather than text. Contact notes migrate as Note records linked to the People record via ContentDocumentLink.

Levitate stores company data as properties on the Contact record rather than as a standalone object. We extract distinct company names during the contact export transform, deduplicate them, and import them as Twenty Company records before the People import. Company becomes the parent of the related People record via the workspaceKey field on People.

Levitate Tags are the primary segmentation mechanism driving automation triggers and contact filtering. We preserve the full tag taxonomy by mapping each distinct tag value to a Twenty multi-select picklist option on the People object. Tag assignments on each contact migrate as selected picklist values. This preserves the segmentation logic at the field level so that Twenty's filter and grouping features work against migrated tags without rebuilding the taxonomy.

Levitate Key Dates (birthday, policy renewal, custom age milestones) are a Levitate-specific field type driving date-triggered automations. These are not a native object in Levitate — they are custom date fields attached to contacts. We flag each Key Date field during the discovery scan, create equivalent custom date fields in Twenty's Data Model, then import date values against the correct People record. If Key Dates are not pre-created in Twenty before import, dates land as plain text fields that cannot trigger automations.

Levitate Campaigns track groups of emails sent to a segment with aggregate engagement stats (opens, clicks, replies) stored per campaign. We migrate campaign metadata as Twenty Opportunity records with campaign-type naming, and aggregate engagement counts stored as custom number fields on the Opportunity. Individual email performance migrates as Task records with engagement notes in the description field. Customers wanting full campaign analytics post-migration should plan for a reporting rebuild in Twenty.

For each Levitate Campaign, we create a Twenty Opportunity record (the campaign as a named sales effort) and one or more Task records capturing the aggregate open/click/reply counts. This gives sales teams a timeline entry showing campaign activity without requiring them to cross-reference a separate analytics tool.

Levitate automations are server-side workflow definitions that cannot be exported as portable JSON. We extract the enrollment state — which contacts are currently enrolled in which automations — and preserve it as a multi-select picklist value or custom text field on the People record listing each active enrollment. This gives the customer and their admin a record of automation history without migrating the automation logic itself. We deliver a written automation inventory listing each automation's trigger conditions, conditions, delays, and email steps for manual rebuild in Twenty.

Levitate email engagements (opens, clicks, replies) are tracked per contact per campaign but the raw event log is not bulk-exported. We capture the last engagement date and aggregate counts as contact-level custom fields during the export. If detailed email logs are available via Levitate Support, they migrate as Task records linked to the People record. Email content sent via Levitate campaigns migrates as Note records attached to the relevant People or Opportunity.

Call and meeting logs stored in Levitate migrate as Twenty Task records with the task type set to Call or Meeting, ActivityDate set to the original timestamp, and any disposition or notes preserved in the Task description. Duration and attendee information migrate as custom fields on the Task record.

Levitate contact profile notes migrate as Twenty Note records linked to the relevant People record via ContentDocumentLink. Note body migrates as rich text. Contact profile notes are not available in the self-serve Levitate CSV export — we request them from Levitate Support directly as part of the discovery engagement.

SMS message history is stored per contact in Levitate but the export capability for SMS logs is limited to the contact's recent message thread view. We migrate available SMS logs as Task records with the SMS direction (sent/received), timestamp, and content preserved in the Task description. Long message threads that exceed Levitate's thread view export limit are partially migrated.

Levitate user accounts (owner, admin, member roles) are listed during discovery, but role definitions and permission scopes are not exportable. We map the primary owner and active user list to Twenty Members. Twenty requires that users be invited and accept their invitation before OwnerId references can be mapped during record import — we provision this sequence during the migration setup phase so that user references resolve at import time.

Levitate custom fields attached to contacts (up to 25 per account) map to Twenty custom fields on the People object. If the customer has data that logically belongs in a separate Levitate object (e.g., policy records, client assets), we create equivalent Twenty Custom Objects during the schema design phase, pre-create the fields in Settings > Data Model, and import via the Twenty REST API. Custom object relationships (lookups to People or Company) require the parent record to exist first.

Levitate's industry-specific integrations with Clio, Vertafore, and AMS360 sync contact and account data with practice management systems. Integration configuration (OAuth tokens, sync direction, field mappings) is stored server-side and not exportable. We deliver a written inventory of each active integration with its connection details, data flow direction, and field-level mapping for the customer's admin to reconfigure post-migration. There is no automated migration path for OAuth tokens or sync rules between platforms.