Migrate from Kylas Sales CRM to Salesforce Sales Cloud

Kylas Lead records carry lead_score, lead_source, status, and owner assignment. Salesforce separates unqualified prospects (Lead) from qualified buyers (Contact attached to Account). We apply a lifecycle-stage or lead-status threshold during migration scoping to determine the split: Kylas Leads with status 'New', 'Contacted', or score below a defined threshold map to Salesforce Lead; Leads already qualified through a Kylas pipeline or with status 'Qualified' map to Salesforce Contact. The original Kylas lead_score and lead_source migrate to custom fields kylas_lead_score__c and kylas_lead_source__c on both Lead and Contact for reporting continuity.

Kylas Contact records map to Salesforce Contact. Standard fields (Name, Email, Phone, MailingAddress) migrate 1:1. Custom fields on Contact carry over via the Kylas custom field export with type-mapped Salesforce equivalents (text fields to Text, picklists to Picklist, dates to Date). Email uniqueness constraints are validated during import. Kylas contact owner resolves to Salesforce OwnerId by email match against the User table.

Kylas Companies map to Salesforce Account. The Company name becomes Account Name; industry, website, phone, and address fields migrate directly. Multi-currency settings from Kylas map to Account CurrencyIsoCode in Salesforce. Account is inserted before Contact to satisfy the AccountId lookup on Contact records. Kylas Company size classification (employees, revenue) maps to NumberOfEmployees and AnnualRevenue on Account.

Kylas Deals map to Salesforce Opportunity. The Kylas deal stage maps to Salesforce StageName using the pipeline-to-Sales-Process mapping defined during scoping. Deal value (Amount), expected close date (CloseDate), and owner assignment (OwnerId) migrate directly. Kylas closed-won and closed-lost reasons map to Salesforce LossReason fields or custom picklists.

Kylas supports multiple named Pipelines with fully custom stage names and stage counts. Each Kylas Pipeline becomes a Salesforce Opportunity Record Type with a corresponding Sales Process that whitelists the mapped stage values. Stage probability percentages migrate from Kylas to Salesforce StageProbability, rounded to integer values. We flag any Kylas pipeline with more stages than the destination Sales Process supports and discuss consolidation options with the customer before migration.

Custom fields on any Kylas object are exported with field type, picklist value IDs, and current values. We pre-create matching custom fields in Salesforce during the schema design phase, mapping Kylas field types to Salesforce field types (Kylas text to Text, Kylas number to Number, Kylas date to Date, Kylas dropdown to Picklist). Picklist value IDs are remapped to Salesforce picklist values using a translation table built during the pre-migration audit. Custom fields deploy via Salesforce Metadata API before data migration begins.

Kylas Activity records attach to Leads, Contacts, Deals, and Companies. Call-type activities map to Salesforce Task with TaskSubtype = Call and duration in CallDurationInSeconds. Note-type activities map to Salesforce Note linked via ContentDocumentLink to the parent record. Standard task activities map to Salesforce Task with Status, Priority, and ActivityDate preserved. Owner resolution uses the User email mapping. Activity ordering is preserved by setting ActivityDate to the original Kylas timestamp.

Kylas documents stored as binary blobs map to Salesforce ContentDocument (Files) linked via ContentDocumentLink to the parent record (Lead, Contact, Account, Opportunity). The file name, description, and created date migrate; original binary content transfers in base64 encoding. Very large document stores (over 10 GB) require chunked migration with separate ContentDocument and ContentVersion loads. Document metadata without binary content migrates first as a placeholder for post-migration manual upload if bandwidth is constrained.

Kylas tags apply across objects as vocabulary labels. We export the full tag vocabulary and map each tagged record to a Salesforce TopicAssignment (via Topics) or a multi-select picklist on the target object, depending on the customer's chosen strategy. We merge duplicate tag names during transformation. The customer decides at scoping whether tags map to Topics (enterprise-wide taxonomy) or multi-select picklist fields (object-scoped).

Kylas user records (name, email, role, profile) are exported and mapped to Salesforce User by email. We flag inactive Kylas users and hold them in a reconciliation queue for the customer's Salesforce admin to provision as active or inactive Users before record import begins. OwnerId references on all objects require this resolution step to be complete before migration proceeds past the User phase.

Kylas Smart Lists are dynamic saved searches with membership evaluated at display time; they have no persistent record set to export. We export the filter criteria for each Smart List so the customer's admin can rebuild the logic as a Salesforce List View, Report filter, or Flow filter. The records within each Smart List are migrated as standard filtered exports from the underlying object queries. Smart List rebuild is out of scope for migration but included in the handoff documentation.

Kylas workflow automation rules (triggers, conditions, action sequences) are not exposed through the export API. This is a platform-level restriction, not a limitation of our migration tooling. We document every active Kylas workflow with its trigger object, condition logic, action sequence, and assigned owner, and we map each to a recommended Salesforce Flow variant (record-triggered, scheduled, or screen flow). The customer's Salesforce admin or a Salesforce partner rebuilds workflows post-migration. This restriction applies to all migrations out of Kylas, not just to Salesforce destinations.