Migrate from monday CRM to Twenty CRM

monday's People feature (inside the CRM module) maps to Twenty's People object. People stores name, email, phone, and CRM-specific properties as a distinct API entity from board Items. We map display name, primary email, primary phone, and any custom People properties to Twenty custom fields on the People object. Note: Twenty's out-of-box People standard fields are more limited than monday's CRM properties — industry, employee count, and social profiles require custom field creation before import. We flag missing standard fields during schema design so the Twenty workspace is provisioned correctly before CSV import.

monday CRM Deals are CRM-typed Items attached to a Pipeline. Each Deal carries standard columns (deal value, close date, stage) plus optional custom columns. We map the deal value to Opportunity Amount, close date to CloseDate, and pipeline stage names to Opportunity StageName. The Twenty workspace must have matching StageName picklist values provisioned before import; we extract stage definitions from monday's Pipeline API response and create the corresponding stages in Twenty during schema setup.

monday Pipelines group Deals into ordered Stages with optional probability percentages. We extract each Pipeline's stage definitions (stage name, position, probability) and configure corresponding Opportunity stages in Twenty's Settings → Data Model. Probability percentages migrate to Twenty's StageProbability values. If the monday account has multiple Pipelines (each with its own stage set), we create multiple stage groups in Twenty or use a custom field (Pipeline Name) to differentiate if Twenty's stage model does not natively support multiple independent stage sets.

monday board Items that are not CRM-typed but contain relevant business data (activity notes, project-linked records) are evaluated during scoping. Items with a Name and long-text body map to Twenty Notes. Items with a due date and assignee map to Twenty Tasks. Items that represent products or services without a deal association may require a custom object in Twenty. We flag the item count per board during discovery so the customer can decide what to migrate versus archive.

Subitems are nested rows inside a monday Item and are excluded from monday's bulk account export and standard Excel export. We must enumerate each subitem individually via the monday API using the parent Item's ID, which multiplies API call volume. Each subitem migrates as a record in a Twenty custom object (linked to the parent Opportunity) or as a Note attached to the parent record, depending on the customer's chosen data model. The subitem enumeration count is scoped upfront because it directly affects API time and migration timeline.

monday supports over 20 column types including text, number, date, formula, dependency, link, and status. Custom columns are preserved as field definitions in monday exports. We map each custom column to a Twenty custom field on the relevant object (People, Opportunity, or a custom object). Formula and dependency columns in monday — which compute values based on other Items — have no direct Twenty equivalent and are flagged as 'computed field, requires rebuild' in the mapping document. Column types relying on monday-specific integrations (e.g., Integromat columns) are also flagged as non-migratable.

monday Updates are per-Item comment threads. The per-board Excel export can include Updates as a separate tab; via API, Updates are enumerable per Item. We preserve Update text and timestamps, mapping them to Twenty Note records attached to the parent record (People, Opportunity, or Company). The original author and timestamp migrate to Note fields. Rich text formatting in monday Updates is simplified to plain text in Twenty Notes.

Files uploaded to monday board Items are stored in monday's file storage. We retrieve file URLs via the monday API and re-attach them to the corresponding Twenty records (People, Opportunity, or Note). File attachments are included in the per-board export but can be excluded to reduce download time on large accounts. The customer chooses whether to include file attachments during scoping.

monday Users are account members assigned as owners or collaborators. We map users by email and name. monday's permission structure (multi-level permissions, SAML SSO on Enterprise) is not part of the standard export and does not migrate. Twenty workspace membership must be configured manually before migration so that Owner lookups on Opportunity and Note can be resolved during import. We flag any monday Owner without a matching Twenty User for admin provisioning before the record import phase.

monday automations built on the Sentence Builder (Recipe) system or the new monday workflows system are workflow logic, not CRM data. They fire on item changes and cannot be extracted as transferable rules. We do not migrate automations. We deliver a written inventory of every active automation rule during pre-migration review, capturing the trigger, conditions, and actions with a recommended Twenty workflow equivalent. The customer's admin rebuilds automations in Twenty post-migration.

monday Dashboards aggregate data across multiple boards into chart and summary widgets. They reference board Items and column data live. We cannot migrate dashboard definitions because they are view configurations, not data. We migrate the underlying tabular data so that Twenty views and reports can be rebuilt on top of the imported records. Saved Kanban filters, board views (Kanban, Calendar, Chart), and conditional colouring are similarly not migratable; we flag their configuration in the pre-migration review document.