Migrate from Kylas Sales CRM to Twenty CRM

Kylas Lead records map to Twenty Person records with a custom field kylas_lead_source__text storing the original lead_source value and a custom field kylas_lead_score__number preserving any numeric score. Kylas lead status (New, Contacted, Qualified, Unqualified) maps to a custom picklist kylas_lead_status__picklist on the Person object. Since Twenty has no built-in Lead conversion workflow, converted Kylas Leads retain their Person record; the customer's team configures any follow-up conversion logic post-migration.

Kylas Contact records map directly to Twenty Person records. Email, phone, address, job title, and lifecycle-stage metadata transfer to the corresponding Twenty Person fields. Custom fields on Kylas Contacts (beyond the standard set) are created in Twenty via the /metadata API before import and mapped by field type. Kylas Contact-to-Company linkage transfers as a Twenty Person-to-Company relation.

Kylas Company records map to Twenty Company records with industry classification, company size, and domain data preserved. The Kylas industry picklist values are remapped to Twenty industry picklist equivalents. Multi-currency settings from Kylas (relevant for companies with international operations) are stored as a custom field in Twenty since Twenty's self-hosted model handles currency display at the deployment level.

Kylas Deals map to Twenty Opportunities. The deal value transfers to the Opportunity amount field, the expected close date maps to closeDate, and the pipeline stage name maps to a Twenty Opportunity stage. Kylas pipeline names (if multiple exist) map to a custom Opportunity field pipeline_name__text for segmentation. Closed-won and closed-lost reasons from Kylas custom fields become Twenty custom fields for deal retrospective analysis.

Kylas named Pipelines with custom stage sets map to Twenty Opportunity stage configurations. We extract every unique stage name from every Kylas pipeline and create matching stage values in Twenty's Opportunity settings. If a Kylas pipeline exceeds Twenty's practical stage count, we consolidate low-volume stages into a catch-all stage and document the mapping for the customer's review.

Kylas Activity records (Tasks, Calls, Notes attached to Leads, Contacts, Deals, and Companies) map to Twenty Task records and Comment records. The activity type determines the mapping: Kylas task engagements become Twenty Tasks with status and due date preserved; Kylas call logs become Twenty Tasks with a custom call_duration__number field; Kylas notes become Twenty Comment records linked to the parent Person or Company. Activity timestamps are preserved as the Task createdAt date.

Kylas custom fields on any object are exported with their field type, picklist value IDs, and current values. We create matching custom fields in Twenty via the /metadata API before data import. Picklist value IDs from Kylas are remapped to Twenty picklist labels, and a custom field kylas_original_field_name__text is added to preserve traceability. Custom field migration is a pre-requisite step executed before any record import.

Documents stored in Kylas are exported as binary blobs with parent record associations. Twenty supports file attachments via its API; we map Kylas documents to Twenty attachments linked to the corresponding Person or Company record. Very large document stores (over 5 GB of attachments) require a separate storage provisioning step and may extend the migration timeline by one to two weeks.

Kylas tags apply across objects as a cross-object labeling system. Twenty uses Label2 for tagging entities. We export the full Kylas tag vocabulary and map each tagged record to a Twenty Label2 with the same name. Tags that apply to both Persons and Companies create multiple Label2 relations on the respective records.

Kylas user records (name, email, role, profile) are exported and mapped to Twenty WorkspaceMember records. We match by email as the primary key. Inactive Kylas users become inactive WorkspaceMembers in Twenty pending the customer's decision to re-activate. Owner assignment on Deals, Activities, and Contacts resolves by matching the Kylas owner email to the Twenty WorkspaceMember after user provisioning.

Kylas Smart Lists are dynamic saved searches with filter criteria evaluated at display time; they have no persistent record set to export. We document every Smart List's filter criteria (field names, operators, values) in a written inventory so the customer's team can recreate the logic using Twenty's filter and view system. This is not a data migration; it is a configuration inventory delivery.

Kylas workflow automation rules (triggers, conditions, action sequences) are not exposed via the export API. We perform a UI-assisted audit of every active Kylas automation and document it in a written inventory specifying the trigger object, conditions, and action sequence. The customer's team uses this document to rebuild automations in Twenty or via an external automation tool. This is not a code migration; it is a rebuild blueprint.