Migrate your Kylas Sales CRM data

Kylas treats Leads as a distinct pre-conversion object with source, status, and scoring fields. We export all Lead records including lead_score, lead_source, and custom fields. On import into platforms without a separate Lead object we merge into Contacts and preserve the lead_status as a custom property.

Contacts in Kylas carry standard fields (name, email, phone, address) plus custom properties and lifecycle-stage metadata. We perform 1:1 field mapping with validation against email uniqueness constraints in the destination.

Kylas Companies map to the standard Account/Company object. We preserve industry classification, company size, and multi-currency settings. Linked Contacts and Deals retain their association through our foreign-key stitching process.

Deals carry pipeline stage, deal value, expected close date, owner assignment, and weighted probability. We map Kylas pipeline stages to the destination pipeline model, flagging any stages that exceed the destination's stage limit.

Kylas supports multiple named Pipelines with fully custom stage names and stage counts. We map pipeline names to destination pipelines but warn when a Kylas pipeline exceeds the destination's maximum stage count, as stages may need to be merged.

Custom fields on any object are exported with their field type, picklist value IDs, and current values. We create matching custom fields in the destination during migration and remap picklist value IDs to the destination's value set.

Activity records attach to Leads, Contacts, Deals, and Companies. Kylas timestamps and owner assignment are preserved. Some activity subtypes (e.g., field-sales check-ins) may not have a direct equivalent in the destination and are flagged for manual review.

Documents stored in Kylas can be exported as binary blobs. We map them to the destination's attachment or document object, preserving the parent record association. Very large document stores may require chunked transfer.

Smart Lists are saved filter views with dynamic membership rules evaluated at query time. They have no persistent record set to export. We export the filter criteria so customers can rebuild the logic in the destination platform's equivalent feature.

Kylas workflow automation rules (triggers, conditions, actions) are not exposed via the export API. We document the automation configuration so customers can manually rebuild workflows in the destination system. This is a migration limitation Kylas imposes, not FlitStack AI.

Tags in Kylas apply across objects. We export the full tag vocabulary and map each tagged record to the destination's tagging or labelling feature, merging any duplicate tag names.

Kylas user records (name, email, role, profile) are exported and mapped to the destination's user/owner schema. We flag inactive users and invite them to the destination org after migration.

Saved reports and dashboards are configuration objects with query definitions. Kylas does not export these via its standard data export path. Customers should treat reports as read-only historical artefacts to be manually rebuilt in the new platform.