Migrate from OTRS to Salesforce Service Cloud

OTRS Tickets map directly to Salesforce Cases. We extract ticket_id, title, ticket_number, state_id, priority_id, queue_id, customer_id, owner_id, create_time, change_time, and escalate_time from the ticket table during direct database read. The OTRS State (open, closed, pending, merged) maps to Salesforce Status using a state-type mapping table we build during scoping. Article history from the article table migrates as CaseComments and EmailMessages on the Case. We set CaseOrigin to 'Phone' for OTRS phone-channel tickets and 'Web' for portal tickets to preserve channel attribution.

OTRS Articles represent individual communication entries (emails, notes, external replies) linked to a Ticket. Each article has a content_type, sender_type (agent/customer/system), subject, body, and create_time. We split articles by sender_type: agent and system notes migrate as internal CaseComments (IsPublished=false); customer-facing emails and portal replies migrate as EmailMessage records linked to the Case with FromAddress and ToAddress preserved. Email bodies in HTML format are stored with ContentType set accordingly. We enumerate all content_types during scoping to ensure attachments and inline images are correctly parsed.

OTRS Customer records contain contact fields (firstname, lastname, email, phone, company) and user preferences. Customers with an email domain that maps to a known organization merge into a Salesforce Account with the Contact as a child record. Customers without an organization link import as individual Contacts without an Account. We preserve the OTRS customer_id as a custom field otrs_customer_id__c for cross-reference. The OTRS CustomerUser login mapping is noted for identity reconstruction if Experience Cloud portals are in scope.

OTRS Dynamic Fields are entity-attribute-value rows stored in dfv tables, each with a field name, type (Text, Date, Dropdown, Multiselect, Checkbox, DateTime), and value storage. We enumerate all defined Dynamic Fields during scoping, map each to a typed Salesforce custom field on Case (or on Contact/Account if the field scope is broader), and handle EAV value storage by pivoting rows into column values at migration time. Dropdown Dynamic Fields map to Salesforce picklists with the OTRS PossibleValues list as the picklist value set. Multiselect maps to multi-select picklist.

OTRS Queues define ticket routing, access boundaries, and SLA assignments. We export queue names, the assigned SLA, and the queue-to-agent group mapping. Each OTRS Queue maps to a Salesforce Queue of the Case object type, and queues with complex SLA routing map to Omni-Channel Routing configurations with Skills-Based Routing if the customer licenses that feature. Queue-to-Group email addresses map to Salesforce Case Origin and Email-to-Case routing configurations.

OTRS Agents are tied to roles, groups, and queues via separate permission tables. We export agent records (firstname, lastname, email, valid_until) and reconstruct ownership and assignment relationships by resolving the OTRS user_id to Salesforce OwnerId via email match. Agents without a matching Salesforce User go to a reconciliation queue for admin provisioning before record import resumes. Role and group memberships that have no Salesforce equivalent (such as OTRS role-based restrictions) are documented as a permission matrix for the admin to rebuild.

OTRS SLA definitions link response_time and solution_time thresholds to queues and ticket types. We export SLA names, calendar definitions, and escalation thresholds as Entitlement records in Salesforce tied to the Account or Contact. FirstResponse and Resolution milestones are created from the SLA thresholds with the OTRS escalate_time values as the target completion timestamps. OTRS escalation history (escalation events, warning triggers) migrates as EntitlementHistory records for audit completeness.

OTRS Configuration Items are CMDB entries with a class-based schema (Hardware, Software, Network, Document) and custom properties. We export CI data and the ci_ticket_link table. Large-scale CMDB migrations (over 5,000 CIs) we handle as a separate import pass: each CI class maps to Salesforce Asset with Class mapped to Asset Type, and CI-to-Ticket linking table reconstructs as AssetId on Case. For smaller CMDBs we deliver a CI inventory spreadsheet for manual Asset creation post-migration. This decision is made during scoping based on CI volume and customer admin capacity.

OTRS Process Management stores workflow definitions as XML with activity nodes, transition rules, and conditional branching across multiple tables (process, activity, transition). We export the complete workflow structure, activity sequence, and conditional logic as a written Process Inventory document. This document is delivered to the customer's Salesforce admin or implementation partner to rebuild using Salesforce Flow. We do not migrate OTRS workflows as Salesforce Flow as standard scope because the XML structure and trigger model differ fundamentally.

OTRS Services define available offerings linked to SLAs and queues. Services with a defined service catalog interface map to Salesforce Custom Objects with a Knowledge-driven service catalog if the customer licenses Salesforce Knowledge. Services without catalog intent migrate as data records linked to Entitlements. The OTRS service-to-SLA association is preserved as a custom lookup field on the service record.

OTRS attachments are stored as binary blobs in the article_attachment table with filename, content_type, and content_size. We extract each blob, create a ContentVersion record with VersionData set to the blob binary and FileType inferred from MIME type, then link it via ContentDocumentLink to the parent Case and CaseComment. Inline images embedded in HTML article bodies are extracted as separate ContentDocument records with the article body rewritten to reference the ContentDocument URLs post-migration.