Migrate from Mobile Service App to Twenty CRM

Mobile Service App customer contacts migrate to Twenty People records. Email, phone, name, and address fields map directly. The contact type is stored as a custom pick-list field (Contact_Type__c) on the People record since Twenty uses a single object for all individuals.

Technician contacts map to Twenty People records and are matched to Twenty workspace members by email. Unmatched technicians are flagged for admin review before migration. Technician-specific fields (certifications, service areas) migrate as custom fields on the People record. These custom fields are created in Settings → Data Model prior to import to ensure compatibility.

Mobile Service App customer companies map directly to Twenty Companies. Address fields, industry, employee count, and domain map directly. Parent-child company hierarchies use Twenty's Parent_Company__c relation field. If your data includes subsidiary relationships, we also preserve the original company IDs as a custom field for audit trail and future reconciliation.

Jobs require a Twenty custom object since Twenty has no native work-order or service-call entity. We create Service_Job__c with fields for job number, status, priority, scheduled date, completed date, service type, and description. The technician assignment links via a Workspace_Member__c relation; customer and company link via Company and People relations.

Mobile Service App job stages (e.g., Scheduled, In Progress, On Hold, Completed, Cancelled) map to a custom pick-list on Service_Job__c. Stage probabilities are stored as a custom field for pipeline reporting. If Twenty's workflow builder is used to drive stage transitions, the pick-list values must match the workflow trigger conditions.

Job descriptions and internal notes migrate as Twenty Notes attached to the Service_Job__c record. Original timestamps are preserved in a custom Date_Time__c field on the Note. Rich-text formatting is converted to Twenty's supported note format. If any note contains embedded images or attachments, we store those as file URLs and re-link them after migration.

Invoices require a custom object since Twenty has no native billing entity. We create Invoice__c with fields for invoice number, amount, status, invoice date, due date, and notes. The customer link uses a Company or People relation field. Payment status is stored as a custom pick-list field.

Equipment profiles (serial numbers, manufacturer, model, location) migrate as Twenty's Equipment__c custom object. Each equipment record links to the customer Company via a relation field. Location address maps to a custom address field on the equipment record. During migration, we verify that each equipment's company link resolves to an existing Twenty Company record, updating any broken references before final import.

Mobile Service App scheduling tasks and reminders map to Twenty Tasks. Due date, assignee, status, and subject map directly. Completed task history migrates as completed Tasks with original completion timestamps preserved as a custom datetime field. If the source includes recurring tasks, we flatten each occurrence into a separate Task record to maintain the full activity timeline in Twenty.

Any Mobile Service App custom fields not covered by standard mappings become Twenty custom fields. We create these in Settings → Data Model before migration runs. Field types (text, number, date, pick-list, relation) are matched to Twenty's supported types. Custom pick-list fields require value lists to be pre-created.

Job photos, equipment images, and attached documents from Mobile Service App are re-uploaded to Twenty's file storage or stored as URL references. File size limits on Twenty's storage infrastructure apply — large files may require compression before import. We also verify file integrity after upload to prevent data loss.

Scheduling rules, technician routing logic, and automated dispatch workflows do not have a Twenty CRM equivalent. We export the workflow definitions as a JSON reference document and map them to Twenty's workflow builder during the manual rebuild phase. Dispatch rules often require a third-party scheduling tool or custom code.