Helpdesk migration
Field-level mapping, validation, and rollback between Kaseya VSA and Zoho Desk. We move data and schema; workflows are rebuilt natively in Zoho Desk.
Kaseya VSA
Source
Zoho Desk
Destination
Compatibility
6 of 12
objects map 1:1 between Kaseya VSA and Zoho Desk.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from Kaseya VSA Service Desk to Zoho Desk is a ticketing-centric migration driven by the VSA X Service Desk module retirement and Zoho's transparent per-agent pricing model. Kaseya VSA uses an agent-centric XML export via Import Center with ISO-8859-1 encoding and a custom field model scoped at the Partition, Organization, Site, and Agent Group levels. Zoho Desk uses a department-centric schema with Agents, Contacts, Accounts, Tickets, and Threads that must be populated through CSV import or Zoho's Assisted Migration process. We extract Kaseya's Service Desk XML, transcode to the correct encoding, resolve the custom field ordering from the Data Warehouse API, and map ticket history to Zoho Desk Threads with author attribution preserved. Agent-level custom fields that exceed Zoho's 40-field report limit are flagged before migration. We do not migrate Agent Procedures, Monitor Sets, Patch Policies, Event Sets, or Workflows as code; these require rebuilding in Zoho's Blueprint and workflow rules.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Kaseya VSA object lands in Zoho Desk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Kaseya VSA
Organizations
Zoho Desk
Departments
1:manyKaseya VSA Organizations are the top-level tenant containers, especially relevant for MSPs with multiple customer environments. Zoho Desk uses Departments as the primary organizational unit, with Teams nested within Departments. We map each Kaseya Organization to a Zoho Desk Department, and create Teams within each Department representing the Kaseya Sites under that Organization. Multi-tenant MSP structures with separate Organizations for each client map cleanly to separate Zoho Desk Departments, preserving billing and reporting separation.
Kaseya VSA
Sites
Zoho Desk
Teams
1:manyKaseya Sites are sub-containers within an Organization representing physical locations or client sub-divisions. Site assignments on Agents are preserved as Team assignments in Zoho Desk. Each Kaseya Site becomes a Zoho Team under the corresponding Department. Agents linked to a Site map to the corresponding Team, and ticket assignment rules can be configured to route by Team.
Kaseya VSA
Service Desk Tickets
Zoho Desk
Tickets
1:1Kaseya VSA Service Desk Tickets export via Import Center XML and include TicketId, TicketNumber, Summary, CustomFieldOrder, CustomFieldCaption, CustomFieldName, CustomFieldValue, and CustomFieldType from the Data Warehouse API. We map Ticket.Status to Zoho Desk Ticket Status, Ticket.Priority to Priority, Ticket.AssignedTo to the agent's email-matched Zoho Agent record, and ticket history conversations to Zoho Desk Thread records with author attribution. The Data Warehouse API CustomFieldDetails endpoint returns custom field values per ticket; we flatten the context-level field hierarchy (Global, Org, Site, Agent Group, System) into Zoho's module-level custom fields.
Kaseya VSA
Service Desk Ticket Definitions
Zoho Desk
Ticket Layouts (Fields List)
lossyKaseya VSA Service Desk Ticket Definitions define the form structure, field types, and required fields for tickets. Zoho Desk uses Layouts and Fields per Department to control which fields appear on tickets and their required status. We map Kaseya's Ticket Definition field types (text, dropdown, date, numeric, checkbox) to Zoho field types (single-line, multi-line, picklist, date, number, checkbox). Custom fields defined at the Ticket Definition level become Zoho Desk custom fields added to the relevant Department layout before migration.
Kaseya VSA
Service Desk Message Templates
Zoho Desk
Email Templates / macros
1:1Kaseya VSA Service Desk Message Templates are canned response templates used in ticket replies. These map to Zoho Desk Email Templates (Setup > Templates > Email Templates) which can be associated with departments and used in automated responses or manual macros. We extract template body content and variable placeholders from the Import Center XML and create equivalent Zoho Desk templates with Zoho's {ticket.ticket_number}, {contact.name}, and {ticket.status} variable syntax.
Kaseya VSA
Service Desk Holiday definitions
Zoho Desk
Holidays
1:1Kaseya VSA Service Desk Holiday definitions control SLA calculation during business hours exclusions. These map to Zoho Desk Holidays (Setup > Office Hours and Holidays) per Department. We extract holiday dates and descriptions from the Import Center XML and configure them in Zoho Desk, noting that Zoho's SLA timer pauses during Holiday periods as configured.
Kaseya VSA
Agents (managed endpoints)
Zoho Desk
Contacts
lossyKaseya VSA Agents are managed endpoints with hostname, OS, last check-in, and status. Zoho Desk does not have a native RMM agent model. If the migration scope includes Kaseya Service Desk tickets that reference Agents as the affected device, we create Zoho Desk Contacts representing those devices and store the original Machine ID and Agent ID in custom fields (vsa_machine_id__c and vsa_agent_id__c) for reference. This is a reference mapping, not a full endpoint migration.
Kaseya VSA
Contacts (Service Desk requesters)
Zoho Desk
Contacts
1:1Kaseya VSA Service Desk Tickets have a requester (Contact) associated with each ticket. These contacts export from the Data Warehouse API with name, email, phone, and Organization association. We map Kaseya requester contacts to Zoho Desk Contacts, using email as the dedupe key. Organization-level contacts map to Zoho Accounts for companies, with individual requesters linked to the Account.
Kaseya VSA
Organizations
Zoho Desk
Accounts
1:1Kaseya VSA Organizations that represent companies (not MSP client containers) map to Zoho Desk Accounts. We use the Organization name as Account Name, the Organization's primary contact email as the Account email, and store the original Organization ID in a custom field (vsa_org_id__c). If the Organization is an MSP tenant container rather than a customer company, it maps to a Zoho Desk Department instead, and we create separate Accounts for any customer organizations nested within.
Kaseya VSA
Views
Zoho Desk
Custom Views
1:1Kaseya VSA Views define saved ticket list configurations with filters and column selections. Zoho Desk Custom Views serve the same purpose: saved filter combinations scoped to a Department. We map Kaseya View filter criteria (status equals, priority equals, assigned agent equals, date range) to Zoho Desk's saved view filter syntax. Column selections map to the Zoho view column picker.
Kaseya VSA
Agent Procedures, Monitor Sets, Patch Policies, Event Sets
Zoho Desk
No equivalent in Zoho Desk
lossyKaseya VSA Agent Procedures (CMD/PowerShell scripts), Monitor Sets (alerting thresholds), Patch Policies (automated patching schedules), and Event Sets (trigger-action rules) have no Zoho Desk equivalent because Zoho Desk is a pure helpdesk without RMM capabilities. We do not migrate these as data. We deliver a written inventory of each object with its configuration details (procedure script content, monitor threshold values, patch approval rules, event trigger conditions) so the customer's admin can evaluate alternatives: native Zoho Desk Blueprint automation for ticket routing, Zoho Flow for cross-app automation, or a dedicated RMM tool for endpoint management post-migration.
Kaseya VSA
Machine ID Templates
Zoho Desk
No equivalent in Zoho Desk
lossyKaseya VSA Machine ID Templates encode standardized endpoint configurations and are explicitly listed in Kaseya's migration documentation as an Import/Export type. Zoho Desk has no endpoint management or Machine ID concept. We document the Machine ID Template configurations (template name, assigned machines, configuration parameters) in the migration inventory and flag that endpoint standardization requires a dedicated RMM tool post-migration if the customer no longer uses Kaseya VSA for endpoint management.
| Kaseya VSA | Zoho Desk | Compatibility | |
|---|---|---|---|
| Organizations | Departments1:many | Mapping required | |
| Sites | Teams1:many | Fully supported | |
| Service Desk Tickets | Tickets1:1 | Mapping required | |
| Service Desk Ticket Definitions | Ticket Layouts (Fields List)lossy | Fully supported | |
| Service Desk Message Templates | Email Templates / macros1:1 | Fully supported | |
| Service Desk Holiday definitions | Holidays1:1 | Fully supported | |
| Agents (managed endpoints) | Contactslossy | Fully supported | |
| Contacts (Service Desk requesters) | Contacts1:1 | Fully supported | |
| Organizations | Accounts1:1 | Fully supported | |
| Views | Custom Views1:1 | Fully supported | |
| Agent Procedures, Monitor Sets, Patch Policies, Event Sets | No equivalent in Zoho Desklossy | Fully supported | |
| Machine ID Templates | No equivalent in Zoho Desklossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Kaseya VSA gotchas
ISO-8859-1 XML encoding requirement on Import/Export
VSA 9 to VSA 10 migration requires a full architectural reassessment
Machine ID reassignment during VSA-to-VSA transfer
Confusing SKU billing model with no published pricing
Custom reports capped at 40 custom fields
Zoho Desk gotchas
Agent email identity determines comment ownership after migration
Blueprints and SLA policies do not export via API
File upload capped at 10GB per migration batch
Tier-gated export and migration capabilities
Inbound migration is two-phase with a hard Phase 2 cutoff
Pair-specific challenges
Migration approach
Discovery and Service Desk object inventory
We audit the source Kaseya VSA instance across Import Center exportable object types: Service Desk Tickets, Ticket Definitions, Message Templates, Views, and Holiday definitions. We query the Data Warehouse API ServiceDeskCustomFieldDetails endpoint to capture all custom field names, types, orders, and values across context levels (Global, Organization, Site, Agent Group, System). We identify the Organizations and Sites that require mapping into Zoho Desk Departments and Teams. We confirm the VSA version (VSA 9 vs VSA 10) because VSA 10 introduced architectural changes to agent deployment that affect the broader RMM scope even if only Service Desk is being migrated. The discovery output is a written Service Desk object inventory, custom field schema map, and Department-Team hierarchy design for Zoho Desk.
Zoho Desk schema preparation
We create the Zoho Desk destination structure before any data import. This includes provisioning Departments matching Kaseya Organizations (or Site-level Teams within a master Department depending on the customer's preference), creating Teams for each Kaseya Site, adding Zoho Agents by email-matching Kaseya technicians, configuring agent roles (Agent, Light Agent, or Support Administrator), and creating custom fields on the Ticket module layout for every Kaseya custom field identified in discovery, prefixed with vsa_ to avoid naming conflicts with Zoho native fields. Ticket Definitions from Kaseya map to Zoho Desk field configurations (required/optional, field type, picklist values). Message Templates from Kaseya become Zoho Desk Email Templates.
XML export, encoding transcoding, and data validation
We export Service Desk data from Kaseya VSA via the Import Center as a single XML bundle or multiple sequential exports. During ingestion, we detect the file encoding and transcode to ISO-8859-1 if required to prevent silent corruption. We validate ticket record counts, custom field completeness, and attachment references against the Data Warehouse API data. Any tickets with missing required fields (unassigned, no requester) are flagged for customer cleanup before migration. We build a ticket-to-thread cross-reference from the Import Center XML conversation data and the Data Warehouse API CustomFieldDetails response.
Sample CSV migration and Zoho schema validation
We run a sample migration using Zoho Desk's Assisted Migration CSV format with a representative subset of 50-100 tickets, their associated Contacts and Accounts, and custom field values. This validates the Zoho Desk custom field configuration, Department and Team assignments, and agent role mapping before full production migration. The customer reviews the sample tickets in Zoho Desk and confirms mapping accuracy. Any field type mismatches, missing picklist values, or layout issues are corrected in the Zoho Desk schema before Phase 2.
Full production migration in dependency order
We run production migration in dependency order: Accounts (from Kaseya Organizations), Contacts (from Kaseya Service Desk requesters), Tickets (with CustomFieldDetails values flattened into vsa_ custom fields, original created_at embedded in description), Threads (ticket conversation history with author attribution), Views (Zoho Custom Views matching Kaseya saved filters), Message Templates (Zoho Email Templates), and Holidays (Zoho Desk Holiday configurations). Each phase emits a row-count reconciliation report. Tickets are assigned to Departments based on the Kaseya Organization mapping, and to Teams based on the Site mapping. Agent assignments resolve by email match against the Zoho Agent table.
Delta migration and workflow rebuild handoff
We capture any Service Desk tickets created or modified in Kaseya VSA during the migration window and migrate the delta in a final pass. We then deliver the written inventory of Kaseya VSA objects not migrated: Agent Procedures, Monitor Sets, Patch Policies, Event Sets, and Machine ID Templates. For each object type, we document the configuration details (script content, threshold values, policy rules, event conditions) and provide a recommendation for rebuilding equivalent automation in Zoho Desk Blueprint (for process flows), Workflow Rules (for ticket triggers), or a third-party RMM tool (for endpoint management if Kaseya VSA is fully decommissioned). We do not rebuild these automations inside the migration scope.
Platform deep dives
Kaseya VSA
Source
Strengths
Weaknesses
Zoho Desk
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 4 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Kaseya VSA and Zoho Desk.
Object compatibility
4 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Kaseya VSA: Not publicly documented.
Data volume sensitivity
Kaseya VSA doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Kaseya VSA to Zoho Desk migration scoping. Not seeing yours? Book a call.
Walk through your Kaseya VSA to Zoho Desk migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Kaseya VSA
Other ways to arrive at Zoho Desk
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.