Migrate from Signpost to Twenty CRM

Signpost Contacts map to Twenty People records. Standard fields (name, phone, email, address, business association) migrate 1:1. Signpost's behavioral properties managed by Mia (last_contacted_date, engagement_score, review_request_status) migrate as custom fields on the People object. Note that Twenty's standard Person schema is lean—fields like phone_type, multiple email addresses, and jobTitle require custom field creation in Settings → Data Model before import. We flag these at scoping and create them via API before data migration begins.

Signpost's per-business CRM model maps directly to Twenty's Company object. Business name, address, website, and parent-child franchise structure migrate as Company fields. Custom properties on the Business record migrate as custom fields on the Company. The Company record is created before any related People import so that the People-Company relationship is satisfied at insert time.

Signpost campaigns (email and SMS) do not have a native Opportunity equivalent in Twenty. We map campaign records to a Campaign custom object we create in Twenty, capturing campaign name, type (email/SMS), target audience (tag-based), and campaign status. The automated trigger logic managed by Mia (send timing, delay intervals, branching conditions) cannot migrate; we document it as a written workflow audit and recommend the customer recreate campaign sequences in a tool like n8n or a custom automation script post-migration.

Signpost's review solicitation object tracks request timing, customer response, and positive/negative triage. Twenty has no native review object. The most recent review request status and customer response migrate as custom fields (most_recent_review_request_date, most_recent_review_status, review_response_type) on the People record. Full solicitation history across all time is flattened into a text notes field or a custom Reviews custom object with one record per solicitation event. We advise customers to export a historical review report from Signpost before migration begins.

Signpost appointment records (scheduling data, customer association, status, appointment type) map to Twenty Task records. We set Task.status based on appointment status (scheduled → Open, completed → Completed, cancelled → Cancelled) and preserve appointment type as a custom Task field. Location and notes from the appointment migrate to Task.location and Task.body. Custom appointment types that do not map to Twenty's standard Task fields require custom field creation during schema setup.

Signpost custom fields on contacts migrate to Twenty People custom fields. Field types are preserved where possible (text → text, number → number, date → date, checkbox → boolean, picklist → select). Incompatible field types are flagged for customer review during scoping. Custom fields must be created in Twenty's Settings → Data Model before import; the CSV import creates records only, not fields.

Signpost custom fields on businesses migrate to Twenty Company custom fields using the same type-preservation logic as contact-level custom properties. Industry, employee count, and annual revenue (common business-level fields in Signpost) migrate as custom Company fields if Twenty's standard fields do not cover the use case.

Signpost contact tags migrate to Twenty Tags attached to the People record. Tags used for campaign targeting are preserved as tag values. Tags that represented Mia behavioral scoring segments (e.g., hot_lead, at_risk, review_requested) are migrated as tags but flagged in the scoping report since the behavioral scoring logic that assigned them is not transferable.

Signpost user accounts and owner assignments on records map to Twenty User records. We resolve owners by email match. Inactive or permission-specific Signpost users may need to be created as placeholder User accounts in Twenty. IMPORTANT: Twenty requires all referenced Users to be created and active before importing records that assign OwnerId; we sequence User provisioning before Contact import.

Referral and loyalty program enrollment records migrate as a custom LoyaltyProgram custom object in Twenty with fields for program_name, enrollment_date, referral_status, and points_balance. Program rules (earn rules, reward tiers, expiration logic) do not migrate; we document them in the written inventory for the customer's admin to reconstruct in Twenty's custom object logic or an external loyalty tool.

Signpost Payments tracks payment status against invoices or estimates. Payment records migrate as a custom Payments custom object linked to the People record, capturing payment_amount, payment_date, payment_status, and invoice_reference. Signpost Payments is a separate product tier; we scope this object only if the customer confirms Signpost Payments is in active use. Payment processing integration (Stripe, Square) is not migrated; the customer sets up payment processing separately in Twenty or retains the existing processor.