Migrate from Deepser to Salesforce Service Cloud

Deepser Service Requests map directly to Salesforce Case. The request's priority, status, category, assigned agent, requester customer, and timestamps migrate as corresponding Case fields. Deepser's requester Customer record links to the migrated Contact in Salesforce, establishing the WhoId on Case. We validate required fields (Status, Priority, Origin) against the destination org's field-level security before migration.

Deepser Change Requests follow the same schema as Service Requests but include a change-type classification (Standard, Minor, Major, Emergency). Salesforce has no native change-type field on Case, so we create a custom picklist field ds_change_type__c to carry the original Deepser value. The Record Type distinguishes Change Request cases from standard Service Request cases. We preserve change-type values during scoping so the custom picklist is configured before migration begins.

Deepser Customers (requester entities linked to tickets) map to Salesforce Contact. The full contact card migrates including name, email, phone, company association, and any custom fields defined on the Customer module. Deepser's company link becomes the AccountId lookup on Contact, which is resolved after the Account import phase. Custom field schemas vary per Deepser installation; we discover the full set during scoping and map each to a typed Salesforce field.

Deepser Companies function as organizational parent records for Customers. The Company name migrates to Salesforce Account Name, and the account hierarchy is preserved by resolving parent-company lookups at migration time. Company-level custom fields (industry classification, contract tier, etc.) map to Salesforce Account custom fields. Account is created before Contact import so that the AccountId lookup is satisfied at the moment of Contact insert.

Deepser IT Assets (hardware and software tracked in the ITAM module) map to Salesforce Asset records with serial number, type, location, assigned contact, and lifecycle status. Deepser custom asset properties vary per installation; we discover the full custom field schema during scoping and create matching Salesforce custom fields on Asset before migration. Asset-to-Contact assignments resolve against the Contact mapping so that the ContactId reference is satisfied.

Deepser Agents (internal users who receive and resolve tickets) map to Salesforce User records. We resolve by email match against the destination org's User table. Agents without a matching Salesforce User enter a reconciliation queue; the customer's admin provisions missing Users before record migration resumes. Deepser's role and team assignments map to Salesforce Profile, Role, and Queue membership.

Deepser knowledge base articles (internal or customer-facing content linked to tickets) export through the grid. Article content, categories, and URL-name references migrate and are re-created in Salesforce Knowledge. Salesforce requires Knowledge to be enabled and configured with Article Types before import; we scope this during the destination configuration phase. The customer reviews article categorization and assigns Salesforce article types during validation.

Deepser custom field schemas vary per installation and exist across multiple modules. During scoping, we discover the full custom field inventory (field name, data type, applied-to module) and map each to the corresponding Salesforce field type. Salesforce custom fields are created in the destination org before any data import begins. The mapping document is reviewed and signed off during the sandbox migration phase.

Deepser ITIL-aligned workflows (sequences of approval gates, task assignments, and automated routing triggered by service or change requests) do not migrate as Salesforce Flow. The workflow definitions and step types are documented during scoping, and we deliver a written inventory with each step's trigger, conditions, actions, and recommended Salesforce Flow equivalent. The customer's admin or a Salesforce partner rebuilds workflows in Flow Builder or Omni-Channel post-migration.

Deepser SLA records define response-time and resolution-time thresholds linked to ticket categories and priority levels. Salesforce Entitlement Management handles SLA tracking through Entitlement Processes and Milestones attached to Contacts or Accounts. We document the existing SLA thresholds, business hours, and assignment rules and deliver a written recommendation for rebuilding them in Salesforce Entitlement Management. Rebuild is outside migration scope.