Migrate from Basecamp Scout to Twenty CRM

Basecamp Scout's Lead records map 1:1 to Twenty CRM People records. The primary name, phone, email, and address fields translate directly. Lead status (Active, Qualified, Converted) maps to a custom pick-list field (Lead_Status__c) on the People record since Twenty does not have a native lead-status concept.

Basecamp Scout assigns one Sales Rep per lead. In Twenty, owner assignment uses the WorkspaceMember relation on People. We resolve Basecamp Scout's assigned_rep by email match against Twenty Workspace Members. Unmatched reps are flagged before migration — teams either invite them to Twenty first or assign records to a fallback Workspace Member.

Basecamp Scout optionally tracks company associations per lead. These map to Twenty Companies records. The Basecamp Scout company name, industry, and size fields translate to Twenty's displayName, industry, and size fields. Multi-company associations per lead (if used) need to be resolved to a primary company in Twenty with additional company links stored as relation notes.

Basecamp Scout follow-up records map to Twenty Tasks. The follow-up title becomes the Task subject, due date maps to dueDate, and completion status maps to Task status. Each Task is linked to the corresponding People record (the lead it belongs to) via Twenty's relation field. Follow-up notes content becomes the Task body.

Basecamp Scout meeting-status records capture whether a meeting was scheduled, attended, or resulted in a next step. Meetings with narrative content (notes, outcomes) migrate as Twenty Notes linked to the relevant People record. Meetings without narrative content migrate as Tasks with the meeting status as the Task description. The original status value (Scheduled, Completed, No-Show) is preserved in a custom pick-list field (Meeting_Status__c).

Basecamp Scout's geo-tagged attendance records have no equivalent in Twenty's standard objects. We create a custom object (Attendance_Log__c) with fields for location coordinates (latitude, longitude), timestamp, geo-fence name, and the related People record. This preserves the full attendance history but requires custom field creation in Twenty before import runs — the migration plan documents the required schema.

Basecamp Scout alert rules (SMS on geo-fence breach, push on status change) have no native equivalent in Twenty's workflow builder. We preserve the alert configuration as a reference custom object with fields for trigger_type, notification_channel, and recipient list. Rebuilding equivalent logic in Twenty requires workflow rule creation post-migration — we provide an export of the alert configuration as a rebuild reference.

Basecamp Scout's lead priority and scoring fields map to a custom Number field (Lead_Score__c) on the People object. If multiple priority levels exist, we preserve the raw numeric or categorical value and document the value mapping so your team can configure a matching pick-list in Twenty.

Basecamp Scout supports up to 10 custom fields per inbox (dropdown, single-line text, multi-line text, number, date). Each inbox's custom field set requires individual mapping to Twenty custom fields on the People object. Dropdown fields need value-by-value mapping to Twenty pick-lists. We create the target custom fields in Twenty before import and validate that pick-list values match before the full run.

Basecamp Scout file attachments on leads or follow-ups migrate as Twenty Notes with the file content stored as note body or as a linked attachment. File size limits in Twenty's PostgreSQL-backed storage accommodate typical document sizes. We flag any files exceeding reasonable size thresholds before import so your team can decide whether to host externally or compress.

Twenty's People.createdAt is set at migration time. Original Basecamp Scout create dates are preserved in a custom datetime field (original_create_date__c) for reporting continuity. This ensures pipeline reports reflect when leads were originally created rather than when they landed in Twenty.

Basecamp Scout's internal record ID is stored on the migrated People record as source_system_id__c. This field enables delta-run de-duplication (preventing record duplication if the migration is re-run) and provides traceability between the source and destination records. When future synchronizations run, we reference this field to match incoming Basecamp Scout records against already-migrated Twenty People records, ensuring each lead is updated rather than duplicated. The source_system_id__c also supports audit trails and reconciliation reporting by linking every Twenty record back to its original Basecamp Scout identifier.