Migrate from Vonigo to Twenty CRM

Vonigo Contact records map directly to Twenty People records. Name, email, phone, job title, and address fields migrate as standard Twenty fields on People. Primary company link resolves via the Vonigo CompanyId → Twenty Companies relationship. Unassigned contacts (no primary company) land in Twenty with no company link and can be merged or linked manually after migration.

Vonigo Company records map to Twenty Companies. Company name, domain, industry, number of employees, and annual revenue migrate as standard fields. Vonigo's multi-location capability means a single Company may have multiple Service Location records — each location's address migrates as a separate address field set on the parent Company record, or as a custom Location object if the franchise model requires granular location tracking.

Vonigo Job records are the primary work unit and map to Twenty Opportunities. Job name becomes Opportunity name, amount migrates as the monetary amount field, and job status maps to a custom Opportunity stage field. Vonigo's job type (service category) migrates as a custom select field on the Opportunity since Twenty has no native job-type concept. The Job record's primary contact and company links migrate as Opportunity relations to People and Companies.

Vonigo work orders are sub-records of Jobs describing individual service tasks, technicians, and schedules. Since Twenty has no native work-order object, we create a WorkOrder custom object in Twenty with fields for work-order number, description, scheduled date, assigned technician (linked to People), status, service address, and a lookup to the parent Opportunity (Job). Each Vonigo work order becomes one WorkOrder record linked to its parent Opportunity.

Vonigo invoice records have no direct equivalent in Twenty's standard object set. We create an Invoice custom object with fields for invoice number, invoice date, total amount, tax amount, status (sent/paid/overdue), and a lookup to the parent Opportunity. Payment records linked to the invoice migrate separately as a custom Payment object or are embedded as line items within the Invoice object depending on the invoice-to-payment cardinality in the source data.

Vonigo payment records represent customer payments against invoices. We create a Payment custom object (or map to Invoice line items if a simpler structure is preferred) with fields for payment date, payment amount, payment method, payment reference number, and a lookup to the parent Invoice. Payment-method values are mapped value-by-value since Vonigo's payment-type vocabulary may differ from any existing custom pick-list in Twenty.

Vonigo's multi-location model stores service addresses as separate records linked to a Company. In Twenty, service addresses are represented as address fields on the Company record (primary location) and on the WorkOrder custom object (job-specific service address). If a Vonigo Company has more than one service location, the primary location migrates to the Company address fields and additional locations are stored in a custom ServiceLocation custom object with a many-to-one relationship to the Company.

Vonigo users and job owners are resolved against Twenty Workspace Members by email address match. Vonigo owner names and IDs are stored as a custom field on the target record (e.g., Opportunity.VonigoOwnerName__c). Unmatched owners are flagged in the migration plan — the team either creates corresponding Twenty users before migration or assigns records to a fallback Workspace Member. Active/inactive status is checked against Vonigo's user roster.

Vonigo file attachments on Jobs, Work Orders, and Contacts migrate to Twenty Notes records linked to the parent object (People, Companies, or Opportunities). Large files or documents are re-uploaded to Twenty's file storage. File size limits and inline-image handling follow Twenty's standard file-attachment constraints. Attachments without a clear parent record are imported as Notes on the most relevant People or Company record.

Vonigo custom fields on Contact, Company, and Job objects are created as custom fields in Twenty on the corresponding standard or custom object. Field type is mapped: text to text, number to number, date to date, and pick-list to select (with value-by-value mapping for the pick-list options). Required field constraints are checked — Vonigo required fields may conflict with existing Twenty field requirements and require post-migration admin review.