Migrate from DeskDay to Salesforce Service Cloud

DeskDay Tickets map to Salesforce Case records. The ticket subject becomes Case Subject; the conversational thread becomes EmailMessage records attached to the Case; ticket status (Open, Pending, Resolved, Closed) maps to Salesforce Case Status values which we configure to match DeskDay's status vocabulary. Priority maps to Case Priority. Custom ticket fields migrate as custom Case fields with equivalent data types. The ticket created_date and last_modified_date become Case CreatedDate and LastModifiedDate to preserve historical timestamps.

DeskDay end-user contact records (name, email, phone, company association) map to Salesforce Contact records. We preserve the DeskDay contact ID as a custom field deskday_contact_id__c for cross-reference. The primary contact on a DeskDay ticket becomes the Case's ContactId via email matching. End users without email are imported as Contacts without email addresses and flagged for admin verification.

DeskDay Client Organizations representing each MSP customer map to Salesforce Account records. The client name becomes Account Name; domain or website maps to Account Website. Service tier and SLA level associated with the DeskDay client organization are stored as custom fields on the Account (e.g., sla_tier__c, client_region__c). Account is created before Contact import so that the AccountId lookup is satisfied at Contact insert time.

DeskDay agent records (name, email, role, team assignment) map to Salesforce User records. We match DeskDay agents to existing Salesforce Users by email during scoping. Agents without a matching User go to a reconciliation queue for the customer's admin to provision before record migration resumes. OwnerId on migrated Cases points to the resolved Salesforce User.

DeskDay team-based ticket routing maps to Salesforce Queue records (for Cases) or Groups. We create a Queue per DeskDay team during schema configuration, set the queue's Case assignment routing model, and update the Case OwnerId references during migration to point to the correct Queue. Team membership is preserved via Group membership on the Salesforce side.

DeskDay custom ticket fields require field-level mapping because DeskDay's custom field schema is still evolving and field types (text, number, dropdown, date) must be matched to Salesforce field types during destination schema design. We extract the full custom field definition set from DeskDay, map each to a Salesforce Case custom field of equivalent type, and flag any DeskDay field types with no Salesforce equivalent for admin decision during scoping. Custom field values on existing tickets are migrated as part of the Case import.

DeskDay KB articles with title, body content, and category assignments map to Salesforce Knowledge Article records of a defined Article Type. Article view counts, feedback ratings, and internal publication status from DeskDay migrate as custom fields on the Salesforce article because these metadata fields have no native Salesforce Knowledge equivalent. We preserve the article-assignment category hierarchy using Salesforce Data Category Groups configured during schema setup.

DeskDay tags on tickets (flat label arrays) have no native Salesforce equivalent because Salesforce does not have a global tag object. We offer two migration strategies during scoping: a custom multi-select picklist field on Case (suitable for a bounded tag vocabulary under 150 values), or Salesforce Topics with TopicAssignment records (suitable for unbounded or evolving tag sets). The customer selects the strategy before migration begins.

DeskDay stores ticket file attachments in its own cloud with internal URL references that are not portable. We download all ticket attachments from DeskDay, re-upload them to Salesforce as ContentDocument records linked to the migrated Case via ContentDocumentLink, and update the Case record with the new attachment reference. Attachment count and total size are factored into migration timeline estimates because re-upload processing scales with volume.

DeskDay SLA policies (business-hours definitions and escalation rules) map to Salesforce Entitlement Management objects: Entitlement Processes define the SLA milestones (First Response, Resolution) and times; Entitlements link the process to the Account. We migrate SLA target durations and business-hours definitions as Entitlement Process configuration records. Any SLA targets tied to DeskDay custom date fields require field remapping to the Salesforce entitlement milestone start time field.

DeskDay reporting data is generated at query time from ticket and agent activity logs rather than stored as independent report records. We do not migrate report definitions. We deliver a written inventory of DeskDay report types, metrics, and filter criteria for the customer's admin to rebuild using Salesforce Reports and Dashboards or a BI tool post-migration. Historical summary data can be exported from DeskDay as a CSV and loaded into a custom Report object if needed.