Migrate from WorkBuddy to Twenty CRM

WorkBuddy Jobs are work orders, not sales opportunities. The migration requires an explicit architectural decision: Jobs can become Opportunities (name → Name, budget_amount → Amount, job_status → StageName) or a custom work_order object if the team needs to preserve job-specific fields that don't fit Opportunity semantics. FlitStack surfaces this decision before the migration runs.

Each WorkBuddy Work Order maps 1:1 to a Twenty Opportunity. Work Order name → Opportunity.name, scheduled_start → CloseDate (or a custom date field), assigned_technician → OwnerId via email resolution against Twenty workspace members. Work Order status maps to Opportunity stage via value_mapping. Work Order properties that don't map directly become custom fields on the Opportunity.

Subcontractors are people records in Twenty — name → name, email → email, phone → phone, company → companyId (lookup to Company record). Subcontractor trade_specialty becomes a custom pick-list field on the People record. License_number and insurance_expiry migrate as custom text and date fields. Email-matched owners in Twenty receive assignments for migrated Work Orders they were assigned in WorkBuddy.

WorkBuddy customers may exist as Company records (with contact persons) or standalone contact records. The migration creates a Company record for the business and a People record for the primary contact, linking them via the standard companyId relationship. For customers stored as people-only in WorkBuddy, a minimal Company record is created with the person's name as the company name.

Twenty has no native Asset object. FlitStack creates a custom Asset object in Twenty's data model with fields for asset_name, asset_type, location, last_service_date, and a relation to the Company that owns it. Asset-service history maps to Notes or Tasks linked to the Asset record. Custom object creation happens before migration data lands, per Twenty's requirement that fields must exist before CSV import.

WorkBuddy's service-location data (site name, site address, latitude/longitude) has no native equivalent in Twenty. The migration maps site name to Company.name and site address to Company.address fields. Latitude and longitude become custom number fields on the Company record if precision location tracking is required for the field-service workflow.

Work Order notes and instructions become Twenty Notes attached to the related Opportunity. Long-form instructions that represent actionable follow-up items become Twenty Tasks with the Opportunity as the parent record, assigned to the Work Order's original assigned_technician (resolved via email match to a Twenty workspace member).

WorkBuddy safety and compliance data — permits, inspection results, site-risk flags — doesn't fit standard Twenty objects. The migration creates a custom SafetyRecord object with fields for record_type, issue_date, expiry_date, and a relation to the Company or Work Order it belongs to. For simple safety notes, a Note record attached to the Company is the lightweight alternative.

WorkBuddy allows custom properties per work-order type (e.g., trade_category, site_access_instructions, equipment_serial). Each custom property requires a corresponding custom field on the Opportunity object in Twenty's Settings → Data Model before import. Pick-list values map via value_mapping if the custom property has enumerated options; text fields map directly.

Files attached to WorkBuddy Jobs and Work Orders — photos, permits, contracts, site diagrams — are downloaded and re-uploaded to Twenty Files, associated to the parent Opportunity or Company record. File size limits and format compatibility are validated during the sample migration phase. Inline images in notes are extracted and rehosted as separate file records.

WorkBuddy team members are internal staff who may be assigned to Work Orders. They map to Twenty workspace members via email resolution — the WorkBuddy user email is matched against invited Twenty workspace members. Unmatched users are flagged before migration; the team either invites them to Twenty first or assigns their records to a fallback owner.

WorkBuddy time entries tracking labor hours against work orders have no direct equivalent in Twenty's standard model. The migration maps time-entry data to a custom TimeEntry object (if the Professional or Organization tier's custom object quota is available) or as custom number fields on the Opportunity for total_hours and labor_cost. This is preserved for reporting reference even if it doesn't map to a native Twenty workflow.