Migrate from Kaseya Vorex Service Desk to Zoho Desk

Vorex Tickets map directly to Zoho Desk Tickets with standard field mapping: status, priority, type, requester, assignee, and timestamps preserved. Conversation threads migrate as Comments on the Zoho Ticket. We use paginated REST extraction from Vorex (up to 100 objects per request on v1 API, 200 on v2) paced within the 1500 requests per hour v2 limit and 500 requests per hour v1 limit. Tickets with attachments are handled in a secondary pass after the ticket body migrates.

Vorex Organizations map to Zoho Desk Accounts as the parent record. Vorex Organization-linked Contacts map to Zoho Desk Contacts attached to the corresponding Account. We extract all Vorex Organization records first, create Zoho Desk Accounts, then resolve AccountId on each Contact during the Contact import phase. The Organization's address, phone, and domain fields map to the Zoho Account's standard address and website fields.

Vorex Service Desks are top-level organizational containers potentially scoped by department or region. Zoho Desk uses Departments as the equivalent container. We extract the Service Desk name and description, then create Zoho Desk Departments or tag the Department name as a custom field (cf_service_desk_origin__c) on tickets depending on whether the customer wants a strict Department hierarchy or a flattened single-department model. Service Desk-level SLA assignments are noted as a custom field mapping for manual Zoho SLA configuration post-migration.

Vorex exposes custom field schemas via structured API returning Ref, Caption, Format, Order, and DefaultValue. Formats include text, number, date, dropdown, and checkbox. We pre-create Zoho Desk custom fields (prefixed cf_ per Zoho convention) before migration, matching the Format type to the closest Zoho field type. Dropdown fields in Vorex become picklist fields in Zoho Desk with the same option values. Checkbox fields map to Zoho's checkbox custom field type. DefaultValue migrates as the field default where Zoho supports it.

Vorex SLA Policies define response and resolution time targets tied to ticket priority. These are named workflow constructs in Vorex without a direct API schema. We extract SLA policy names and rule definitions (first response time, resolution time per priority level) and map them to Zoho Desk SLA Policies in the SLA module. We flag any Vorex SLA rules with conditions not natively supported in Zoho Desk (e.g., time-of-day-based escalation outside business hours) as a configuration gap for the customer's admin to address in Zoho Flow.

Vorex Agents map to Zoho Desk Agents. We resolve by email match. Note that Zoho Desk distinguishes between full Agents, Light Agents (cannot reply publicly on tickets), and Support Administrators. We create all migrated agents as full Agents unless the customer specifies Light Agent for a subset. Zoho Desk sends an invitation email that each agent must accept before accessing the account. Deactivated Vorex agents require pre-provisioning in Zoho Desk with the same email to avoid losing case ownership during migration.

Ticket attachments (documents, screenshots, logs) are extracted from Vorex and re-uploaded to the corresponding Zoho Desk Ticket as Comments with file attachments. Files over 10 MB are chunked and uploaded via Zoho Desk's multi-part attachment API. Note that Zoho Desk's Zwitch migration enforces a 10 GB total file upload limit during the official migration process; we handle larger attachment volumes via direct API upload bypassing the Zwitch queue.

Vorex tracks billable and non-billable time logged against tickets for professional services scenarios. Zoho Desk has no native time tracking module at the standard tier, so we migrate time entries as Zoho Desk Ticket Comments with structured data (agent name, duration, date, description) plus custom fields cf_time_entry_duration__c, cf_time_entry_billable__c, and cf_time_entry_date__c for reporting. If the customer requires full billable time tracking, we recommend a separate Zoho Projects or Zoho Invoice integration post-migration.

Vorex tickets contain embedded IT Glue configuration item references (servers, workstations, software licenses) via the bidirectional IT Glue integration. These are external IDs pointing into the IT Glue product. There is no functional equivalent in Zoho Desk. We extract the full CI link data (CI type, CI name, IT Glue record ID) and surface it as a multi-line custom field cf_it_glue_ci_links__c on the migrated ticket. The customer's admin uses this data to manually re-link assets to tickets in Zoho Desk or in a connected IT Glue instance if Zoho-IT Glue integration is implemented separately.

Vorex tickets may contain VSA Live Connect remote session launch references that link tickets to VSA device records. These are Kaseya-internal cross-product references. We extract the VSA device name, device ID, and session URL (if available) as a custom field cf_vsa_device_ref__c on the migrated ticket. VSA Live Connect launching directly from a ticket does not function in Zoho Desk. The customer's admin uses the stored reference data to navigate to the VSA device record manually or evaluate a Zoho-VSA integration if one becomes available.

Vorex Organization address fields (street, city, state, zip, country) map to Zoho Desk Account address fields using the standard address compound field in Zoho Desk. Address data is extracted as part of the Organization export and written to the Account during the Account import phase. We flag any Organization with incomplete address data (missing city or country) as a data quality issue in the reconciliation report.

Vorex ticket status values (Open, In Progress, Pending, Resolved, Closed) map to Zoho Desk ticket status values. We extract the full status list from the Vorex API during discovery and configure matching status values in Zoho Desk before migration. Any Vorex status values with no direct Zoho Desk equivalent are mapped to the nearest Zoho status and flagged in the mapping inventory for customer review.