Migrate from Cordis CRM to Twenty CRM

Cordis CRM contact profiles map to Twenty Person records. The first name, last name, email address, phone number, and job title migrate directly. We identify all active custom contact properties during the scoping survey before migration and map them to Twenty custom fields with equivalent data types. The Cordis interaction history timeline (tasks, notes, call records) migrates as Twenty Activity records linked to the Person.

Cordis CRM company records map directly to Twenty Company. Company name becomes the name field, domain maps to the website field, and any industry, employee count, or address properties map to corresponding Twenty Company fields. We preserve the relationship graph linking contacts to companies so that after migration, each Person record shows its linked Company on the Twenty timeline. Deduplication uses company name as the match key with external ID preservation for reconciliation.

Cordis CRM pipelines and their stage configurations map to Twenty Opportunity records scoped by a Pipeline field. We extract the stage names and order from the customer's Cordis instance during scoping and create matching Pipeline records in Twenty before importing any Opportunities. Stage probability percentages transfer where available; otherwise we use sensible defaults that the customer adjusts in Twenty's pipeline settings post-migration.

Cordis CRM Deals map to Twenty Opportunity. The deal amount, close date, stage assignment, and linked company all transfer to the corresponding Twenty Opportunity fields. We resolve the Opportunity's Pipeline reference and the Company lookup at import time. Note that Twenty (as of v2.0) does not have an automated incremental numbering system for Opportunity IDs, so we preserve the original Cordis deal ID as a custom field for audit trails and cross-reference during reconciliation.

Cordis CRM task records map to Twenty Task activities. Task title, description, due date, status (open, completed), and assignee migrate directly. Recurrence rules from Cordis are flagged as requiring manual reconfiguration in Twenty because recurrence behavior may differ between platforms. Task assignment migrates by resolving the Cordis owner email against the Twenty user email in the destination workspace.

Cordis CRM campaign membership and engagement data map to Twenty List records or segment structures depending on the customer's intended use. Campaign name becomes the list name; campaign members become list members linked to the corresponding Person records. We deliver a campaign inventory document listing every active Cordis campaign, its member count, and the recommended Twenty list structure for the customer to finalize before import.

Cordis CRM documents linked to contact or company records migrate as Twenty file attachments. We export the latest version of each document, preserve the original filename and file type, and re-associate each attachment to the migrated Person or Company record using the ID mapping table built during the import phase. Version lineage is flagged in the migration report; customers who need historical versions restore them manually from their Cordis export.

File attachments linked to individual records in Cordis migrate as Twenty Files attached via the ActivityTarget relationship. We preserve the original upload date, filename, and file type. Attachments are imported in a separate phase after all Person, Company, and Opportunity records are committed to Twenty to satisfy the parent-record lookup dependency.

Cordis CRM custom fields are identified during the pre-migration scoping survey. We map each custom field to a Twenty custom field of the closest matching data type (text, number, date, picklist, checkbox, relation). Because Cordis does not publicly document its custom field schema, this mapping is customer-specific and validated during the scoping call before the migration contract is finalized. We do not assume field names or types from generic CRM patterns.

Cordis CRM's Google Workspace integration does not auto-export email history. We extract email threads directly from Gmail where the customer authorizes access, then import them as Twenty Activity records of type email linked to the corresponding Person records. This step is optional and scoped separately; it requires explicit customer authorization and adds time to the migration timeline depending on email volume.