Migrate from Seraph to Salesforce Service Cloud

Seraph Ticket records map to Salesforce Case. The mapping requires schema discovery from Seraph export data because field names vary per installation. We identify the ticket identifier, subject, description, status, priority, created date, and last modified date during the discovery phase and map each to the corresponding Salesforce Case field (CaseNumber, Subject, Description, Status, Priority, CreatedDate, LastModifiedDate). Custom Seraph fields migrate as Salesforce custom fields created in the destination org before migration.

Seraph Contact records map to Salesforce Contact. Email address serves as the dedupe key. We resolve the parent Account by matching the contact's domain or company name against Salesforce Account records. If no matching Account exists, we create one. Salesforce Contact's AccountId field is set at migration time once the Account record is available.

Seraph Company or Account records map to Salesforce Account. We use the company name as the dedupe key and create Account records before Contact migration so that the Contact-to-Account relationship is satisfied at insert time. Website, industry, phone, and address fields map directly where present in the Seraph export.

Seraph Agent records map to Salesforce User via email address lookup. The customer's Salesforce admin provisions User records for each agent before migration begins. Any Seraph Agent without a matching Salesforce User goes to a reconciliation queue. OwnerId on Case is set to the resolved User Id. Inactive Seraph agents map to inactive Salesforce Users if historical assignment must be preserved.

Seraph ticket comments and customer replies map to Salesforce CaseComment for public-facing notes or EmailMessage for email-thread content linked to the Case. Comment body, author, and timestamp migrate. If Seraph stores internal notes separately, we flag them as Salesforce InternalNotes via the IsPublished field on CaseComment.

File attachments from Seraph tickets migrate as Salesforce ContentDocument records attached to the parent Case via ContentDocumentLink. We preserve original filename, file extension, and content hash for integrity verification. Files are uploaded via the Salesforce Composite API or Bulk API 2.0 with chunking for files over 12 MB.

Seraph ticket tags or categories that serve as routing or classification signals map to Salesforce Case Origin, Case Type, or a custom multi-select picklist depending on the customer's use case. We define the target field type during scoping based on how the customer uses tags in Seraph.

Seraph custom fields or objects beyond Ticket, Contact, and Account migrate to Salesforce custom objects with equivalent API names and field definitions. We pre-create the destination schema including custom fields, lookup relationships, and validation rules before any data import. The customer validates the schema design in a Salesforce Sandbox before production migration.

Seraph SLA timers and first-response or resolution-time targets do not migrate as active configurations. We document the existing SLA terms from Seraph and map them to Salesforce Entitlement Processes and Milestones in the destination org, which are available from Service Cloud Professional tier. The customer's admin configures and activates these post-migration.

Seraph workflows, ticket routing rules, auto-assignment rules, and SLA escalations do not migrate. These are configuration-layer logic that does not have a direct Salesforce equivalent in a runnable state. We deliver a written inventory of every active Seraph automation with its trigger, conditions, actions, and a recommended Salesforce Flow or Omni-Channel configuration equivalent. The customer's admin or a Salesforce partner rebuilds them post-migration.