Migrate from Kaseya VSA to Zendesk

VSA Service Desk Tickets map to Zendesk Ticket records. The VSA ticket Definition (status values, priority, category, resolution type) becomes Zendesk custom ticket fields and ticket status values. We preserve original ticket timestamps as Zendesk CreatedAt and UpdatedAt by setting them during API import. VSA ticket comments and conversations map to Zendesk Comments in chronological order. Custom fields at the ticket level map to Zendesk custom_fields array entries using the field ID rather than field name per Zendesk API convention.

VSA Ticket Definitions (field schemas, status definitions, and form layouts) do not have a direct Zendesk equivalent because Zendesk has its own ticket field system. We create matching Zendesk custom fields during migration, define dropdown options to match VSA status and category values, and flag any VSA fields with no Zendesk equivalent for the customer's admin to decide whether to create a field, store as a tag, or drop.

VSA Organizations map to Zendesk Organizations. However, VSA Organizations are MSP multi-tenant containers that may represent dozens of discrete customer environments, while Zendesk Organizations are typically one per end-customer account. We assess the Organization structure during discovery and either map 1:1 or recommend splitting a VSA Organization into multiple Zendesk Organizations if the customer serves distinct end-user bases.

VSA Sites are sub-containers within Organizations, typically representing physical locations or sub-divisions. Zendesk has no native Site equivalent. We map Sites to a custom Organization-level text field, or to Zendesk Tags on tickets if the customer's primary use of Sites is ticket attribution by location. The customer chooses the strategy during scoping.

VSA custom fields at the ticket level map to Zendesk custom_fields. VSA dropdown and multi-select fields map to Zendesk tagger (dropdown) and multi-tagger fields using field ID matching. Numeric, boolean, and text fields map directly to their Zendesk equivalents. VSA custom field definitions are preserved as Zendesk field labels and option values, with a migration note flagging any field names longer than Zendesk's 50-character limit.

VSA Agent Groups are technician-level groupings for procedure deployment and monitoring. Zendesk has no Agent Group equivalent; agents are assigned individually or via User Segments (Zendesk Suite Team and above). We map VSA Agent Group memberships to Zendesk User Segments if the customer uses segment-based views, or document the mapping for manual reassignment post-migration.

MSP customers using VSA Organizations to represent discrete client environments need to map these to Zendesk's account model. Zendesk's account model supports multiple Organizations under one Zendesk instance, but each Organization is an isolated data container. We design the Organization mapping during scoping, confirming whether the customer needs separate Zendesk Organizations per client or a consolidated Organization structure.

VSA custom fields at the Agent level (Global, Organization, Site, Agent Group, or System contexts) are RMM-specific endpoint attributes that do not map to Zendesk's helpdesk schema. We extract agent-level custom field values referenced in tickets and migrate them as Zendesk ticket custom fields. Agent-level fields that are not referenced in tickets are flagged as non-migratable with a recommendation to maintain them in a concurrent RMM platform or a custom Zendesk app.

Agent Procedures are VSA automation scripts (CMD, PowerShell, VSA-native) that execute at the endpoint level. Zendesk has no equivalent at the ticket level. We do not migrate Agent Procedures. We deliver a written inventory of all exported Agent Procedures with their trigger conditions, parameters, and target scope as a reference document for the customer's admin to evaluate for rebuild in Zendesk automations, a parallel RMM tool, or retirement.

Monitor Sets define alerting and threshold configurations attached to Agents in VSA. These are RMM automation objects with no Zendesk equivalent. Zendesk's helpdesk platform handles incident response to user-reported issues, not machine-level monitoring alerts. We do not migrate Monitor Sets. We document them as a separate RMM concern and recommend the customer maintain endpoint monitoring in a dedicated RMM platform alongside Zendesk.

Patch Policies control automated patching schedules, approval rules, and reboot handling for VSA-managed endpoints. These are RMM automation objects. Zendesk does not have a patching module. We do not migrate Patch Policies. We flag Patch Policy configurations as a separate RMM concern and deliver a written inventory of active policies for the customer's admin to re-implement in their chosen RMM platform post-migration.