Migrate from Oracle Field Service Cloud to HighLevel

Oracle FSC Activities map directly to HighLevel Tasks. Activity date windows, status, activity type, and description fields carry over. Assigned technician becomes the Task owner via email-matched user lookup. SLA fields are stored as custom datetime fields in HighLevel since no native SLA object exists.

Oracle FSC Work Orders carry detailed job data — SLA type, priority, parts required, billing code. These map to HighLevel Opportunities (for billable jobs in the pipeline) or Tasks (for operational follow-ups). Billing amounts map to Opportunity Monetary Value. SLA compliance status becomes a custom field on the Opportunity.

Oracle FSC Customer records (person-level entities) map to HighLevel Contacts. Customer name, email, phone, address, and communication preferences carry over as standard Contact fields. Primary company link creates a Contact-to-Company relationship in HighLevel. During migration, customer records are matched by email address to identify existing contacts and prevent duplicates in the target system.

Oracle FSC Locations (service-site records) map to HighLevel Companies. Location name, address, service territory, and account number fields map to Company Name, address fields, and a custom Account_Number__c field. Locations linked to multiple customers aggregate to a single Company with multiple Contact associations.

Oracle FSC Resources (technicians, fleet assets) do not have a direct HighLevel equivalent. Technician records migrate as Contacts with a Role field set to 'Field Technician' and skill-set data stored in custom fields (Skill_Set__c, Work_Zone__c, Certification__c). Active/inactive status maps to Contact.archived.

Oracle FSC Buckets (work grouping containers for scheduling) have no HighLevel equivalent. We create a Work_Bucket__c custom object with Name and Description fields. Bucket-to-activity assignments are preserved as a lookup field on the Task. Bucket priority and capacity fields become custom numeric fields.

Oracle FSC inventory tracking for parts, stock levels, and bin locations migrates as a Parts_Inventory__c custom object with Part_Number__c, Description__c, Quantity_On_Hand__c, and Bin_Location__c fields. Each inventory item is linked to related Work Orders through a lookup relationship. Inventory usage history from work orders is preserved as a related list on the Opportunity or Task, maintaining the connection between parts consumed and the jobs they were used for.

Oracle FSC Capacity Areas and Quota records govern technician availability windows per skill and geography. HighLevel has no capacity management module. Capacity area labels migrate as text custom fields on the Contact record; time-window quotas are documented for rebuilding in HighLevel Workflows as availability-based routing logic.

Oracle FSC maintains comprehensive activity history including status transitions, route changes, and completion notes. Each history event converts to a timestamped Task Note entry in HighLevel for audit purposes. Status-change events are also captured as custom datetime fields like Completed_At__c to preserve reporting continuity. This approach ensures all historical context transfers while maintaining a searchable audit trail in the new system.

Oracle FSC file attachments on Activities or Work Orders—including photos, signatures, inspection reports, and PDFs—are downloaded and re-uploaded to HighLevel's file storage, linked to the corresponding Task or Opportunity record. Original file names and attachment timestamps are preserved during transfer. Inline images in activity notes are extracted and re-hosted within HighLevel's file system. File size limits and supported formats follow HighLevel's storage conventions.

Oracle FSC custom objects defined in the OFSC data model map 1:1 to HighLevel Custom Objects. Custom object fields migrate as corresponding Custom Object custom fields. Relationship fields that use Oracle FSC's lookup model map to HighLevel relationship fields on the same Custom Object type.

Oracle FSC Service Requests linked to activities are mapped as Tasks with a custom Service_Request_ID__c field that preserves the source system ID for traceability. Request type, urgency level, and resolution summary transfer to custom fields Task_Type__c and Resolution__c on the HighLevel Task. Each Service Request's linked Activity reference is maintained through the Task relationship, ensuring complete audit continuity between the source and target systems.