Migrate from Delivra to Twenty CRM

Delivra contacts with an associated company organization map to a Twenty Company record (created first) followed by a Person record with a link to the Company via the personCompany field. We use the contact's primary organization name to create or match the Company record, then link the Person to it. All contact properties (email, name, phone, custom fields, tags, lifecycle stage) migrate to the Person object with the original lifecycle stage preserved in a custom field for audit.

Delivra contacts with no associated company organization migrate as standalone Person records in Twenty. Email, name, phone, address, custom field values, and tag values map directly. Subscription status and GDPR consent flags migrate to personOptOutEmail and a custom gdprConsentDate field. This is the simplest migration path: a single flat record with no parent-lookup resolution required.

Delivra Custom Tables with 1:1, 1:many, and many:many relationships require schema extraction before any mapping design. If the custom table is a flat extension of the Contact record with no independent existence, we denormalize foreign key values into Person custom fields. If the custom table represents an independent entity with its own relationships (for example, a Subscriptions table linked to both Contact and a Product), we create a separate custom object in Twenty and document the lookup relationships for manual recreation. This is the most complex mapping type in a Delivra-to-Twenty migration and drives timeline and cost significantly.

Delivra campaign records include name, status, targeting criteria, and associated content. Twenty CRM does not have a native Campaign object in the standard data model. We extract campaign metadata (name, status, associated contact lists, targeting filter criteria) into a written inventory document that the customer uses to recreate campaigns in Twenty manually or via the API. Campaign email content requires HTML export and re-creation in Twenty's template system.

Delivra workflows built with the visual workflow builder include triggers, conditions, decision branches, time delays, and action sequences. Twenty CRM has workflow and sequence tools, but they are architecturally different and do not accept workflow exports from Delivra. We document every active workflow with its full logic tree (trigger event, each condition branch, every action and delay) and provide a recommended Twenty workflow equivalent. The customer's admin rebuilds the workflows post-migration.

Delivra segment definitions use filter conditions based on contact properties, engagement behaviors, and list membership. We extract each segment's full criteria (property names, operators, values, logical AND/OR grouping) into a written inventory. Segments do not migrate as active filters; the customer recreates them using Twenty's filter and view system, referencing the inventory document for the original criteria.

Delivra lead scoring models assign point values to contact attributes and behaviors. We export the numeric score and any scoring model rules as a custom field on the Twenty Person object (leadscoScore__c as a number field). The scoring model logic itself (which properties contribute points and at what weight) is documented separately for the customer to re-implement in Twenty manually or via a scoring automation rebuilt post-migration.

Delivra email templates built with the drag-and-drop editor export as HTML content and design metadata. We extract the HTML body, subject line, preheader, and any dynamic content blocks into a structured document. Email template recreation in Twenty requires manual re-build in Twenty's template editor or API-based HTML import. Complex conditional content blocks and dynamic personalization tokens may require additional specification documentation.

Delivra web forms and landing pages built in the visual editor have field definitions, layout configuration, and submission routing logic. We document the field names, types, validation rules, and any custom CSS or styling. Visual form builder output does not migrate; the customer recreates forms in Twenty's equivalent form tools or via a third-party form builder integrated into Twenty. Landing pages require re-creation in a separate landing page tool or within Twenty's available capabilities.

Delivra user accounts with name, email, and role-based permissions migrate as User records in Twenty. We match by email address. Roles and permission structures are platform-specific and must be re-created manually in Twenty's workspace settings. We export the role name and permission matrix as a configuration reference document for the customer's admin.

Delivra engagement history (open events, click events, SMS events, engagement scores) attached to contact records migrates as custom fields on the Twenty Person object or as Note records linked to the Person. Open and click counts become numeric custom fields on Person (engagementOpenCount__c, engagementClickCount__c). SMS event history migrates as a structured Note or as a custom SMS history field. Twenty does not have a native engagement timeline equivalent, so this data is searchable via custom field queries but not visible in the standard activity timeline.

Every custom field defined on a Delivra contact record maps to an equivalent custom field on the Twenty Person object. Field data types translate as follows: text to text, number to number, date to date, checkbox to boolean, dropdown to select, multi-select to multi-select. Required-field constraints on Delivra do not automatically replicate to Twenty; we document required fields as a configuration recommendation for the customer to apply in Twenty settings post-migration.