Migrate your Deepser data

Service Requests are Deepser's primary ticket object. Every request carries fields for priority, status, category, assigned agent, requester customer, and timestamps. We map these 1:1 into the destination's Tickets object, preserving the full status and assignment history.

Change Requests follow the same schema as Service Requests but include an additional change-type classification (Standard, Minor, Major, Emergency). We carry the change-type value as a custom property in the destination to preserve the routing logic customers built around it.

Customers in Deepser 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. Grid exports include the Customer column with ID references that we resolve during import.

Companies in Deepser function as organizational parent records for Customers. We preserve the Company name and link it to the Customer record in the destination, maintaining the hierarchy that ticket assignment and reporting depend on.

Deepser's ITAM module tracks hardware and software assets with fields for serial number, type, location, assigned user, and lifecycle status. Asset types and custom properties vary per installation, so we review the grid export's column set before mapping each field to the destination's asset schema.

Agents are the internal users who receive and resolve tickets. We migrate Agent records with name, email, role, team assignment, and active/inactive status. Deepser requires a minimum of 3 agents on any paid plan, which we note when scoping inbound migrations.

Workflows in Deepser are ITIL-aligned sequences of steps triggered by service requests or change requests. They include approval gates, task assignments, and automated actions. Since workflows encode process logic specific to Deepser's execution engine, we extract the step definitions and map them to the destination's automation objects, flagging any step type that lacks a direct equivalent.

Deepser exposes a Custom Fields module where customers define additional properties on Tickets, Customers, Assets, and other entities. Custom field schemas vary per installation. We discover the full column set from the grid export, identify each field's type (text, dropdown, date, checkbox), and map it to a corresponding custom field in the destination, creating the field definition if it does not exist.

Deepser's reports and dashboards are interactive visualizations with no documented export endpoint. We do not migrate report definitions or dashboard layouts. We recommend exporting the underlying data via the grid export and rebuilding key reports in the destination system using the migrated data.

Deepser supports a knowledge base for publishing internal or customer-facing articles linked to tickets. Article content, categories, and attachment references are accessible through the grid export. We migrate article body text and metadata, but attachments embedded as files in the KB require separate file-handling steps.

Deepser ships with native integrations for Microsoft Teams, NinjaOne RMM, and Datto RMM. These are configuration-based connections rather than data objects. We document the integration settings and reconfigure equivalent connections in the destination system post-migration.

Deepser's billing modules track time-based billing entries linked to tickets and assets. These are scoped by module and include line-item, worklog, movement, and operational billing records. We migrate the record headers and amounts, but note that billing recalculation rules may differ in the destination billing system.