Migrate from Krayin CRM to Twenty CRM

Krayin Leads map directly to Twenty People. We use email as the primary dedupe key. If a Person record with the same email already exists in Twenty from a prior Persons migration, we flag the duplicate for the customer to resolve. Krayin lead status, source, and score custom attributes migrate to Twenty People custom fields that must be pre-created in Settings → Data Model. Krayin lead-to-person conversion history does not carry over; we treat all Krayin Leads as open records requiring a fresh stage assignment in Twenty.

Krayin Persons map to Twenty People. Name, email, phone, address, job title, and department migrate directly. Custom attribute fields on Person objects (dropdowns, multi-select, date fields) require a direct database query to Krayin's custom_attributes table because the REST API does not fully expose all attribute field types. We map the custom field values to Twenty People custom fields, creating the fields via the Twenty GraphQL API during setup if they do not already exist. Email is the dedupe key across the Persons load.

Krayin Companies map to Twenty Company. Company name, domain, address, phone, and industry (if populated in Krayin) migrate directly. We create Companies in Twenty first in the load order so that Company ID is available for Person association (Krayin Persons are linked to a Company by organization_id). Any Person records without a valid Krayin organization_id map to a 'No Company' placeholder in Twenty and are flagged for manual reassignment post-migration.

Krayin Deals map to Twenty Opportunity. Deal name becomes Opportunity name, amount maps directly, expected close date maps to closeDate, and Krayin stage_id maps to a Twenty Opportunity status value that we create during setup. Owner (Krayin user_id) maps to the Twenty Member with the matching email. Krayin Deal-to-Person and Deal-to-Company associations migrate as Opportunity-to-People and Opportunity-to-Company links in Twenty via the relationship API. Custom deal attributes migrate to Opportunity custom fields via direct DB query where the API is incomplete.

Krayin Pipelines (custom stage sequences per deal type) map to Twenty Opportunity status values within a single Opportunity object. We create status values matching Krayin stage names and probabilities during the Twenty workspace setup phase via the GraphQL API. If Krayin uses multiple pipelines with different stage sets (common in multi-line-of-business Krayin deployments), we create Twenty Opportunity status values scoped by pipeline name prefix. Stage transition rules and automation triggers from Krayin cannot migrate; we document each pipeline's stage sequence as a written deliverable for the customer's admin to rebuild in Twenty manually.

Krayin Products map to Twenty Product. SKU, name, price, description, and inventory quantities migrate directly. Products must be created before any Deals/Opportunities that reference them so that product associations can be resolved at import time. Krayin product categories map to Twenty Product custom fields or a category field we create via GraphQL if the standard Product object lacks one.

Krayin Quotes do not have a direct Twenty equivalent; Twenty does not include a native Quotes object as of 2026. We migrate Quote records as Note objects attached to the related Opportunity, preserving line items as a structured text body in the Note. The customer rebuilds quoting capability in Twenty using custom objects or a third-party quoting tool post-migration. If the customer requires a full Quote-to-OpportunityLineItem model, we scope a custom object build as a separate engagement.

Krayin Activities (Tasks, Calls, Meetings) map to Twenty Tasks. Call disposition and duration migrate as custom Task fields; Meeting start and end times map to Task startDate and dueDate fields. Activity records are associated to their parent Krayin record (Lead, Person, Deal) via the Twenty relationship API by resolving the target People or Opportunity ID. We preserve the original Krayin activity timestamp as a custom field for audit ordering. Activity types that have no clear Twenty analog (e.g., Krayin's specific event subtypes) map to a generic Task with a type custom field preserving the original value.

Krayin Users map to Twenty Members. We match by email address. Any Krayin User referenced on a Deal or Activity record must have a matching Twenty Member before that record's import can proceed; we enforce this dependency in the load order. Role and permission sets from Krayin require manual rebuild in Twenty because Twenty's permission model uses a different structure. We export the Krayin role assignments as a written report for the admin to reconfigure.

Krayin tags on Leads, Persons, and Deals migrate to Twenty Tag records. Tags are stored as string arrays in Krayin and must map to Twenty's Tag object. We create Twenty Tags during migration and associate them to People and Opportunities via the Tag API. If a Krayin tag has no equivalent in Twenty's tag vocabulary, we preserve it as a custom People or Opportunity multi-select field. Tag taxonomy cleanup is recommended during scoping: unused tags with fewer than 10 associated records are flagged for exclusion.

Krayin custom attributes on Leads, Persons, Companies, Deals, and Products require a direct database query to Krayin's custom_attributes table because the REST API does not expose all custom attribute types (particularly dropdowns, multi-select, and date fields). We query the database directly, extract the attribute definitions and values, then create the corresponding Twenty custom fields via GraphQL before importing the values. This adds a discovery step to the migration timeline but ensures complete field coverage. We flag any Krayin attribute types with no Twenty equivalent (e.g., Krayin-specific field types) as requiring manual post-migration field creation.