Migrate from Kaseya VSA to Freshdesk

Discovery and Freshdesk edition assessment

We audit the Kaseya VSA environment across Organizations, Sites, Agent count, Service Desk Ticket volume, custom field definitions (at Organization, Site, Agent, and System scope), and any active Import Center XML exports. We pair this with a Freshdesk edition assessment: Starter ($15/agent) covers basic ticketing; Growth ($29/agent) adds custom fields and analytics; Pro ($49/agent) adds workflow automations and SLA policies; Enterprise ($79/agent) adds multilingual support and advanced security. We confirm the customer's current Kaseya contract SKU during scoping because migrating mid-contract requires a separate de-procurement decision.

XML extraction with encoding correction

We extract Kaseya VSA data via the Import Center XML export. The critical step is detecting the source file encoding (we have seen UTF-8, UTF-16, and Windows-1252 variants from different Kaseya versions and export tooling) and transcoding to ISO-8859-1 before parsing. We parse the XML into a normalized intermediate representation covering Organizations, Sites, Agents, Agent Groups, Service Desk Tickets, custom field definitions, and custom field values. Any XML parsing failures are logged with line numbers and fed back to the customer for Kaseya-side correction before extraction continues.

Freshdesk schema pre-creation

We create all destination custom fields in Freshdesk before any data import. Organization-level custom fields from Kaseya become Freshdesk Company custom fields. Agent-level custom fields become Freshdesk Contact custom fields. Ticket-level custom fields become Freshdesk Ticket custom fields. Custom field types are mapped (Kaseya text to Freshdesk text, Kaseya dropdown to Freshdesk dropdown, Kaseya checkbox to Freshdesk boolean). We also create the kaseya_original_id__c field on Ticket and the kaseya_machine_id__c field on Contact during this phase. Schema is deployed into a Freshdesk trial or sandbox workspace for validation before production migration.

Dependency-ordered import with rate-limit handling

We import data into Freshdesk in dependency order: Companies (from Organizations), child Companies (from Sites), Contacts (from Agents with kaseya_machine_id__c populated), then Tickets (with Contact and Company lookups resolved). Each phase uses the Freshdesk REST API v2 with per-plan rate-limit awareness (200, 400, or 700 calls per minute), per-endpoint sub-limit respect, and exponential backoff on 429 responses. For tickets with more than ten conversation entries, we route to the dedicated conversations endpoint rather than the embedded include=conversations parameter. Batch sizes are tuned per-endpoint during dry-run validation.

Validation and reconciliation

We run row-count reconciliation against the extracted Kaseya data after each import phase: Organizations versus Freshdesk Companies, Sites versus child Companies, Agents versus Freshdesk Contacts, Tickets versus Freshdesk Tickets. We spot-check twenty to thirty random records against the Kaseya source for field-level accuracy. Any unmapped custom fields, dropped conversations, or encoding artifacts are logged and corrected before the next phase. The customer reviews the validation report and signs off before cutover.

Cutover, delta sync, and automation inventory delivery

We freeze Kaseya VSA writes during cutover, run a final delta migration of any tickets modified during the migration window, then enable Freshdesk as the system of record. We deliver a written inventory of Kaseya Monitor Sets, Patch Policies, Event Sets, and Agent Procedures with a Freshdesk equivalent reference (Automations, SLA Policies, or manual rebuild). We do not rebuild Kaseya automation logic as Freshdesk rules inside the migration scope; that is a separate configuration engagement. We support a five-business-day hypercare window for reconciliation issues raised during the first week of Freshdesk production use.