Migrate from Swivl Tech to Twenty CRM

Swivl Tech Customer records map directly to Twenty People records. Name, email, phone, and address fields transfer directly. Custom fields such as Swivl customer role or department migrate as Twenty custom fields on the People object. Owner resolution happens by email match against invited Twenty workspace members.

Swivl Tech stores company name and domain on Customer or Job records. These map to Twenty Company Name and Website fields. Industry and employee count from Swivl company records become custom fields in Twenty since Twenty does not include native industry or employee-count pick-lists. Parent-company relationships require manual review before migration.

Swivl Tech Job records — the core field-service entity — map to Twenty Opportunities. The job name becomes the Opportunity name, the service amount maps to Opportunity amount, and the scheduled date maps to the expected close date. Job status, service type, priority, and service address transfer as custom fields on the Opportunity because Twenty has no native job object.

Swivl job statuses (Scheduled, In Progress, Completed, Cancelled) require a custom pick-list field on Twenty Opportunity — typically named job_status__c. Values map one-to-one. A Twenty admin creates the pick-list options before migration so import validation does not reject records with unmapped status values.

Swivl service type (HVAC repair, electrical, plumbing, etc.) maps to a custom text or pick-list field service_type__c on Opportunity. The field type depends on whether Swivl uses a controlled vocabulary or free-text entries. Free-text entries become custom text fields; controlled pick-lists become custom pick-list fields in Twenty.

Swivl job location data (street, city, state, ZIP) has no native address field on Twenty Opportunity. We create service_address__c, service_city__c, service_state__c, and service_zip__c custom fields. Latitude and longitude, if present in Swivl, migrate as decimal custom fields for map-integration compatibility.

Swivl Tech invoice records link to jobs and carry invoice number, amount, tax, status, and due date. These map to a set of custom fields on the related Opportunity: invoice_number__c, invoice_status__c (pick-list: Paid, Unpaid, Overdue, Void), invoice_amount__c, tax_amount__c, due_date__c, and paid_date__c. PDF invoice files are re-uploaded as Twenty Files attached to the Opportunity record.

Swivl services attached to a job — line-item descriptions and amounts — merge into the Opportunity amount field if single-service, or into a custom services_json__c text field capturing the full service breakdown as JSON when multiple line items exist. We preserve the original service descriptions as a text audit trail on the Opportunity.

Swivl owner_id and technician_id fields resolve by email match against Twenty workspace members. FlitStack flags any Swivl owner with no matching Twenty user before migration so the team can invite them or reassign records to a fallback user. This prevents orphaned Opportunity records with unresolvable owner relations.

Swivl activity records (call logs, email threads, meeting notes) migrate as Twenty Tasks and Notes with original timestamps, owners, and parent-record links preserved. Tasks carry the activity subject and type; detailed body content migrates as a Note attached to the related People or Opportunity record. This preserves the full service communication history.

Swivl file attachments on jobs, invoices, or customer records re-upload to Twenty Files and attached to the target record. File size limits and inline image handling follow Twenty's upload constraints. We preserve the original filename and content type as metadata on each uploaded file.

If Swivl Tech stores custom objects (e.g., Equipment, Warranty, Recurring Service Contract), those map 1:1 to Twenty custom objects. Custom object associations that use N:N relationships in Swivl require junction objects in Twenty. We document the relationship structure during the audit phase and surface any many-to-many mappings in the migration plan before data lands.