Migrate from Crust CRM to Twenty CRM

Crust CRM Contacts map to Twenty Person records. Standard fields (name, email, phone, address) map directly. The Crust contact's lifecycle stage or custom status property maps to a Twenty custom field person_type__c that the customer configures during scoping, since Twenty's Person object does not have a built-in Lifecycle Stage equivalent. We use email as the dedupe key during import and link each Person to a Company via the Company link field.

Crust Companies map directly to Twenty Company records. Company name, domain, industry, employee count, and address fields map to their Twenty equivalents. We use the Crust company domain as the Website field and as the dedupe key. Company is created before Person import so that the company link relationship is satisfied at Person insert time.

Crust Deals map to Twenty Opportunities. The dealstage property maps to a Twenty pipeline stage value that we configure in Settings before migration. Pipeline and stage names migrate from Crust's pipeline-stage map as a translation table, with the Crust pipeline becoming a Twenty pipeline defined in Settings Data Model.

Crust pipelines with arbitrary stage names map to Twenty Pipelines defined in Settings Data Model. Each Crust pipeline stage becomes a Twenty Stage with a probability value translated from Crust. Stage ordering is preserved. If Crust has multiple pipelines, each becomes a separate Twenty Pipeline.

Where Crust CRM has a distinct Lead object separate from Contact, we treat all Lead records as Person records in Twenty with a person_type__c value set to Lead. Twenty's People object unifies contacts and leads without a separate object, so we preserve any Crust lead_score or lead_source fields as custom Person fields rather than splitting into separate objects.

Crust activity records (calls, emails, meetings, tasks, notes) migrate as Twenty Task or Note records linked to the parent Person, Company, or Opportunity via the target_object and target_record_id fields. We set the activity date from the Crust timestamp to preserve timeline ordering. Call duration and disposition map to custom Task fields if defined in the Crust schema.

Crust configurable modules are the most migration-specific object type. We run a pre-migration schema audit against the Crust instance (via REST API for cloud-hosted or database export for self-hosted) to enumerate every custom object, its field types (text, number, date, relation, multi-select, etc.), and any module-to-module lookup dependencies. We then use Twenty's /metadata API to pre-create the equivalent custom objects with matching field names and types before importing any Crust custom module data. Any field types that do not have a direct Twenty equivalent (e.g., complex Crust-specific types) are flagged during scoping with a transformation recommendation.

Crust Users (owners assigned to contacts, companies, deals) map to Twenty WorkspaceMembers by email match. We resolve the owner assignment during import by looking up the WorkspaceMember record by email. Any Crust Owner without a matching Twenty WorkspaceMember goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Crust attachments stored per record are exported individually with filename and record association preserved. We re-attach them in Twenty using the native file attachment mechanism. If Crust stores attachments in an external storage backend (S3, local filesystem), we coordinate with the customer's technical team for access credentials during scoping.

Crust tags (simple label fields on any object) map to Twenty Tag records. Tags are linked to the parent record (Person, Company, Opportunity) via the taggable_id and tag_id fields. We preserve tag names exactly as they appear in Crust.

Crust CRM's enterprise messaging and identity management modules store collaboration metadata (user mentions, discussion threads, team channels) that has no direct equivalent in Twenty's data model. We export this metadata as a JSON manifest and attach it as a Note on the relevant Workspace record in Twenty for the customer's admin to review. Actual messaging history does not migrate as it is not a CRM record in Twenty.