Migrate from Resco – Mobility & Productivity to Twenty CRM

Resco Account records (mirrored from the underlying CRM) map directly to Twenty Organization. We use the Organization name as the dedupe key during import. If Resco is connected to Microsoft Dynamics 365 or Dataverse, we extract Account records from the parent CRM's API rather than the Resco sync layer, as the Resco export may apply filter conditions that exclude some records. Address, phone, industry, and website fields map to their Twenty Organization field equivalents.

Resco Contact records map to Twenty Contact with a direct 1:1 field mapping for standard fields (name, email, phone, title). The primary Address on Contact migrates to the Twenty address block. Contact ownership resolves by matching the Owner email to the target Twenty User. If Contacts were associated with an Account in the parent CRM, we resolve the Organization ID at migration time before Contact insert to satisfy the Lookup relationship.

Work Order is a first-class Resco Field Service+ entity with no direct Twenty CRM equivalent. Twenty does not include field service management as a standard feature. We work with the customer during discovery to decide whether Work Orders map to a custom WorkOrder object (requiring pre-creation of the schema in Twenty's Data Model) or to Opportunities if the business treats field work as billable projects. Status, assignment, line items, and photos migrate in either case; the schema decision affects downstream reporting and filtering in Twenty.

Work Order line items from Resco Field Service+ require the same schema decision as their parent Work Order. If the customer chooses a custom WorkOrder object, line items become a related custom WorkOrderLineItem object. If Work Orders map to Opportunities, line items map to OpportunityLineItem equivalents using Twenty's opportunityLineItems relation. Part number, quantity, unit price, and description fields transfer directly in either configuration.

Resco inspection templates are Woodford-configured artifacts with branching logic, conditional questions, and scoring rules. These are schema definitions that cannot be exported as data. We extract the template structure (question text, field types, response options, branch conditions) during discovery and document it in a written specification that the customer's admin uses to recreate the template as a Twenty custom object. The inspection response data (actual filled-out forms) migrates as records in the recreated custom object.

Filled inspection forms stored in Resco map to inspection response records in the custom InspectionResponse object we create in Twenty. Each response is linked to the parent Contact (the field worker who completed it) and to the related Work Order if applicable. Question responses, completion timestamps, and GPS capture location migrate as fields. Resco's digital signature field on inspections migrates as a text blob or base64-encoded attachment depending on format.

Location tracking records in Resco are stored in the Mobile Auditing entity with the Owner field set to the initiating user, not to the work order or asset. These records are audit trail artifacts, not operational records. We migrate them as Note records attached to the related Work Order or Contact, preserving the timestamp, user identity, and location coordinates. Customers who need structured location history may prefer a custom activity object with latitude and longitude fields rather than Notes.

Route plans in Resco are optimized sequences of work orders generated by the routing engine. These are runtime configuration artifacts rather than transactional records. There is no migration path for route plan data; the routing logic does not translate to Twenty CRM, which has no native routing engine. We flag route plans during discovery and advise the customer to plan for a third-party routing tool (such as a Maps API integration or a dedicated FSM routing solution) to replace this capability post-migration.

Resco activities synced from the parent CRM (appointments, tasks, calendar events) map to Twenty Task records. Subject, description, due date, assigned user, and status transfer directly. If the customer used Resco's calendar integration with Microsoft Exchange or Google Calendar, we flag this as an integration to re-establish post-migration in Twenty's settings.

Woodford custom entities not mirrored in the parent CRM require explicit schema re-creation in Twenty. We extract the entity definition (field names, field types, picklist values, lookup relationships) from the Resco project export during discovery and use it to pre-create the equivalent Twenty custom object via Twenty's Data Model settings before any data import. Any lookup relationships to standard entities (Account, Contact) must be resolved to their Twenty equivalents before the custom object import runs. Entities without a clear Twenty counterpart require a re-modeling decision with the customer.

Resco stores documents locally or routes them to external services (Dropbox, Google Drive, OneDrive, SharePoint). We migrate attachments linked to CRM records as Twenty attachment records. If the customer used SharePoint routing from a Dynamics 365 environment, we recommend re-establishing SharePoint or an alternative external storage connection in Twenty post-migration, as Twenty does not have a native SharePoint integration at this stage. Standalone local files stored only in Resco require explicit extraction before the migration window.

Resco user records reference the underlying CRM user identity. When migrating from a Dynamics 365 or Salesforce parent CRM to Twenty, user IDs and ownership assignments must be re-mapped to Twenty User records. We resolve owners by email match. Any Resco user without a matching Twenty User is held in a reconciliation queue for the customer to provision before record import resumes, as OwnerId references are required on most standard object inserts.