Migrate from ClinchPad to Twenty CRM

ClinchPad stores each contact with a single embedded deal in one record. We split this into a Twenty Person (first name, last name, email, phone, company name) and a linked Opportunity with the deal value, expected close date, and pipeline stage. Any ClinchPad contact without an associated deal creates a Person record with no Opportunity — these land in Twenty's People workspace as unassociated contacts. We preserve the original ClinchPad deal value and stage name as Opportunity fields and flag records that lack a close date by setting it to 90 days from migration date as a placeholder.

ClinchPad's Kanban columns (e.g., New, Contacted, Proposal, Won, Lost) map directly to Twenty's Opportunity stage values. We configure the Twenty workspace's opportunity stages during migration to match the exact stage names and sequence from ClinchPad. Stage ordering and labels are preserved so that the Kanban board reflects the customer's existing pipeline logic without manual rebuild.

ClinchPad stores company name inside the Lead record as a text field. We extract this into a Twenty Company record, using the company name as the dedupe key. If multiple ClinchPad contacts share the same company name, we create one Company and link all matching Person records to it. Companies without a name remain as Person-only records.

ClinchPad supports tagging on leads. Tags migrate as a tag field on the Twenty Person record. Twenty supports native tagging on People, so tags transfer directly without requiring a custom field. Tag deduplication handles any duplicate label variations.

ClinchPad notes attached to a lead migrate as Comment records in Twenty, linked to the corresponding Person or Opportunity. We preserve the note timestamp and author if exposed in the CSV export; otherwise the note body migrates as-is with a migration-date placeholder for the author field. Note volume per record in ClinchPad is typically low.

ClinchPad stores attachment URLs (Dropbox links, Wufoo references, direct uploads) in the CSV export without file bodies. We collect the customer's attachment store access during discovery, download source files, and re-attach them to the corresponding Person or Opportunity in Twenty's native file storage. Filename deduplication handles collisions when multiple records reference files with the same name. This step requires customer cooperation to provide source file access.

ClinchPad supports limited custom text fields on leads. We export these as-is and create matching custom fields in Twenty's data model via Settings → Data Model. Field type is set to TEXT in Twenty to match ClinchPad's text-only custom field support. The customer configures any field-label changes directly in Twenty's field editor post-migration.

ClinchPad has a flat user model without granular role permissions. We map ClinchPad users to Twenty User records by matching email addresses. Owner assignment on migrated Opportunities resolves to the matched Twenty User. Role-based access control does not carry over because ClinchPad does not expose a permission model in its export — the customer configures Twenty roles post-migration.

ClinchPad does not expose a structured activity log, task object, or engagement history via any documented export mechanism. Notes are the only migratable activity-related data. Call logs, email history, meeting records, and task lists cannot be migrated. We flag this as a data-loss gap during discovery so the customer accounts for it before cutover.

ClinchPad integrations (Mailchimp, Google Calendar, Wufoo, Dropbox) store connection tokens but not customer data. We do not migrate integration state. Mailchimp lists and Wufoo form submissions remain in those platforms and must be reconnected manually in Twenty or re-created as part of the customer's integration setup post-migration.