Migrate from Populate to Twenty CRM

Direct map. Populate person records (name, email, phone, jobtitle, address fields) migrate as Twenty People records. The company field in Populate becomes a companyId relation pointing to the matching Twenty Company record — Populate records without a company link attach to a default placeholder Company.

Direct map. Populate organization records map to Twenty Company records using the domain field for matching — if a matching Twenty Company already exists by domain, the records are linked rather than duplicated. Soft-deleted companies in Twenty count toward uniqueness and will be restored on re-import with the same domain.

Direct map. Populate deal records migrate as Twenty Opportunities — each Opportunity requires a linked Company and optionally a linked Person. The pipeline field from Populate maps to Twenty's Pipeline pick-list, which must be pre-created with matching stage values in Settings → Data Model before import.

Direct map. Populate task records migrate as Twenty Tasks with the original due date, status, and assignee preserved. Assignees are resolved by email match against Twenty workspace members — unmatched tasks are flagged before migration so a fallback assignee can be designated.

Direct map. Populate notes and log entries migrate as Twenty Notes, preserving the original body text and creation timestamp. Notes attached to a specific person, company, or deal link to the corresponding Twenty record via the standard note association fields.

Direct map with re-upload. Populate file attachments are downloaded and re-hosted in Twenty's storage layer. Inline images embedded in notes are extracted and reattached as separate files. File size limits apply on the Twenty cloud plan — files exceeding limits are flagged for manual upload post-migration.

Populate pipeline names map to a custom pick-list field on the Twenty Opportunity object. The pick-list options must be pre-created in Twenty Settings → Data Model before the Opportunity import runs — otherwise all pipeline values land as blank and require manual correction.

Stage values are mapped value-by-value from Populate directly to matching Twenty Stage pick-list options. Any stages from Populate that do not yet exist in Twenty's pick-list configuration are flagged during the data audit and created on-the-fly before the Opportunity import runs. Probability percentages and forecast-category assignments from Populate are preserved as custom fields on the Twenty Opportunity record to maintain accurate sales forecasting data.

Owner assignment is resolved by email match — each Populate owner email is matched against Twenty workspace members. Unmatched owners are flagged before migration; their records are assigned to a designated fallback Workspace Member so no Opportunity or Task lands without an assignee.

Populate custom objects map 1:1 to Twenty custom objects. Custom object schemas must be pre-created in Twenty Settings → Data Model before any records import — the metadata (fields, types, relations) determines how incoming records are validated. Custom objects with many-to-many relationships to People or Companies require junction objects to be set up in Twenty first.

When a single Populate person record links to multiple companies, the most recently modified company becomes the primary companyId on the Twenty People record. Secondary company associations are added using Twenty's native multi-company person feature — this must be pre-configured in Settings → Data Model or the secondary links are stored as a custom text field for manual resolution.

The original Populate internal record ID is stored on every migrated record as a custom text field named Source_System_ID__c for full traceability, debugging purposes, and delta-run de-duplication across migration cycles. FlitStack references this ID during subsequent migration runs to detect records already present in Twenty and automatically skip them, preventing duplicate record creation and maintaining data integrity throughout iterative migration processes.

Twenty automatically assigns its own CreatedDate timestamp at the moment each record is imported, which reflects when the migration occurred rather than when the record was originally created. To preserve accurate historical context, the original Populate record creation timestamp is captured and stored in a custom datetime field (Original_Create_Date__c) on each record. This ensures all historical reports and analytics reflect the true record creation timeline from your source system.

Populate workflows and automation sequences are platform logic with no export format. They do not migrate and have no direct Twenty equivalent — Twenty's Workflows builder must be used to rebuild each automation from scratch. FlitStack exports the full workflow definitions from Populate as a structured reference document for the rebuild project.