Migrate from KulaHub to Twenty CRM

KulaHub Contacts map directly to Twenty People. Every KulaHub Contact property (name fields, email, phone, address, notes, tasks, documents) migrates as a typed People field. KulaHub GDPR unsubscribe flags and email preferences transfer as custom boolean fields on People so the new system respects existing suppression lists. Company affiliation in KulaHub maps to a Twenty People-Company link resolved after the Company import phase.

KulaHub does not expose a separate Company or Account object; all business entities are stored as Contact records. We extract any contact records where company name is populated, deduplicate by domain and name, and load these as Twenty Company records before the People import so that the companyId relationship is satisfied at insert time.

KulaHub activity logs are exported as a chronological time-series. Calls migrate as Twenty Task records with taskType=Call. Meetings migrate as Twenty Event records with startDateTime, endDateTime, and attendees preserved. General system events and notes migrate as Twenty Note records linked to the parent People or Company via the relationship ID. We load in date order to preserve the audit timeline and set the ActivityDate to the original KulaHub timestamp.

KulaHub Tasks linked to contacts migrate as Twenty Tasks with Status, Priority, and due date preserved. Task assignment resolves the KulaHub owner reference to the corresponding Twenty Workspace Member by email match. Any KulaHub task with no matching user in Twenty goes to the reconciliation queue for the customer's admin to provision before the production import resumes.

KulaHub documents attached to contacts are extracted as binary blobs and re-associated with the corresponding Twenty People record via file attachment linkage. File name and original upload date transfer as metadata. We flag any file exceeding Twenty's size limit during discovery so the customer can decide whether to link via URL instead.

KulaHub campaign history including opens, clicks, and unsubscribe events migrates as Note records on the relevant People records with a type tag identifying it as campaign engagement data. GDPR unsubscribe preferences from campaign tracking are carried as typed boolean People fields to ensure the destination system respects suppression. We do not recreate email campaigns as sendable objects because Twenty does not include built-in email campaign management; campaign send capability requires a third-party email platform integration.

KulaHub Users are exported first so owner and assignee references resolve correctly during subsequent record imports. We match KulaHub users to Twenty Workspace Members by email address. Any KulaHub user referenced in activities or tasks but not yet provisioned in Twenty is held in the reconciliation queue. Twenty requires members to accept their invitation and appear in the Members list before record imports that reference them can succeed.

KulaHub captures website enquiries via forms linked to contact records. The form-field schema is not publicly documented. We request a sample export of form-submission data during discovery and map each key-value pair to a custom People field in Twenty's Data Model. Unmapped fields are held in a staging table and presented to the customer for manual mapping before the production migration run.

KulaHub stores email unsubscribe states and GDPR preference flags per contact but the underlying data format is not documented. We export these flags as typed boolean custom fields on the People object in Twenty, preserving the original suppression state so the destination system can respect existing opt-outs without requiring re-consent. Email marketing to migrated contacts is disabled until the customer confirms the preference data migration is complete and verified.

KulaHub reports including the All Contacts export and activity reports are included in the migration scope as reference data. We extract these as CSV files and cross-reference record counts against migrated data to validate completeness. The report layouts themselves do not transfer; Twenty reporting is configured fresh using the migrated data as its source.