Migrate from Deepser to Zendesk

Deepser Service Requests are the primary ticket object and map directly to Zendesk Tickets. The Service Request fields for priority, status, category, assigned agent, requester customer, and timestamps map to Zendesk's standard ticket fields. We carry the original Deepser Service Request ID in a custom ticket field deepser_sr_id__c for audit and cross-reference. Custom fields defined on the Service Request module in Deepser map to Zendesk custom ticket fields, with type alignment (dropdown to single-select, multi-checkbox to multi-select, text to text).

Deepser Change Requests follow the same schema as Service Requests but add a change-type classification (Standard, Minor, Major, Emergency) that has no direct Zendesk equivalent. We create a Zendesk ticket form scoped to Change Requests with a custom single-select field cr_change_type__c carrying the original classification value. The Standard/Minor/Major/Emergency label migrates verbatim, and any Deepser approval-status value maps to a Zendesk custom field for visibility. SLA-linked Change Requests require Zendesk SLA policies to be configured in the destination before migration begins.

Deepser Customers are the requester entities linked to tickets. We migrate the full contact card including name, email, phone, company association, and any custom fields defined on the Customer module. Deepser Customer records that are inactive or marked as deleted in the source are flagged and excluded from the migration set unless the customer requests otherwise. The Deepser customer_id maps to a custom user field deepser_customer_id__c on the Zendesk End User record.

Deepser Companies function as organizational parent records for Customers. We preserve the Company name, domain, and any custom fields defined on the Company module, mapping them to Zendesk Organizations. The Company-Customer hierarchy maps to Organization-Member relationships in Zendesk, which agents use to view all tickets belonging to the same organization. Deepser's Company-level SLA and contract fields map to custom Organization fields in Zendesk if present.

Deepser Agents migrate to Zendesk Agents with name, email, role, team assignment, and active/inactive status preserved. Deepser requires a minimum of 3 agents on all paid plans, which affects source-side scoping but does not constrain the Zendesk destination. We resolve Agent email addresses as the dedupe key and create Zendesk user accounts with the matched email. Any Deepser Agent without a matching Zendesk email goes to a reconciliation queue for the customer's admin to provision before the ticket import phase.

Deepser IT Assets track hardware and software with fields for serial number, type, location, assigned user, and lifecycle status. Zendesk has no native ITAM module. We create a Zendesk Custom Object (available on Suite Team and above) to hold asset records, with the asset_type, serial_number, location, assigned_user, and lifecycle_status fields mapped to typed Custom Object fields. If the customer also uses a dedicated ITAM tool post-migration (ServiceNow, Freshservice, NinjaOne), we map to a Custom Object with lookup fields rather than a standalone asset module to preserve future connectivity.

Deepser Custom Fields defined on Tickets (Service Requests, Change Requests), Customers, and Assets vary per installation. During discovery, we enumerate every custom field in use and map each to a Zendesk equivalent by type: Deepser text fields map to Zendesk text, dropdowns to single-select, multi-checkbox to multi-select, dates to date fields, and numeric fields to integer fields. Custom field schemas are deployed into the Zendesk destination before any record import begins. Any custom field that has no direct Zendesk equivalent is stored as a text field and flagged in the mapping document.

Deepser knowledge base articles with categories, content, and attachment references migrate to Zendesk Guide. Deepser article categories map to Zendesk Guide Sections and Categories. Article body content migrates as HTML, with inline images transferred as file attachments and re-linked in Zendesk. Article author, publication status, and attachment references are preserved in Zendesk article metadata fields. Draft or archived articles in Deepser migrate with the same status in Zendesk Guide. Note that Zendesk Guide is a separate product add-on that must be activated before migration; we coordinate activation timing with the customer during scoping.

Deepser report definitions and dashboard layouts are stored internally with no export capability. We do not migrate report definitions or dashboard layouts. We recommend exporting the underlying ticket and asset data that feeds each report before migration so the customer has the source data available for rebuilding in Zendesk Explore. We deliver a written report inventory document listing every Deepser report by name, the data sources it references, the filters applied, and the intended output, so the Zendesk admin can rebuild each one systematically.

Deepser ITIL Workflows are sequences of steps triggered by Service Requests or Change Requests, including approval gates, task assignments, and conditional routing. They encode organization-specific change-management logic that cannot be mechanically translated to Zendesk's trigger and automation model. We do not migrate Workflows as automation code. We deliver a written workflow inventory listing every active Deepser workflow by name, trigger condition, step sequence, approval chain, and SLA linkage, with a recommended Zendesk Trigger or Automation equivalent for the customer's admin to rebuild. Priority is given to workflows linked to SLA compliance or mandatory approval chains.