Migrate from VBOUT to Twenty CRM

VBOUT Contacts map directly to Twenty People. Standard fields (name, email, phone) transfer 1:1. Custom fields on VBOUT Contacts require pre-creation in Twenty via Settings → Data Model before import because Twenty's standard People object has sparse field coverage (GitHub issue #13953 flags this as a known gap). We create every custom field in Twenty first, then map each VBOUT Contact property to the equivalent Twenty field, using Text, Number, Date, Select, or Multi-Select types based on VBOUT's field definition. VBOUT's Lead Score property migrates to a numeric custom field on People.

VBOUT Companies map to Twenty Companies. Company domain, address fields, and industry map 1:1. Like People, the Companies object in Twenty has limited standard fields out of the box, so any custom fields on VBOUT Companies (division, annual revenue tier, account tier) must be pre-created in Twenty before the Company import batch runs. We resolve Company as the parent of People before Contact import so that the People-Company relationship link is satisfied at insert time.

VBOUT's Lead object is distinct from Contact and carries source attribution, assignment data, and lead score. We map these to Twenty People records with custom fields for lead_source__c, assigned_to__c, and lead_score__c. Note that Twenty does not yet have a native Lead object with a conversion action to custom objects (GitHub issue #10422); Leads that should become Opportunities in Twenty require manual conversion or a custom workflow rebuild.

VBOUT Tags encode pipeline stage, segment classification, and contact classification. We extract the full Tag taxonomy during discovery, then create equivalent custom fields in Twenty: pipeline_stage__c (Select), primary_segment__c (Select), and contact_classification__c (Multi-Select). Tags apply to People and Company records via lookup. The customer chooses whether each Tag set becomes a Select (single-value) or Multi-Select (multi-value) field during scoping.

VBOUT Smart Audiences are dynamic segmented lists based on behavioral and demographic criteria with proprietary rule definitions. The segmentation rules do not export in a portable format. We extract the raw criteria (field names, operators, values) and produce a written rebuild guide for each Smart Audience mapped to Twenty's filter and view system. The segmentation logic must be manually rebuilt in Twenty as saved views and filters; the audience members themselves are not a separate object and are covered by the underlying Contact export.

VBOUT Pipeline Stages are stored as Tags with ordering metadata rather than as a native pipeline object. We extract the stage names and order from the Tag set, then create a pipeline_stage__c Select field on People and a stage__c Select field on Twenty Opportunities. If the customer uses VBOUT's pipeline management module (Professional tier), we map stage definitions to Twenty's Opportunity stage dropdown values via Settings → Data Model.

VBOUT custom fields on Contacts and Leads (dropdown, conditional, text, numeric, date, payment field types) map to equivalent custom fields in Twenty's Data Model. VBOUT conditional and payment field types that have no direct Twenty equivalent are mapped to Text fields with the raw value preserved; the customer reviews and reconciles these post-migration. We require all destination custom fields to be created in Twenty before the migration batch begins because Twenty's CSV import creates records, not fields.

VBOUT email campaign history (subject, send date, open rate, click rate) can be exported as structured records. We export campaign metadata and statistics as a CSV artifact. These do not map to a native Twenty object; we recommend creating a custom EmailCampaign object in Twenty with fields for subject, sent_date, opens, clicks, and contact_count. Email template bodies export as content artifacts but must be manually re-created in Twenty's template editor because the visual layout is not transferable.

VBOUT forms (standard, multi-step, conditional, payment) export field definitions and submission records as structured data. Form field configurations migrate as a custom FormField object in Twenty. Form submission records migrate as FormSubmission records linked to the submitting Contact's People record. Payment form transaction data migrates with the submission metadata; the payment processing integration does not carry over and must be reconfigured with a Twenty-compatible payment gateway.

VBOUT automation workflows store trigger-action sequences in a proprietary JSON schema not portable to Twenty's workflow system. We export each workflow definition as a structured JSON artifact and produce a step-by-step rebuild guide mapped to Twenty's workflow editor. The trigger conditions, delays, and actions are documented in plain English so the customer's admin can replicate the logic. This is a documentation-only deliverable; the workflows themselves must be rebuilt manually.

VBOUT landing pages are stored as platform-specific page definitions with no transferable layout. We export page metadata, form field configurations, and redirect rules as a structured artifact. The visual layout, copy, and design must be rebuilt manually in Twenty's page builder or an external tool. Form field configurations carried over in the artifact reduce rebuild effort but do not eliminate it.

VBOUT dashboard reports are UI-native visualizations that cannot be exported. We export the underlying raw data (email open rates, click maps, form submission counts, lead activity logs) as CSV so equivalent reports can be built in Twenty's analytics layer. The dashboard configurations themselves do not transfer; the customer rebuilds them as Twenty views and saved filters post-migration.