Migrate from Kursaha to Twenty CRM

Kursaha Contact records map to Twenty Person records. Standard fields (name, email, phone, company) map directly. Behavioral properties (lifecycle stage, lead score, engagement frequency) are preserved as custom fields on the Person object in Twenty. We confirm field type compatibility during scoping because Kursaha behavioral properties may be stored as free-form text that requires normalization to Twenty's typed fields. Company association in Kursaha maps to the Company field on Twenty Person, creating a lookup link.

Kursaha Company records (if present in the export) map directly to Twenty Company records. Domain from Kursaha becomes the Company website field. We use domain as the dedupe key during import. If the customer's Kursaha data contains only Contact-level company data without discrete Company records, we create Companies from unique domain values during the transform step before importing to satisfy Twenty's Person-Company relationship model.

Kursaha Kampania objects contain campaign metadata (name, status, start/end dates, channel assignments) that does not map to any standard Twenty CRM object. We map Kampania name, status, and dates to a Twenty Opportunity with a custom Kampania Name field, treating each campaign as a business relationship or initiative rather than a marketing send record. If the customer has more than one campaign per opportunity context, we create a custom Kampania object in Twenty before migration. Channel assignments (mail, WhatsApp, SMS) are documented as custom fields for manual reconstruction in any multi-channel tool the customer adopts post-migration.

Kursaha audience segments are defined by filter rules against contact properties. We audit every segment's filter conditions and reconstruct them as Twenty Saved Views with equivalent filter logic. Complex multi-condition segments may require simplification because Twenty's filter builder uses a simpler operator set than Kursaha's segment rule engine. We document any segment that cannot be fully reconstructed so the customer's admin can rebuild it manually.

Kursaha Channels are linked to Kampania rather than stored as independent records. We preserve channel-to-Kampania associations as custom fields on the Kampania-equivalent Opportunity or custom object. The channel templates (email, WhatsApp, SMS content) are extracted as text fields for documentation purposes. Actual template rendering and channel delivery in Twenty requires the customer to configure a separate email sending tool (such as a transactional email service) and potentially a WhatsApp Business API integration.

Kursaha templates include text content and HTML structure for each channel. We extract template body text and basic HTML markup into Twenty Note records linked to the associated Kampania-equivalent record for reference. Advanced AMP markup and interactive elements cannot be preserved; we flag these as requiring rebuild in the destination channel tool. The template subject line migrates as a Note title for audit purposes.

Kursaha user accounts and role assignments (admin, editor, viewer) map to Twenty workspace user accounts. We extract users by email address from the CSV export and create corresponding Twenty users during migration. Role mapping is documented for the customer's admin to reassign in Twenty's role and permissions settings because role hierarchies differ between platforms.

Kursaha's real-time analytics and campaign engagement metrics (opens, clicks, conversions, cohort data) are computed by the platform's processing layer and are not available as discrete exportable records. We do not migrate analytics history. Customers should capture screenshots of dashboards before cutover. Post-migration analytics are rebuilt in Twenty's native reporting or in a dedicated BI tool connected to Twenty's API.

Kursaha integrations with third-party tools (forms, CRM connections, analytics platforms) are configuration-level settings stored in Kursaha's platform. These do not export as data records. We document every active integration the customer has configured in Kursaha so that the same integrations can be reconfigured in Twenty or a new tool post-migration.

Kursaha custom contact properties not present in the standard field set are preserved as custom fields on the Twenty Person object. We create each custom field in Twenty before migration, mapping the source field name to a descriptive Twenty API name. Text, number, date, and boolean property types map directly; multi-select or behavioral scoring properties require a review of the source data to determine the appropriate Twenty field type.