Migrate from Loyalistic to Twenty CRM

Loyalistic Contacts map directly to Twenty People records. Standard fields (name, email, phone, website) map 1:1. We perform field-level sampling during discovery to identify all active custom properties on the Contact object and map each to a Twenty custom field created via Settings Data Model before import. The migration user must create all custom fields in Twenty before CSV import because Twenty's CSV import creates records, not fields.

Loyalistic Customer Profiles aggregate contact details with enrichment data. We migrate the underlying contact fields and attach profile metadata (enrichment source, enrichment timestamp, social handles) as custom fields on the Twenty People record. The enrichment provenance is preserved as a text field noting the original source system.

Loyalistic Company records map to Twenty Company. We extract all company fields (name, domain, address, industry) and map them to the Twenty Company object. Company records must import before People records so that the company lookup on People can be resolved at insert time. We use the company domain as the dedupe key.

Loyalistic Segments define rule-based group membership. The segment logic itself cannot migrate because Twenty does not support rule-based dynamic segments. We export segment names and member lists and apply them as flat tags on the corresponding People records. The customer recreates segment logic as static filter views or tag groupings in Twenty's workspace. Segment rebuild is documented in the handoff inventory.

Survey definitions (question text, type, options) and response records are distinct objects in Loyalistic. We create a Survey Response custom object in Twenty and migrate response records linked to the originating People record via lookup. Survey question branching logic requires manual reconstruction in Twenty's workspace; we document the question structure in the handoff inventory.

Loyalistic Campaign records (title, status, timing) migrate as Twenty Task records with a campaign-type tag and campaign metadata preserved in custom fields. Engagement events (opens, clicks, sends) attach as activity records (Task subtype = activity) linked to the relevant People records. The campaign record itself does not exist as a standalone object in Twenty's standard model.

Loyalistic Deals map to Twenty Opportunity. We map dealstage to Twenty stageName, deal amount to amount, and pipeline to a Twenty Opportunity custom field that the customer configures as a picklist. Owner resolution happens by matching HubSpot owner email to Twenty user email.

Loyalistic custom fields on Contact migrate to Twenty custom fields on People. We perform field-level sampling during scoping to identify all active custom properties, their data types (text, number, date, select), and any validation patterns. Each custom field is created in Twenty Settings Data Model before migration begins. Fields must exist before the CSV import runs.

Loyalistic Report configurations (saved views, filter criteria, metric definitions) cannot migrate as interactive reports. We export the report metadata and filter criteria and document them as a list of recommended Twenty filter views and the fields to include in each. The customer rebuilds saved views from the documented specifications.

Loyalistic email and workflow templates (content, variable placeholders) export as text and HTML assets. We deliver them as a structured CSV with template content, subject line, and variable placeholders. The customer recreates templates in Twenty's workspace or a connected email tool. Template recreation is not included in the data migration scope.

Loyalistic engagement events (opens, clicks, conversions) migrate as Twenty Task records with an engagement type tag (Email Open, Email Click, Conversion). Each activity links to the originating People record. Activity timestamps are preserved as Task due dates to maintain the engagement timeline order.

Loyalistic flat tags on Contacts migrate directly to Twenty tags on People. We perform a 1:1 tag name mapping and apply them during People import. No tag logic or hierarchy exists in either platform, so no transformation is required.