Migrate your Desk365 data

The core object in Desk365. Tickets carry standard properties (Status, Priority, Created/Updated timestamps, Assignee, Requester) plus optional Custom Fields. Both open and closed Tickets export cleanly. We preserve SLA breach timestamps if they exist as computed metadata.

Customer records in Desk365 represent ticket requesters. They carry name, email, company association, and portal access status. We map them 1:1 to the destination's Contact/Customer object and preserve any linked Company where the destination supports it.

Agent records include display name, email, department membership, role (Admin/Agent), and active/inactive status. We replicate Agent assignments on Tickets during migration and map role labels to the destination's equivalent permission model.

Desk365 organizes agents and email routing into Departments with configurable access levels (global, department-only, agent-only). We replicate the full department hierarchy and attach each Agent to their correct Department on the destination side.

Articles have a publish status (Draft/Published), visibility flag (Agent-only vs. public on the Support Portal), and folder structure. We migrate all articles and preserve visibility; however, destination platforms may not support the same Agent-only/KB-category distinctions, so we map folders to the closest available structure and flag any unsatisfied visibility rules.

SLA Policies define First Response and Resolution time targets tied to Priority level and Business Hours schedules. We map SLA Policy names and their time thresholds to the destination's SLA object, but Business Hours and Holiday List references may not transfer if the destination uses a different scheduling model.

Macros trigger on Ticket create/update events using conditions (field values, customer events) and fire actions (reply templates, field updates, assignments). We export macro definitions as structured rules, but complex multi-step macros with Teams notifications or conditional branching may require manual recreation on the destination platform.

Tags are flat string labels applied to Tickets for categorization. We preserve all Tag values and reapply them to the destination Ticket records. No hierarchical or color metadata is carried over as most destination platforms support only flat tag names.

Each Ticket contains one or more Conversation records capturing public replies, internal notes, and system-generated status changes. We export all conversation entries in chronological order and reassemble them under the migrated Ticket in the destination system.

File attachments on Tickets (and inline in conversations) are stored with URLs pointing to Desk365's blob storage. We download attachments and re-upload them to the destination platform or to cloud storage with a reference link in the destination record. Large file volumes may require chunked processing due to API rate constraints.

Desk365 supports custom text, number, dropdown, date, and boolean fields on Tickets. We extract field definitions and values, then map them to equivalent custom fields on the destination. If the destination lacks a matching field type, we store the value as a text custom property with a naming convention indicating the original field name.

End users can export their own submitted tickets from the Support Portal as CSV, scoped by All Tickets, Department/Company, or self-only. We use this export as a secondary source to cross-validate requester data and fill any gaps in the agent-side ticket export.

Desk365's Premium tier includes IT Asset Management that links hardware/software assets to Tickets. We extract asset records and their linked Ticket associations. Asset-to-asset relationships and dependency graphs are flattened to a simple linked list in the destination.