Migrate from Swift Digital Suite to Twenty CRM

Swift Digital Suite Contacts map to Twenty CRM People records. We export the full contact profile including email address, first name, last name, phone, custom properties, engagement score, segment membership, and lifecycle stage. The contact's email address becomes the People email field and serves as the dedupe key during import. Engagement score migrates as a numeric custom field (e.g., swift_engagement_score__c) because Twenty has no native scoring algorithm. Segment memberships map as Tags applied to the People record in Twenty. Lifecycle stage maps to a text or select custom field for reference. The contact's SMS consent and email subscription flags collapse into Twenty's single opt-out field using the more restrictive state.

Swift Digital Suite does not have a native Company or Account object, but enterprise contacts often store organisation name in a custom property or as a related record. We extract the organisation name from the contact's custom properties, deduplicate unique organisation values, and create Twenty Company records first, then link People records to the resolved Company via the ManyPeople relation. This ensures the People-to-Company relationship is satisfied at insert time rather than patched in a second pass.

Swift Digital Suite segments are named groups of contacts based on behavioural or demographic criteria. We export each segment as a distinct tag name and apply it to every People record that was a member. In Twenty, tags are a first-class concept on People. If the customer uses segments as dynamic audience lists rather than static tags, we document the segment definition as a written criteria map so the customer's admin can recreate the dynamic logic in Twenty's filter views or a connected automation tool.

Individual email sends from Swift Digital Suite campaigns are tied to contacts. We export the send timestamp, open timestamp, click events, and bounce or unsubscribe status for each contact-campaign pair. In Twenty, email engagement events become Tasks with a custom email type (e.g., taskType = email_sent, email_opened, email_clicked) and the campaign name stored in the body or a custom field. The ActivityDate preserves the original send or open timestamp for timeline ordering. Bounce and unsubscribe events update the People opt-out field accordingly.

SMS sends from Swift Digital Suite are tied to contacts and campaigns. We export the message content, direction (inbound or outbound), timestamp, and SMS consent flag. In Twenty, SMS records become Note records attached to the People record, with a custom field indicating direction and campaign association. The contact's SMS opt-out flag collapses into the single People opt-out field as described above. If the customer requires SMS history to be queryable as structured data rather than Notes, we recommend creating a custom SMS object in Twenty before migration.

Swift Digital Suite event registrations include registration date, ticket type, attendance status, and RSVP history. We export the full event roster as a contact-level log of event participation. In Twenty, each registration becomes a Task record linked to the People record, with the event name as the subject, ticket type in a custom field, and attendance status in another. Event-level custom fields (venue, speaker, capacity) are stored as custom fields on the Task.

Survey responses in Swift Digital Suite are tied to contacts as structured answer data. We export all question-answer pairs as flat rows per contact. In Twenty, we map each survey question to a custom field on People (for single-response surveys) or create a Note with the full response block (for multi-question surveys). Survey conditional branching and skip logic are not exposed in the export and cannot be migrated; we document the survey structure as a written description so the customer's admin can evaluate whether rebuild is needed in a dedicated survey tool or as form logic in a connected tool.

Swift Digital Suite campaigns are parent containers for email sends, survey triggers, and event invitations. Campaign metadata (name, type, created date, status) is exported as structured records. In Twenty, which has no native campaign object, we map campaigns to a custom Campaign object we pre-create with fields for name, type, start date, and status. Campaign membership (which contacts received which campaign communications) is preserved as Tags on People linked to the campaign record via a custom lookup field.

Swift Digital Suite automation workflows define trigger conditions, time delays, and action steps. We document the workflow as a structured record showing the trigger, each step, and its conditions, including which contacts are enrolled and which actions fire. Because workflows are code-equivalent and depend on Twenty's own Workflow Automation feature (which requires custom fields to pre-exist), we do not migrate them as executable configuration. We deliver a written workflow inventory document for the customer's admin to review and rebuild in Twenty or a connected automation platform such as Zapier, Make, or n8n.

Contacts and campaigns in Swift Digital Suite support custom properties. We extract all active custom property names and values, map them to identically named custom fields in Twenty's Data Model, and verify that the field type is compatible (text maps to text, number maps to number, date maps to date, select maps to select). Fields must be pre-created in Twenty Settings before the People import runs; we coordinate this with the customer during scoping and confirm all fields exist in the target workspace before production migration begins.