Migrate from Reach to Twenty CRM

Reach Contact records map to Twenty People. Reach does not publish a field schema, so we capture the full column set from the CSV export during extraction and treat any column beyond name, email, and phone as custom. Email address is the dedupe key for People import. The Reach contact record type is preserved as a custom field reach_record_type__c on People for audit. We resolve any Reach Owner references by email match to Twenty workspace members before importing, because Twenty requires linked users to exist before owner lookups can resolve.

No distinct Company or Account object was found in Reach documentation or reviews. If the customer's Reach instance contains company data, it is stored as contact sub-properties or free-text fields on the Contact record. We extract those columns, identify unique company names, and merge them into Twenty Company records before importing the People that link to them. The N:1 merge is resolved at extraction time by deduplicating on the inferred company name column. If no company data is present in the export, this step is omitted and People are imported without Account associations.

Reach custom properties are discovered by comparing the full CSV export column set against a baseline Reach Contact export. Each discovered column not matching a known standard field is treated as custom. Before migration, we create each custom field in Twenty via Settings → Data Model, selecting the matching Twenty field type (text, number, date, select, multi-select, currency, phone, url). Field creation must precede record import because Twenty's CSV import creates records only. API names for imports are retrieved by enabling Advanced mode in Settings per Twenty's documentation.

Reach tag-equivalent columns (implied by content management workflows in reviews) are extracted as distinct values from the export. We create a multi-select picklist field in Twenty's Data Model, populate the picklist options with the extracted unique values, and map each contact's tag column to comma-separated values in the multi-select field during import. If tags are stored as separate rows (one tag per contact per export row), we aggregate by contact email before import.

Reach Enterprise seat-license user records (name, email, role status) map to Twenty workspace members. We extract all users from the Reach export who are referenced as owners on any record and match them by email against Twenty's member list. Any Reach user without a corresponding Twenty account is held in a reconciliation queue. The customer's Twenty admin provisions missing users before record import begins, because Twenty requires linked users to exist before owner or assignee lookups can be satisfied on People and Opportunity records.

Reach playlists and screen management content referenced in reviews suggest media assets tied to contacts or accounts. We extract any URL or file-reference columns from the export and import them as Twenty Note records with a reach_media_type__c custom field set to Playlist, Screen, or Media. File attachments migrate as Twenty Attachment records linked to the nearest People or Company record. Media asset files themselves (if hosted within Reach) cannot be extracted without API access; we flag these for manual handoff and document the Reach screen or playlist names for the customer to re-enter in Twenty.

If the customer's Reach instance contains custom object records (identified during schema discovery from the full export column set), we create equivalent custom objects in Twenty via the /metadata GraphQL API. The object name, field names, and field types are inferred from the export columns and validated against Twenty's supported field types. Lookup relationships to People or Company are created as Relation fields pointing to the target object. Custom objects are migrated last in the sequence because they frequently contain lookup references to records imported in earlier phases.

Reach's export documentation does not reference activity history, call logs, engagement timestamps, or note records as separate exportable objects. We do not migrate activity data unless a full column export confirms its presence. If the customer's Reach export includes a visible activity column or related table, we treat it as a custom property and migrate it as a text or multi-select field on the associated People record rather than as a native Twenty Activity. Customers requiring full activity timeline migration should evaluate whether Reach stores this data outside the exportable schema before proceeding.

If the Reach export includes deal, opportunity, or pipeline columns, these map to Twenty Opportunity records. We create the Opportunity object in Twenty with standard fields (name, amount, close date, stage, probability) and any pipeline-specific custom fields discovered in the export. The Twenty Opportunity stage values are configured in Settings before import. Stage probabilities migrate as percentage values matching the source.

Reach export files expire seven days after generation. We document the complete schema of each export (column names, inferred data types, unique value counts, null rates) in a migration data dictionary delivered to the customer. This dictionary serves as the authoritative schema reference for the migration and for any future admin who needs to understand the Reach data structure. Any column not migrated to a standard Twenty field is documented with its original Reach column name and recommended disposition.