Migrate from osTicket to Salesforce Service Cloud

osTicket Ticket maps 1:1 to Salesforce Case. We resolve osTicket ticket number to Case CaseNumber, ticket status (Open, Closed, Archived) to Case Status, priority (Low, Medium, High, Emergency) to Case Priority, and created datestamp to Case CreatedDate. The Help Topic assignment becomes a custom picklist field case_help_topic__c. SLA Plan assignment migrates to a custom field case_sla_plan__c and is also used to assign an Entitlements Process at migration time. Thread history (the merged HTML blob) is split and mapped separately to CaseComment records with isPublished set to true for customer-facing responses and false for internal notes.

osTicket stores all ticket conversation history — customer replies, agent responses, and internal notes — as one merged HTML blob per ticket. We split each blob at migration time by parsing the rendered-thread structure and identifying the CSS class markers that osTicket applies to each segment type. Each segment maps to a separate Salesforce CaseComment record with the correct isPublished flag: true for messages visible to the customer, false for internal agent notes. Author name, author email, and segment timestamp are preserved in the CaseComment CommentBody and the system InsertedById. Thread-splitting logic is version-sensitive to the osTicket release and is validated against a sample of 10-20 tickets before the full migration runs.

osTicket Users (end customers who submit tickets) map to Salesforce Contact records. We use email address as the dedupe key. Name, email, phone, and address fields map directly. The osTicket Organisation linkage maps to a Contact.AccountId lookup once Account records have been created from osTicket Organisations. Users without an Organisation in osTicket (orphaned records) are flagged in the scoping report and imported as Contacts without an Account link, pending the customer's decision to link them post-migration.

osTicket Organisations map to Salesforce Account. Organisation name becomes Account Name, website becomes Account Website, and phone becomes Account Phone. osTicket allows Organisations to exist without linked Users, so we import Organisations first as parent records, then resolve Contact.AccountId during the Contact import phase. If two osTicket Organisations have identical names, we merge them into a single Account and flag the merge in the reconciliation report.

osTicket Agents are mapped to Salesforce User records by email match. The migration cannot create new Salesforce Users — only an active Salesforce admin can provision user accounts — so we extract all agent email addresses, match them against the destination org's User table, and place any unmatched agents in a reconciliation queue. Agent department assignments are preserved as a custom field agent_department__c on the User record for queue routing configuration after migration.

osTicket Departments control ticket routing and agent permissions. We map each Department to a Salesforce Queue with the Case object as the supported type. Queue membership is populated from the agent list assigned to each osTicket Department. Department SLA Plan associations are preserved as case_sla_plan__c field values and also used to set Entitlements Process on the Case. If osTicket has more than 10 departments, we recommend a naming convention consolidation with the customer during scoping.

osTicket custom fields of type text, boolean, date, list, and integer map to equivalent Salesforce custom fields on the Case object. We pre-create the Salesforce custom fields (with __c suffix and appropriate field types) in the destination org before any data loads. Picklist-type custom fields in osTicket become picklist or multi-select picklist fields in Salesforce with their values explicitly whitelisted. osTicket required custom fields on ticket forms are temporarily set to optional during migration to avoid blocking ticket imports, and we restore the required flag post-migration if requested.

osTicket user-level custom fields (phone numbers, account numbers, preferences) map to Salesforce custom fields on the Contact object. We pre-create these during schema setup. The same required-field handling applies as for ticket custom fields.

osTicket SLA Plans define response and resolution hour windows tied to priority. We migrate SLA plan names and time windows as a custom picklist field case_sla_plan__c. For organisations on Service Cloud Professional or above, we also configure an Entitlements Process with Milestones matching each osTicket SLA plan's response and resolution time. This is a configuration step that the customer's Salesforce admin reviews before migration runs, as it requires Business Hours to be set in the destination org.

osTicket Help Topics are ticket categories that drive routing and SLA assignment. They map to a custom picklist field case_help_topic__c on Case. If the customer uses multiple distinct routing or SLA configurations, we recommend creating Salesforce Case Record Types per Help Topic during scoping, each with its own Page Layout and Entitlements Process. The customer chooses the strategy during the discovery call.

osTicket attachments are stored separately from the thread record and linked by attachment ID. We extract attachment records alongside ticket data, upload each file as a Salesforce ContentVersion (storing the binary and filename), then link it to the parent Case via a ContentDocumentLink record. Files attached to internal notes use ContentDocumentLink with linkType set to Link for visibility control. We handle file type validation against Salesforce's allowed ContentVersion types and flag any unsupported file types (e.g., .exe) in the reconciliation report.

osTicket ticket status values (Open, Pending, Resolved, Closed, Archived) map to Salesforce Case Status picklist values. We align the osTicket status lifecycle with the Salesforce case lifecycle during mapping. Any osTicket statuses that have no Salesforce equivalent (e.g., Archived) are mapped to the Closed status family and flagged in the mapping notes for the customer's admin to split further if needed.