Migrate from webCRM to Twenty CRM

webCRM Organisations map directly to Twenty Company records. Organisation ID is preserved as a legacy webcrm_id__c field for reference and dedupe. Custom fields on Organisation (e.g. industry classification, billing address fields) are extracted from the Overviews export and pre-created in Twenty's Settings > Data Model before Company import. The Organisation name becomes Company name and the primary address fields map to Twenty's standard address compound field.

webCRM Contacts map to Twenty People records. The Organisation ID from the source export is used to resolve the Company Lookup on each People record during import. Email address is the primary dedupe key; we flag duplicate email addresses in the scoping report for the customer to resolve before import. Contact custom fields migrate to People custom fields pre-created in Twenty's data model.

webCRM Deals map to Twenty Opportunity. The dealstage maps to Twenty Opportunity stage; the pipeline assignment maps to a Twenty pipeline pre-configured in Settings > Data Model. Deal amount, close date, and probability migrate to Opportunity amount, closeDate, and probability fields. The Organisation and Contact lookups are resolved by matching Organisation ID and Contact ID from the source export against the imported Company and People records.

Each webCRM pipeline and its associated stages are translated into Twenty Opportunity pipelines with matching stage names. Stage ordering and win/loss statuses are preserved as configured in Twenty's pipeline settings. We map dealstage values from webCRM to Twenty stage values during the CSV transform step before loading.

webCRM Deliveries are exported in webCRM Delivery XML format via Zynk. The nested XML structure (parent Delivery with child line items) is flattened into two CSV outputs: Orders header rows and OrderItems detail rows linked by a generated Order ID. We pre-create an Order custom object in Twenty with an OrderItems child relationship before loading. Delivery date, Delivery status, and linked Organisation and Contact references are preserved during the transformation.

webCRM Products from the Product Database map to Twenty Product records. Product name, description, SKU (hs_sku equivalent), and price fields migrate. Products are imported before Deals so that line items on Deals can reference valid Product IDs during migration. Inventory quantity fields map to a custom number field on Twenty Product.

webCRM Tasks linked to Organisations or Contacts map to Twenty Task records. Task subject, body, status, priority, and ActivityDate migrate. The task status labels from webCRM (e.g. Not Started, In Progress, Completed) are mapped to Twenty Task status values during the CSV transform. Tasks are imported after Companies and People so that the WhoId (People) and WhatId (Company or Opportunity) lookups are satisfied at insert time.

webCRM custom fields on Organisations, Contacts, Deals, Products, and Tasks are extracted during scoping. We create matching custom fields in Twenty's Settings > Data Model with equivalent field types (text, number, date, select, multiselect) before any record import. Fields must exist in Twenty before CSV import runs; importing into a field that does not exist results in silent column drop. The full custom field schema is documented in the scoping report.

webCRM Automation Rules in the Automation Module are not accessible via export and cannot be migrated. During scoping, we identify every active automation rule, its trigger conditions, and its actions, and document these in a written inventory for the customer's admin to rebuild in Twenty's workflow engine post-migration. The inventory includes estimated rebuild time per rule so that budget can be allocated appropriately.

webCRM Users (Owners) referenced on Organisation, Contact, Deal, and Task records are mapped to Twenty Members. The customer must invite all active Users to Twenty via Settings > Members before data import begins. We match Owners by email address against Twenty Member records. Any Owner without a matching Member is placed in a reconciliation queue for the customer's admin to provision before the migration resumes.