Migrate from BigChange to Twenty CRM

BigChange persons map directly to Twenty People records. Email, phone, job title, and contact status transfer as standard fields. Primary company link resolves via the companyId relation on the Twenty People record. Phone numbers are normalised to an international format, and missing job titles are left blank for manual entry. The companyId must already exist in Twenty before the import.

BigChange company name, domain, industry, address, and employee count map to Twenty Companies. Industry values use value‑by‑value pick‑list mapping since BigChange and Twenty industry taxonomies differ. Parent‑company hierarchy maps to the linked Company record. Annual revenue transfers as a numeric field, and any missing domain is stored as a text note. Circular parent‑company references are detected and flagged before import.

BigChange jobs map to a custom Opportunities‑based object in Twenty with fields: job type, priority, status, schedule date/time, engineer assignment, site location, and the original BigChange job ID as a reference field. The object includes name for job title, jobType__c, priority__c, stage__c, scheduledDate__c, assigneeId, siteLocationName__c, siteAddress__c, accessNotes__c, and sourceSystemId for the original job identifier.

BigChange job status values (Pending, In Progress, On Hold, Completed, Cancelled) map to custom Twenty opportunity stage values. Probability and forecast category are re‑applied based on the new stage set after migration. If a status has no direct counterpart, it defaults to the nearest equivalent stage, with any deviations logged for review.

BigChange quotes (with line items, quantities, and agreed rates) transform into a custom QuoteText field on the related Twenty opportunity, storing the full quote body as structured text. The QuoteText includes item descriptions, unit counts, and agreed prices in a pipe‑delimited format. Quote PDF files and agreed‑rate data are preserved as a reference export for manual re‑entry or later attachment.

BigChange location records store site name, full address, access instructions, and a site contact. Twenty has no native location object, so these fields migrate as structured text custom fields on the job opportunity record for manual reference. The site name appears in siteLocationName__c, the address in siteAddress__c, access notes in accessNotes__c, and the site contact in a dedicated siteContact__c field.

BigChange asset records (name, type, serial number, make/model, installation date, linked location) require a Twenty custom object. The custom Assets object mirrors the BigChange schema with name, assetType__c, serialNumber__c, makeModel__c, installationDate__c, and linkedLocation__c fields. Asset‑to‑job linkage is stored as a text reference in a jobAssetRef__c field on the job opportunity.

BigChange invoices and credit notes have no CRM‑native equivalent in Twenty. We export these as a structured CSV reference file preserved for the finance team to migrate separately or re‑enter in an accounting tool. The CSV includes invoice ID, date, customer name, line‑item description, quantity, unit price, total amount, and payment status for comprehensive reference.

BigChange notes attached to persons, companies, or jobs migrate as Twenty Notes. Attachments are re‑uploaded to Twenty Files using the original file name and MIME type. Original timestamps and author attribution are preserved where available from BigChange, stored in the note’s createdAt and createdBy fields for audit trail continuity.

BigChange users and job‑assigned engineers resolve by email against Twenty workspace members. Unmatched users are flagged before migration so the team can invite them to Twenty first or assign records to a fallback owner. All resolved owners receive a migrationOwner mapping to preserve original accountability across the dataset.

BigChange custom properties on any object (persons, companies, jobs, locations) create custom fields in Twenty. Field type conversions apply where BigChange types (e.g., multi‑select) differ from Twenty’s available field types. Each custom field is created in the target object, and pick‑list values are translated using a value‑by‑value mapping table to maintain consistency.