Migrate from Xpressdocs to Twenty CRM

Xpressdocs contact lists and individual contact records map to Twenty CRM People. Each contact record carries name, email, phone, address, and list membership tags. We preserve list-segmentation tags as a multi-select custom field on People since Twenty's standard People object has minimal default fields (per a GitHub issue citing onboarding friction from sparse standard fields). Contact deduplication uses email as the primary key. We flag any Xpressdocs contacts without email addresses for the customer's admin to resolve before import.

Xpressdocs Storefronts are brand containers with product catalogs, template libraries, and user permissions. Since Twenty has no native storefront object, we create a Custom Object called Storefront with fields for brand name, template count, product count, and SSO configuration status. Storefront user roles (Admin, Designer, Orderer) map to a custom role field on the Custom Object. SSO configuration is flagged for manual rebuild since Twenty handles SSO at the workspace level via SAML/OIDC (Organization tier) rather than per-record.

Xpressdocs Products (postcards, brochures, door hangers, business cards) carry paper type, coating, pricing, and storefront association. We create a Custom Object in Twenty called Print Product with fields for product name, SKU, paper type, coating, unit price, and storefront link. Product definitions are fully exportable from Xpressdocs per-object API. If the customer uses Xpressdocs products primarily for tracking print-related Opportunities, we alternatively map Products to Opportunity Line Item records with a custom print product reference field.

Xpressdocs Order records carry fulfillment status, delivery method, quantity, line items, and contact recipient. We map Order history to Twenty CRM Opportunity records: order amount becomes Opportunity amount, fulfillment status becomes a custom picklist field (Pending, In Production, Shipped, Delivered), and delivery method becomes a text field. The Order recipient contact resolves to a Twenty People record via email lookup. Historical orders carry line-item references that we store as Opportunity notes or as a related Custom Object (Order Line Item) with a lookup to the parent Opportunity.

Marketing templates in Xpressdocs are brand-approved designs stored per-storefront with variable-data placeholder fields. We create a Custom Object called Print Template with fields for template name, storefront association, variable field names (as a multi-select list), and asset URL reference. Template asset binaries (image files used in designs) require separate file transfer or re-upload; we export metadata and URL references only. Variable-data field definitions are preserved as named field entries in the custom template object for the customer's design team to reconfigure in the destination print platform.

The JSON Listing Feed API maintains Agent, Property, Open House, Buyer/Seller, and Picture objects in a schema separate from Xpressdocs contacts. We map Property records to a Custom Object in Twenty (Property Listing) with fields for address, price, listing status, agent association, open house date, and buyer/seller flags. Agent records in the listing feed link to Twenty People records via email or name matching. Picture objects store image metadata and MLS reference URLs; image binaries require separate file transfer. The customer should decide whether to merge listing-agent associations into the existing People object or maintain them as separate related records.

AmazingMail trigger rules are event-driven direct mail campaigns tied to external CRM events (service reminders, birthdays, appointment completions). The trigger definition and contact segment rules are not automatically portable across platforms. We export each trigger definition: event source, conditions, delay rules, contact segment criteria, and mailer template reference. We deliver a written inventory of all active AmazingMail programs with recommended Twenty Workflow equivalents. The customer's admin or a Twenty partner rebuilds the trigger logic manually in Twenty's Workflow builder, since automated trigger-from-external-event rules are not part of the standard migration scope.

Xpressdocs Storefront users and role assignments (Admin, Designer, Orderer) are exportable. We map each Xpressdocs user to a Twenty CRM workspace Member. Role naming conventions differ between Xpressdocs tiers and Twenty's permission model, so we map by permission level: Admin maps to workspace owner/admin role, Designer maps to a standard member role with editing permissions, Orderer maps to a read-only or limited role. SSO configuration from Xpressdocs maps to Twenty's SAML/OIDC workspace SSO (available on Organization tier and self-hosted), not per-user SSO flags.

Brand-specific image galleries in Xpressdocs store logo files, brand color configurations, and approved photography as platform assets. The binary files are not exposed through standard export endpoints. We export asset metadata (filename, URL reference, upload date, gallery association) as records in a Custom Object (Brand Asset) with a URL field pointing to the asset location. Actual image files must be transferred separately via file transfer to the customer's hosting environment or re-uploaded to Twenty's workspace (Twenty does not have a native DAM module). We flag all gallery assets for manual file transfer during the cutover window.

Optional Xpressdocs modules carry configuration state that is not always exposed in standard API exports. We identify which modules are active in the source account (Automated Property Marketing, XpressConnection Lead Nurturing, eProcurement Integration) and export their configuration state where accessible. Module-specific data that cannot be exported programmatically is documented in a written module inventory with the customer's admin responsible for rebuilding the configuration in Twenty or an alternative platform. Module implementation fees ($500 each) and monthly support charges have no equivalent in Twenty, so the migration eliminates these recurring costs.