Migrate from SalesPro CRM to Twenty CRM

SalesPro Contact records map to Twenty Person. The core fields (name, phone, email, company association) transfer directly. However, Twenty's Person object lacks standard multi-email and multi-phone support as of the current release — we flag this during scoping and recommend creating custom email and phone fields before migration. SalesPro's spouse signing field (which can contain spurious null values due to a known bug) is stripped during transformation.

SalesPro Company records map directly to Twenty Company. The foreign key linking Contacts to Companies is preserved by resolving the source company ID to the Twenty Company record ID at migration time. Note that Twenty's Company object lacks standard industry, employee count, and annual revenue fields per GitHub issue #13953; we create these as custom fields during schema preparation so that the full SalesPro Company profile migrates.

SalesPro Events (central to hospitality and venue sales use cases) containing date ranges, group details, and BEO references map to a Twenty custom object named Event__c or to Opportunity with custom fields, depending on the customer's workflow. The decision is made during scoping based on whether the customer wants to preserve the BEO generation workflow. Events must be migrated before BEO records because BEOs reference Events via a derived relationship.

SalesPro BEO records are derived outputs from Events and contain cost calculations, timeline specifications, and event signatory data. Twenty has no native BEO object, so we create a custom BEO__c object with fields for event date range, group size, cost breakdown, timeline notes, and signatory information. The Event-to-BEO linkage is preserved as a lookup relationship. If an Event is deleted before migration, its BEO becomes orphaned — we flag this during pre-migration audit and ask the customer to verify all Events are active before export.

SalesPro Task records including assignees, due dates, email reminders, and completion status map to Twenty Task. Assignee assignment is resolved via user email lookup against the Twenty User table. Due dates, priority, and status transfer directly. Tasks are migrated after Users are provisioned to satisfy the assignee reference.

SalesPro Milestones tied to pipeline stages or individual deals map to a custom Milestone__c object in Twenty with fields for milestone name, target date, completion status, and related pipeline stage. If the customer uses milestones primarily for task tracking, we map to Tasks with a custom milestone_type picklist. Milestone ordering relative to pipeline stages is preserved as a custom sequence integer.

SalesPro pipeline stages map to a custom pipeline configuration in Twenty. Each SalesPro stage name and relative position becomes a Twenty stage entry with a custom pipeline__c reference. Stage order is preserved via a sequence field. Custom stage names require field value mapping at migration time.

SalesPro Users assigned to Contacts, Tasks, and Events are resolved by email address against the Twenty User table. Owner reassignment during migration requires explicit admin action — we provide a user mapping table with the email correspondence and flag any SalesPro User without a matching Twenty User in the reconciliation queue. Role-based access flags transfer as custom fields until Twenty's native permission model is configured.

SalesPro calendar entries containing bookings and resource assignments map to the custom Event__c object with start/end timestamps and resource assignment fields. The webhook-based API limitation means calendar data is included in the vendor data export request rather than collected via API polling. If the customer uses the calendar for internal scheduling rather than client event management, we map to Twenty's standard Event object instead.

SalesPro does not expose a bulk attachment export endpoint via its webhook API. Files associated with Events, Contacts, or BEOs cannot be programmatically retrieved without direct database access. We notify the customer during scoping that attachments will not migrate and provide a manual retrieval checklist grouped by record type. The customer or a file specialist can retrieve and re-upload attachments post-migration.