Migrate from Kaseya Vorex Service Desk to Zendesk

Vorex tickets map directly to Zendesk tickets with standard field correspondence: Status to Status, Priority to Priority, Type to Type, requester to Requester (via email lookup in Zendesk Organizations), assignee to Assignee (via agent email resolution). Conversation threads (internal notes and customer replies) migrate as Zendesk Comments ordered by original timestamp. The Vorex TicketNumber is preserved as a custom ticket field vex_ticket_number__sd for cross-reference. The V2 BMS API endpoint /api/odata/1.0/ServiceDeskTickets returns up to 100 objects per page with skip/top paging; we pace extraction at 80% of the 1500 req/hour limit to avoid 429 errors.

Vorex Organizations map to Zendesk Organizations with Name, primary contact email, address, and phone preserved. Organizations are migrated before Tickets to satisfy the Zendesk Requester lookup. If the same contact email appears in multiple Vorex Organizations (multi-tenant MSP scenario), we resolve ambiguity during scoping and may split into separate Zendesk Organizations or merge under a single master Organization.

Vorex Service Desks are top-level containers scoped by department or region with per-organization ticket filtering. Zendesk has no hierarchical container equivalent, so we flatten Service Desks into Zendesk Views using Vorex Service Desk membership as a filter condition. Each Vorex Service Desk generates one or more Zendesk Views (open, pending, resolved) that the customer's admin assigns to agent groups post-migration. If Zendesk Explore reporting is in scope, we also map Service Desk to a reporting segment.

Vorex custom fields expose a structured schema via ServiceDeskCustomFieldDetails API with CustomFieldCaption, CustomFieldName, CustomFieldType, CustomFieldDefaultValue, and CustomFieldOrder. Supported Vorex types (text, number, date, dropdown, checkbox) map to equivalent Zendesk ticket field types. We create the Zendesk field schema before ticket import, preserving the original Vorex Caption as the Zendesk field title and the Vorex CustomFieldName as a reference note. Dropdown and checkbox fields become Zendesk dropdown and checkbox types with options migrated from Vorex permitted values.

Vorex SLA Policies define response and resolution time targets tied to ticket priority and business hours configured in Service Desk locations. Zendesk's SLA feature is available on Professional and Enterprise plans. We map Vorex SLA names and targets (FirstResponseTime, ResolutionTime) to Zendesk SLA policies and apply them to the appropriate ticket groups. SLA violations and pause conditions do not transfer as they are runtime events; only the policy definition migrates.

Vorex Agents map to Zendesk Agents by email match. Vorex agent roles (Admin, Technician) do not have direct Zendesk equivalents — we default all migrated agents to Agent role and note that the customer's Zendesk admin sets permissions, groups, and views post-migration. If a Vorex agent is linked to a VSA user account with elevated permissions, we flag that mapping for manual review because VSA user roles do not apply outside the Kaseya ecosystem.

Vorex ticket attachments (documents, screenshots, log files) are associated with individual tickets and migrate as Zendesk ticket attachments. Files over 25 MB require chunked handling. We extract attachment metadata (filename, content-type, size) from Vorex and re-upload to Zendesk via the attachments endpoint, linking each to the migrated ticket ID. Attachments stored in Vorex cloud storage that require re-authentication are flagged for manual retrieval if the Vorex account is deactivated post-migration.

Vorex tracks billable and non-billable time logged against tickets with duration, date, agent, and description. Since Zendesk lacks a native time-tracking object, we migrate time entries as Zendesk ticket comments with a structured prefix (e.g., [TIME: 1h 15m — billable] or [TIME: 30m — non-billable]) so they are visible in the ticket timeline. Alternatively, we can create time entry records in a Zendesk Custom Object (new Custom Objects API) if the customer licenses the appropriate Zendesk Suite plan and wants structured billable time for PSA workflows.

Vorex bidirectional integration with IT Glue embeds configuration item references (servers, workstations, software licenses) against tickets as external Kaseya IDs. These IDs have no functional equivalent in Zendesk because the IT Glue platform does not exist in the Zendesk ecosystem. We extract the full CI link data from Vorex and surface it as Zendesk custom ticket fields (itg_ci_id__sd, itg_ci_type__sd, itg_ci_name__sd) so teams can manually re-link assets to a new IT documentation platform post-migration. The native auto-population of asset context will not function in Zendesk.

Vorex Service Desk locations define working hours used in SLA breach calculations. We extract location working hours from Vorex and configure equivalent Zendesk Business Hours records. Multi-location configurations (US, EMEA, APAC regional Service Desks) map to separate Zendesk Business Hours entries linked to the corresponding Zendesk Groups or Views.

Vorex ticket categorization and tagging migrate to Zendesk Tags. Incident categorization values (category, subcategory, item) are mapped to Zendesk tags with a naming convention preserving the hierarchy (e.g., hardware-network-switch-failure). Tags are applied at import time and are available for Zendesk triggers and views post-migration.