Migrate your Service Desk Panel data

Ticket is the core record. Most platforms use a flat ticket model with a subject, description, status, priority, and assignee. We map source ticket fields to the destination's field equivalents, but custom fields often require manual review to confirm the right destination field is used.

Customer records are typically Contacts or End Users. The challenge is matching the source customer's email and name to an existing record or creating a new one. We preserve the association by email as the key.

Agents may be called Agents, Technicians, or Staff depending on the platform. We map by email and flag cases where a source agent does not exist in the destination, allowing the customer to choose between creating new users or reassigning.

Team or Group assignment on tickets is a common field. Not all platforms have a Teams concept, and those that do may not expose it in the same way. We map team names as a custom field when the destination lacks native support.

Conversation threads are typically portable as a list of message objects with author, body, and timestamp. We preserve the chronological order and author attribution. Some platforms strip HTML formatting during export, which we flag before import.

Attachments are commonly exported as file references or URLs pointing to storage. If the source platform does not expose direct download URLs, we cannot pull the file body. We flag this during scoping and ask the customer to export files manually if needed.

Tags are simple string arrays attached to tickets. Most platforms support tags, but naming and structure vary. We import tags as-is and let the destination deduplicate or consolidate as needed.

Custom fields vary widely in type (text, dropdown, date, checkbox) and naming. We attempt to match by field label but rely on the customer to confirm the correct destination field mapping. Unmapped custom fields are logged for manual review.

SLA policies define response and resolution time targets tied to priority or request type. SLA configuration is rarely exportable and cannot be reliably reconstructed in the destination without manual setup in the destination platform.

KB articles may be available via API or export depending on the source platform. We preserve title, body, and category. Formatting differences between platforms may require post-migration review of article layout.

Automated rules, triggers, and routing logic are platform-specific and not exportable in a portable format. We document the active workflow rules during discovery so the customer can rebuild them in the destination.

Analytics and reporting configurations are not portable across platforms. Historical ticket metrics may be available as raw data for reimport into a BI tool, but the reports themselves must be rebuilt.