Migrate from Kaseya Vorex Service Desk to Freshdesk

Vorex Tickets map directly to Freshdesk Tickets with standard fields (status, priority, type, requester, assignee, created_at, updated_at) preserved. Conversation threads migrate as Ticket Conversations in Freshdesk, maintaining the original message order and agent-customer attribution. SLA breach flags and escalation flags from Vorex surface as custom fields or ticket status notes. Vorex ticket attachments migrate as Freshdesk ticket attachments, with files over 25 MB handled via chunked upload to accommodate Freshdesk attachment size limits.

Vorex Organizations map to Freshdesk Companies. Organization name becomes the Company name; address, domain, and primary contact fields map to the equivalent Freshdesk Company fields. The Organization ID is preserved as a custom field so that any historical Vorex ticket references can be traced back during reconciliation. If the customer uses Vorex multi-tenant isolation, we map each Organization to a Freshdesk Group or product segment for access-control parity.

Vorex Service Desks function as top-level organizational containers potentially scoped by department or region. Freshdesk has no direct Service Desk object; we map Service Desks to Freshdesk Groups for agent routing and visibility control. If multiple Service Desks exist with overlapping agent rosters, we configure Freshdesk Groups to mirror the original access scope. Group assignment becomes the default assignee routing for migrated tickets.

Vorex exposes a structured custom fields API returning Ref, Caption, Format, Order, and DefaultValue. Formats include text, number, date, dropdown, and checkbox. We map these to Freshdesk custom fields using the equivalent type (text, number, date picker, dropdown, checkbox) and preserve the original Caption as the Freshdesk field label. DefaultValue migrates as the Freshdesk default. We validate picklist values against Freshdesk dropdown options and flag any values that exceed Freshdesk's character limit for dropdown options.

Vorex SLA Policies define response and resolution time targets tied to ticket priority. These are workflow constructs with no direct export endpoint. We extract the SLA configuration as a written specification (policy name, priority level, first response target in hours, resolution target in hours, business hours configuration) and map it to a Freshdesk SLA Policy created during migration setup. The customer configures the SLA Policy in Freshdesk Admin before ticket migration begins; we reference the SLA Policy name in ticket records.

Vorex Agents map to Freshdesk Agents by email address match. Agent role permissions (admin, technician) from Vorex flag as a note in the Freshdesk agent profile since Freshdesk's permission model uses agent groups and profiles rather than direct role assignment. Any Vorex Agent linked to a VSA user account is noted separately because VSA user credentials do not map to Freshdesk authentication. We resolve agents before ticket migration so that assignee references are satisfied at insert time.

Vorex tickets frequently contain embedded IT Glue configuration item references linking to servers, workstations, software licenses, and other assets. These are external IDs pointing into the IT Glue product, which is Kaseya-only and has no Freshdesk equivalent. We extract the full CI reference data (CI type, name, ID, and Vorex ticket association) and write it to a custom field group on the migrated Freshdesk ticket. Native auto-population of asset context will not function in Freshdesk; we deliver a CI reference export CSV and a re-linking guide for the customer's admin to re-establish asset associations manually using Freshdesk assets if the Freshdesk Asset Management add-on is active.

Vorex tracks billable and non-billable time logged against tickets. These migrate as Ticket Notes in Freshdesk containing the time entry data (duration, date, agent name, description). If the customer activates Freshdesk's Time Tracking add-on, the note content can be converted to time entries manually post-migration. Billable flag from Vorex migrates as a tag on the Freshdesk note so that the customer can filter by billing status. Time entries without a parent ticket are held in a reconciliation queue for the customer to map to a Freshdesk ticket before migration completes.