Migrate from Vorex to Zendesk

Vorex Tickets map directly to Zendesk Tickets with status, priority, assigned technician (agent), requester contact, and all timestamps preserved. The Vorex ticket subject maps to Zendesk subject, and the full conversation thread (including internal notes) migrates as Zendesk comments with the correct author (agent vs requester) attribution. We extract via the /tickets endpoint with full field coverage and set the Zendesk ticket type to match the Vorex category if populated.

Project migration requires pre-flight re-profiling because Vorex project date fields are documented as unreliable. Any record where start_date exceeds end_date, or where dates are null on active projects, is flagged for manual review before migration mapping is committed. For Zendesk Suite Enterprise plans, Projects migrate natively. For lower tiers, we map project records to Zendesk Tickets with project metadata (project name, dates, status, associated client) stored in custom fields on the ticket so project context is preserved without requiring the Projects add-on.

Vorex Time Entries export cleanly via the V2 API with billable and non-billable flags, labor rates, owner assignment, and associated project and ticket references. We map time entries to Zendesk's native time tracking (available on Suite Growth and above) or store them as custom fields on the parent ticket if the destination Zendesk tier does not include time tracking. The billing rate and multiplier are preserved as separate custom fields since Vorex-specific rate structures have no Zendesk standard equivalent.

Vorex Expense records migrate with expense type, amount, date, receipt attachment reference, and owner. We map the expense category to a Zendesk custom field and flag any entries linked to inactive employees or technicians. If Zendesk Guide is the destination tier without time and expense tracking, expenses are stored as ticket custom fields or as a linked custom object depending on the customer's data model preference established during scoping.

Vorex Client records (the primary contact entity with name, email, phone, address, and account manager) map to Zendesk End Users or to Organizations depending on whether the contact is a person or an organization. We export both Vorex Client and Company records and present a deduplication recommendation during scoping: merge them into Zendesk Organizations with End User contacts, or keep them separate based on the customer's current Vorex data hygiene.

Vorex Company (account) records store business name, industry, size, and primary contact link. These map to Zendesk Organizations with the business name as the Organization name and industry stored in a custom field. Organization is created before any User import so that the organization_id lookup is satisfied at the moment of User insert.

Vorex User and technician records export with role, email, active or inactive status, and team assignment. These map to Zendesk Agents. We match by email against the Zendesk destination and flag any inactive Vorex users the customer did not explicitly scope for migration. Zendesk requires the migrating user to have admin-level permissions; we coordinate with the customer's Zendesk admin to provision the appropriate agent roles before record import begins.

Vorex Invoice records carry line items, tax codes, and QuickBooks sync flags that vary by tenant configuration. We export invoice headers and line items but strip all QB-specific metadata (GL account references, sync flags, external QB invoice IDs) since they have no Zendesk equivalent and would corrupt the destination data. Invoice records without QB artifacts migrate as a custom object or as ticket-linked records depending on the customer's reporting needs. Zendesk does not have a native invoicing module, so the customer should plan for a separate billing tool if invoicing is part of the service workflow.

Vorex supports custom fields on tickets, projects, and clients, but the V2 API exposes them inconsistently. Some tenants show custom fields as flat key-value pairs; others nest them under a custom_properties object. We normalize both patterns during extraction and map them to Zendesk's standardized custom_fields array, using field ID rather than display name for the API write to avoid ID collisions. If the destination Zendesk tier limits custom field count, we prioritize business-critical custom fields during scoping.

Ticket and project attachments in Vorex are referenced by URL in the V2 API rather than streamed directly. We extract attachment URLs and re-fetch them if the destination Zendesk supports file migration, or log them as a downloadable asset list if the Zendesk tier limits attachment storage. Attachment filenames, content types, and associated ticket or project references are preserved in the mapping log.