Migrate from Thulium to Salesforce Service Cloud

Thulium Cases map directly to Salesforce Case records with CaseNumber, Status, Priority, Origin, and Description fields preserved. The Thulium Case ID is stored in a custom field thulium_case_id__c for traceability. Thulium's Case Status (open, pending, resolved, closed) maps to Salesforce Case Status values, which we configure as a Status picklist on the Case object before import. If Thulium uses custom status labels, we build a value-mapping table during scoping and apply it during transformation.

Thulium stores individual email, chat, and voice interactions as sub-objects within a Case rather than as standalone records. We flatten these into EmailMessage records (for email channel), Task records with TaskSubtype=Call (for voice), and Task records (for chat and internal notes) linked to the parent Case via the WhatId field. Each conversation entry's timestamp, author, and content body migrate to the corresponding Salesforce object. The flattened chronological order is preserved by setting ActivityDate on Tasks and CreatedDate on EmailMessage to the original Thulium timestamp.

Thulium CRM Contacts map to Salesforce Contact records. Email, Phone, FirstName, LastName, and custom field values migrate directly. We use Email as the dedupe key during import to prevent duplicate Contact creation. Thulium's Contact-to-Company linkage migrates as the Salesforce Contact.AccountId lookup, resolved after Account records are created. If Thulium stores a contact's primary company as a reference ID, we resolve it against the Account import to populate AccountId at migration time.

Thulium Companies map to Salesforce Account records. Company name becomes Account Name, address fields map to BillingAddress fields, website becomes Account Website, and custom field values map to corresponding custom fields. Account is created before any Contact import so that the AccountId lookup is satisfied at the moment of Contact insert. Thulium's Company ID is stored in a custom field thulium_company_id__c for traceability.

Thulium supports nine custom field types (text, large text, email, numeric, link, list, yes/no, date) across Cases, Contacts, and Companies. We build a field-mapping table per object during scoping that maps each Thulium type to the nearest Salesforce field type (e.g., Thulium list maps to Salesforce Picklist with a value-mapping table; Thulium yes/no maps to Salesforce Checkbox). Large text fields map to Long Text Area with appropriate length validation. This mapping step is required before any data loads and adds a scoping phase to the migration timeline.

Thulium Agents are the user accounts assigned to Cases and Companies. We map Agent records to Salesforce User by resolving the Agent's email address against the destination org's User table. Any Agent without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before Case import begins, because Case.OwnerId requires a valid User ID. Role and profile assignments from Thulium are documented as a configuration recommendation for the Salesforce admin.

Thulium supports tagging Cases for categorization. Tags migrate to Salesforce as either a custom multi-select picklist field on Case (if the customer chooses to consolidate tags into a structured field) or as TopicAssignment records (if the org uses Salesforce Topics for case classification). We apply a value-mapping table for any naming differences and preserve the full tag vocabulary from Thulium.

Files attached to Cases or Contacts in Thulium are exported and re-uploaded to Salesforce as ContentVersion records linked via ContentDocumentLink to the parent Case or Contact. We preserve original filenames, file MIME types, and the attachment-to-record linkage. Large attachments (over 25 MB per Salesforce ContentVersion limit) are flagged during scoping and handed off to the customer for alternative storage (S3, SharePoint) with the link migrated as a URL custom field.

Thulium SLA configurations (response time, resolution time, business hours) do not migrate as Salesforce entitlement rules. We document the existing SLA terms from Thulium in a written configuration guide that the customer's admin uses to set up Salesforce Entitlements and Milestones post-migration. This includes mapping Thulium's SLA tiers to Salesforce Entitlement Processes scoped to the relevant Account or Contact.

Thulium's built-in reporting exports as raw data only; the report configurations (chart types, filters, groupings, schedules) do not have a Salesforce equivalent export format. We deliver a written inventory of every Thulium report and dashboard with its configuration parameters so the customer's admin can rebuild them in Salesforce Reports and Dashboards. We do not migrate report configurations as code or deliver equivalent Salesforce report definitions within the migration scope.