Migrate from XMPie to Twenty CRM

Each XMPie Audience becomes a row in a Twenty custom object named Audience, created in Settings > Data Model before any data import. We capture the Audience name, the original data source identifier, and the Circle workspace as fields. Twenty has no native segment hierarchy, so we model Audience-to-People as a one-to-many relation, with each migrated recipient pointing back to its source Audience via a lookup field. The Audience custom object preserves the historical grouping for reporting without forcing the team to reuse Circle's segment-precedence logic in Twenty.

Each unique recipient row from the XMPie data sources becomes a Twenty People record. We dedupe across multiple Audiences by email address (primary), then by combined first name, last name, and postal code (fallback) before insert. The original XMPie data source primary key migrates to a custom xmpie_recipient_id field on People for audit. Standard XMPie variables (firstName, lastName, email, phone, address1, city, state, postalCode, country) map to the corresponding Twenty People fields. Anyone present in multiple Audiences is collapsed to a single People record with the Audience lookup repeated through the custom relation.

XMPie Segments are parameter-based rules with a precedence order inside an Audience. Twenty has no segment object, so each Segment becomes either a saved View on the People object (filter expressed in Twenty's native filter syntax) or a Tag on the People record. We re-express the rule logic where the underlying field exists in Twenty, and deliver a written inventory of any segment rule that depended on an XMPie-only computed variable that did not migrate. Precedence order is not enforced by Twenty; the customer applies the segment logic at query time.

Each XMPie Campaign (the Circle orchestration container) maps to a Twenty Opportunity, with the Campaign name, start date, and status preserved. The Opportunity's Company lookup is set to the owning brand or business unit if multiple are present in the source. Active Campaigns map to open-stage Opportunities; completed Campaigns map to a Won or Closed stage that the team designates in scoping. Campaign-level scheduling and automation settings do not migrate; we deliver a written inventory for rebuild in the downstream marketing tool.

A Touchpoint is a one-to-many fan-out: one Touchpoint in Circle sends a piece to many recipients in the linked Audience. We migrate each Touchpoint send event as a Note record in Twenty, attached to the relevant People record, with a second Note copy linked to the parent Opportunity (the Campaign) so the timeline shows on both sides. The Note title carries the Touchpoint name, channel (print, email, SMS, web), and send timestamp. Delivery status (sent, bounced, delivered) and recipient-specific personalization variables are captured in the Note body as plain text.

Print Touchpoint sends carry the printed-piece SKU, the InDesign template name, and the production date. We preserve these as structured fields inside a Twenty Note record, with the proof URL or PDF attachment (if exported from the XMPie package) uploaded as a Twenty Attachment on the Note. We do not migrate the rendered per-recipient PDF unless the customer explicitly scopes it; sample proofs are migrated instead to keep storage manageable.

Email Touchpoint events migrate as Notes with subject line, send timestamp, and delivery status preserved. The email HTML body is not migrated; we deliver a written inventory of the email templates referenced by each Touchpoint so the team can rebuild them in the downstream email tool. Tracking pixel and click event data, if present in the XMPie Circle reports export, are summarized to the Note body rather than re-created as individual Twenty activity records.

Each XMPie Variable that resolves to a recipient-level data point (computed expressions tied to a data source column) becomes a custom field on Twenty People. We create the custom field in Settings > Data Model before import, with the field type matched to the Twenty equivalent (Text, Number, Date, Select). Variables that compute from server-side logic (Qlingo expressions, multi-source joins) do not migrate as live computations; we materialize the last-evaluated value as a static field and document the underlying rule for rebuild.

XMPie Data Sources (Excel, CSV, database exports linked to Campaigns) are the actual source of truth for recipient data. We export each Data Source to CSV, normalize columns to match the Twenty schema we built in step 8, and run the import through Twenty's CSV import flow. Connection configuration to the original database does not migrate; the customer must reconnect the source database to the downstream marketing tool if ongoing sync is needed.

uStore Products (static, kit, upload-driven, dynamic product types from XMPie) become rows in a Twenty custom Product object, with the SKU, product name, and product type preserved. Pricing and delivery settings are not exported by XMPie's package export, so we capture the SKU-level configuration where it exists in the data source extract and flag the rest as requiring manual reconfiguration. The Product custom object is read-only catalog reference inside Twenty, not a transactional inventory.

Each uStore storefront becomes a row in a Twenty custom Store object so the team can attach Products and Audiences to the correct storefront context. Storefront design assets, payment integrations, and order routing rules do not migrate. We deliver the Store package export (.dpkg) as an attachment on the Store record for archival, but the destination team must rebuild storefront ordering in a different tool because Twenty does not run web-to-print.

Each Circle workspace user with admin or campaign-management privileges becomes a Twenty Workspace Member, provisioned in Settings > Members. We resolve owners by email match. Per Twenty's documented migration warning, users must be invited and accept their invitation before record import runs, otherwise the owner reference on People and Opportunity records cannot be resolved and falls back to the migration service account.

Content Objects in uCreate Print (Text, Graphic, Table, Visibility, Style, Link, Multi-Page PDF Table) encode the per-recipient rendering logic that XMPie applies to InDesign documents. These rules do not migrate to Twenty because Twenty has no rendering engine. We deliver a written inventory of each Content Object's rule expression, the variables it references, and the visibility conditions, so the team can rebuild equivalent logic in the downstream design or email tool that replaces the XMPie production layer.