Migrate from Kaseya Vorex Service Desk to Intercom

Vorex Tickets map directly to Intercom Conversations. The Vorex ticket ID becomes a custom attribute vor ex_ticket_id__c on the conversation for reconciliation. Subject maps to the Conversation title, requester Organization maps to the Contact via Intercom Company membership, and conversation threads (customer messages, internal notes, technician replies) map to Conversation Parts ordered by timestamp. Vorex status (Open, In Progress, Pending, Resolved, Closed) maps to an Intercom custom conversation state attribute; Intercom's default Open, Closed state is supplemented with the original Vorex status preserved as a labeled attribute.

Vorex Organizations (representing client companies or internal departments submitting tickets) map to Intercom Companies. The Organization Name becomes the Company name, and Organization domain data maps to the Company domain field. We resolve the Company ID during ticket import so that each Conversation is linked to the correct Company on insert. Vorex multi-tenant organizations each create a separate Intercom Company; the MSP-client relationship is preserved as multiple Companies rather than a parent-child hierarchy.

Vorex Contacts associated with Organizations map to Intercom Contacts. Each Contact is created or matched (by email) against the Intercom Contact table, then linked to the corresponding Intercom Company. Contact email, name, and phone migrate directly. Vorex contact custom fields map to Intercom custom attributes on the Contact object.

Vorex Service Desks are top-level organizational containers potentially scoped by department or region. Intercom does not have an equivalent hierarchical container — all conversations live in a single Workspace Inbox. We flatten Service Desk assignments into Intercom Inbox views by creating tagged segments or routing rules based on the original Service Desk name. The customer configures Inbox assignments and views post-migration; we document the Service Desk-to-view mapping in the migration handoff document.

Vorex custom fields (Ref, Caption, Format, Order, DefaultValue supporting text, number, date, dropdown, checkbox) map to Intercom custom attributes on the Contact object (for requester-scoped fields) and on the Company object (for organization-scoped fields). We map the Vorex Format to the nearest Intercom attribute type: text to string, number to number, date to date, dropdown to string (with allowed_values list), checkbox to boolean. The original Vorex Caption is preserved as the Intercom attribute name for admin clarity.

Vorex Agents (IT staff who own and resolve tickets) map to Intercom Team Members. We match agents by email; un matched agents go to a reconciliation queue for the customer's admin to provision before record import. Vorex agent role permissions (admin, technician) have no direct Intercom equivalent — we note the original role in a custom attribute vor ex_agent_role__c on the Team Member for the admin to configure Intercom permissions post-migration.

Vorex ticket attachments (documents, screenshots, logs) associated with individual tickets migrate to Intercom Conversation Parts of type attachment. We extract binary files from Vorex via the API or Import Center export, then upload them to Intercom linked to the corresponding conversation. Files exceeding 10 MB in Intercom require chunked upload handling; we flag these in the migration report. Attachment filenames are preserved for audit traceability.

Vorex tickets frequently contain IT Glue configuration item references (servers, workstations, software licenses) linked via the IT Glue integration. These are external IDs pointing into the Kaseya IT Glue product that do not exist in Intercom. We extract the full CI link data (CI type, CI name, CI ID) and surface it as a multi-value or structured custom attribute on the Intercom Company record. The native auto-population of asset context will not function in Intercom; we document each CI reference so the customer's admin can manually re-link or use an IT Glue third-party integration if available on Intercom's App Store.

Vorex time entries tracking billable and non-billable hours logged against tickets do not have a native Intercom equivalent. We migrate time entries as Intercom Conversation Parts (internal notes) with the duration, date, agent, and description embedded in the note body in a structured format (e.g., 'Time Entry: 1.5h | Agent: Jane Doe | Date: 2025-09-15 | Billable: Yes | Description: Network diagnostics'). The customer may configure a time-tracking integration post-migration to replace this workaround with a dedicated PSA tool.

Vorex SLA Policies define response and resolution time targets tied to ticket priority. Intercom's SLA model uses Inbox SLA Rules that set first-response time targets per Inbox or team. We document the original Vorex SLA Policy configuration (priority levels, response targets, resolution targets) as a named SLA matrix in the migration handoff document, and the customer's admin configures equivalent Intercom Inbox SLA Rules. We do not migrate SLA policies as functional automation in Intercom because the models differ structurally.