Migrate from Oracle Field Service Cloud to Twenty CRM

Oracle activities (calls, site visits, deliveries) map to Twenty Tasks. Original activity type becomes a custom field (activity_type__c) on the task. Owner is resolved by email match to a Twenty workspace member. Create date and completion timestamp are preserved as custom datetime fields.

Oracle activity notes and outcome descriptions migrate to Twenty Notes attached to the related Person or Company record. This preserves the rich text narrative from each service event alongside the Twenty Task entry for complete activity history. The notes migration captures technician comments, customer feedback, and any unstructured text recorded during the service visit, ensuring that no narrative detail is lost in the migration.

Oracle Resources (technicians, crews, vehicles) convert to Twenty People records. Email, phone, and name map directly. Skills, certifications, and territory assignments migrate as custom fields on the People object since Twenty's standard People fields cover contact data only. The migration also preserves resource type classification (technician, crew, vehicle) as a custom field to maintain operational context in Twenty's CRM environment.

Oracle Work Orders have no direct Twenty equivalent — a custom Work_Order object must be created in Twenty Settings → Data Model before migration. Status, type, priority, scheduled date, completion date, and linked resource map as custom fields on the Work_Order object. Work Order links to the Company (customer location) and the People record (assigned technician).

Oracle Work Order status values (Pending, In Progress, Completed, Cancelled, On Hold) are pick-list values that require explicit mapping to the corresponding pick-list in the Twenty Work_Order custom object. Status transition timestamps migrate as custom datetime fields for audit continuity.

Oracle stores detailed service descriptions and parts used on each work order. These map to custom text or multi-select fields on the Work_Order object. If the work order has multiple line items, a separate related table may be needed as a second custom object — this is surfaced in the migration plan.

Oracle Locations (customer service sites, property addresses) map to Twenty Companies. Name, street, city, state, postal code, and country map directly. Geographic coordinates (latitude/longitude) from Oracle migrate as custom number fields since Twenty's standard Company object does not include location coordinates.

Oracle assigns activity types to every activity record (e.g., Installation, Repair, Inspection, Delivery). Twenty Tasks have no native activity-type field — we create a custom select field (activity_type__c) on the Task object and map each Oracle type value to the corresponding pick-list option.

Oracle records an outcome code for each activity (e.g., Completed Successfully, Rescheduled, No Access, Escalated). This maps to a custom select field (outcome_code__c) on Twenty Tasks. Outcome timestamps also migrate as custom datetime fields. The outcome code migration preserves the full resolution status history for each service activity, enabling reporting on first-call resolution rates and patterns in Twenty's analytics without requiring custom reports to reconstruct the outcome chain.

Oracle Resources carry skill profiles and certification expiry dates that drive routing eligibility. These map to custom multi-select (skills__c) and custom date (certification_expiry__c) fields on the corresponding Twenty People record. The skill profile migration captures all certified competencies, specializations, and training certifications for each technician, ensuring that workforce capability data remains available for future scheduling decisions even though the native scheduling engine does not migrate.

Oracle's capacity and quota groups define how technician availability is modeled. These map to custom fields on the People record (capacity_group__c, weekly_capacity_hours__c) to preserve routing-eligibility context in Twenty even without the scheduling engine. The capacity data migration captures weekly working hours, availability windows, and group assignments that determine which technicians are eligible for specific job types and service areas.

Oracle file attachments (photos, signed forms, service reports) attached to activities and work orders are downloaded and re-uploaded to the corresponding Twenty record (Task or Work_Order). File size limits of the destination environment apply; large files may need compression before re-upload.

Oracle's internal resource_id, activity_id, and work_order_id are stored in a custom source_id__c field on each migrated record. This enables delta-run de-duplication, traceability back to Oracle, and rollback identification if reconciliation fails. The source ID migration also supports audit compliance by maintaining a direct reference link between Twenty records and their original Oracle counterparts for regulatory review and data governance purposes.

Any Oracle custom objects beyond the standard Activity, Resource, Work Order, and Location set map 1:1 to Twenty custom objects. The migration plan documents each custom object's field list and relationship structure so the corresponding Twenty custom object can be created before import runs.