Migrate from Splio to Twenty CRM

Splio Contacts map directly to Twenty People records. We audit list membership before export and assign orphan contacts (those with no list assignment) to a catch-all tag so they are not silently excluded. Contact custom fields (scope: contacts) pre-created in Twenty Settings → Data Model before import. Email, phone, address, and date fields are type-mapped directly; Splio loyalty properties (card_code, nq_points, q_points, tier) migrate to custom fields on People.

Splio Company records map to Twenty Company records. The company name becomes the Company name field; domain and website migrate to standard Company fields. Companies are created before People so that the workspace relationship on People resolves correctly during import.

Splio Orders map to Twenty Opportunity records. The order total maps to Opportunity Amount; order date maps to Opportunity close date; contact reference maps to the related People record. Splio's order status (pending, confirmed, shipped, cancelled) maps to a custom Opportunity status field. Orders are migrated after both Products and Contacts exist in Twenty so that the line-item references resolve correctly.

Splio Order Items (individual line items within an order) map to a custom object (LineItem__c) that we create in Twenty. Each LineItem__c record links to its parent Opportunity via a lookup relationship and to the Product via a ProductId lookup. Splio requires the parent order to exist before accepting line items; we enforce the same dependency by migrating LineItem__c after Opportunity creation completes. Quantity and unit price map to custom numeric fields.

Splio Products map to a custom Product__c object in Twenty (Twenty's standard product model is evolving; we use a consistent custom object approach). Product name, SKU (hs_sku equivalent), price, and category migrate as text and numeric fields. Products are migrated before Order Items so that product references are valid at line-item import time. Product custom fields (scope: products) are pre-created in Twenty before import.

Splio Loyalty Membership records carry card_code, nq_points (non-quantized points), q_points (quantized points), and tier. We migrate these as custom fields on the People object: loyalty_card_code__c, loyalty_nq_points__c, loyalty_q_points__c, and loyalty_tier__c. Fractional point values are preserved as numeric (decimal) fields. If the customer uses multi-tier loyalty rules, we document the tier thresholds as a written inventory for the customer to implement as custom logic in Twenty.

Splio Reward definitions (what rewards exist in the program) map to a custom Reward__c object in Twenty. Fields include reward_name__c, reward_type__c (discount, free product, points multiplier), point_cost__c, and expiry_days__c. Reward definitions are migrated before reward attributions so that the lookup relationship is satisfied.

Splio reward attributions (which contacts received which rewards) map to a custom RewardAttribution__c object linked to People (the contact) and Reward__c (the reward definition). Fields include attribution_date__c, points_redeemed__c, and reward_status__c. This object is migrated after both People and Reward__c exist in Twenty.

Splio Store records represent physical retail locations and e-commerce sites. We map stores to Twenty Company records with a custom store_type__c field (physical, ecommerce, hybrid) or to a custom Store__c object if the customer needs to preserve store-specific attributes (region, manager, hours). The choice is made during scoping based on whether store records need to participate in reports alongside account data.

Splio Interactions are custom API events used to trigger loyalty point credits, milestone celebrations, and programmatic use cases. We export interaction event logs and migrate them as Task records attached to the relevant People record. The task subject carries the interaction type; the task description carries event metadata and timestamp. Large-volume interaction migrations (over 100,000 events) are chunked and batch-loaded via Twenty's import API.

Splio Lists drive contact segmentation and export eligibility. We preserve list memberships as Tags in Twenty. Each Splio list name becomes a tag label; contacts with multiple list memberships receive multiple tags. Blocklists are mapped to a suppression flag (opt_out__c = true) on the People record so that Twenty respects the suppression across all channels.