Migrate from Kaseya VSA to Salesforce Service Cloud

VSA Service Desk Tickets map to Salesforce Cases. The VSA ticket ID (used internally in Kaseya) maps to Case CaseNumber or a custom field vsd_ticket_id__c depending on whether the customer wants the original VSA ID visible alongside the Salesforce-generated case number. Ticket Subject maps to Case Subject, Description maps to Case Description, and Status maps to Case Status with a status value mapping table built during scoping. Priority maps to Case Priority. The VSA Assignee (agent or technician) maps to Case OwnerId via User lookup resolved by email match.

VSA custom fields defined on Service Desk Tickets are read from the Data Warehouse API endpoint /api/odata/1.0/ServiceDeskCustomFieldDetails and translated to Salesforce custom fields on the Case object. Each VSA custom field type (string, integer, date, picklist, checkbox) maps to the equivalent Salesforce field type. Fields with Organization or Site context are preserved as custom fields on Case with values carried through from the parent Organization record during import. The 40-field cap that VSA applies to custom reports does not apply in Salesforce, but any picklist whitelists defined in VSA must be replicated as Salesforce picklist values during schema setup.

VSA ticket conversation history (internal notes, customer replies, public comments) migrates as Salesforce CaseComment records or as EmailMessage records linked to the Case depending on the migration scope. We preserve the author, timestamp, and message body. Conversation ordering is maintained by setting the CreatedDate on CaseComment to the original VSA timestamp. Email-based ticket channels migrate to EmailMessage with the incoming email preserved as Body and the customer email address as FromAddress.

VSA Organizations (the top-level tenant container, especially relevant for MSPs managing multiple customer environments) map to Salesforce Account records. The Organization name becomes the Account Name, and Organization-level custom fields become Account custom fields. For MSPs, the Organization is the client container; for internal IT teams, it is the company division. We preserve the Organization hierarchy as a parent Account tree in Salesforce so that reporting by client or division is available in Salesforce native reports without a custom object.

VSA Sites are sub-containers within an Organization, typically representing physical locations or client sub-divisions. We map each Site to a child Account record under the parent Organization Account, or to a Salesforce Location record (available with Field Service Starter or as a standalone object) if the customer uses Field Service for asset tracking. Site assignments on agents carry forward as the Account hierarchy under which the managed endpoint record lives. The customer's choice is confirmed during scoping based on whether they use Field Service licensing.

VSA Agents (managed endpoints) are the most structurally different object in this migration. Service Cloud does not have a native managed-endpoint object. We offer two migration strategies: (1) Map agents to Salesforce Asset (standard object from Field Service Starter), which supports Asset Name, SerialNumber, Status, InstallDate, and a link to Account; (2) Create a custom object (VSA_Endpoint__c) with fields mirroring the VSA agent configuration including hostname, OS, last check-in, and status. The choice depends on whether the customer has or will add Field Service licensing. Agent Procedures and Machine ID Templates do not migrate; they are documented in the automation inventory for rebuild.

VSA custom fields scoped at the Organization level migrate to custom fields on the Salesforce Account object. Any picklist values, default values, or required-field configurations defined in VSA are replicated in Salesforce during schema setup. The Organization-level custom fields typically capture client contract tier, SLA level, billing contact, or account manager assignment.

VSA custom fields scoped at the Site level migrate to custom fields on the child Account record (or Location custom fields if Field Service is used). Site-level fields typically capture location address, site contact, support tier for that location, or site-specific SLA terms.

Monitor Sets define alerting and threshold configuration for VSA Agents. They are RMM-specific objects with no equivalent in Salesforce Service Cloud. We do not migrate them. We extract the Monitor Set configuration from the VSA Import Center XML and deliver it as a written inventory (Monitor Set name, threshold definitions, agent assignments, and alert contacts) for the customer's IT admin to evaluate against Salesforce Monitoring integrations or a third-party monitoring tool of their choice.

Agent Procedures are CMD, PowerShell, and VSA-specific automation scripts attached to agents. They are the most technically complex object in the VSA stack and have no equivalent in Salesforce Service Cloud. We extract procedure folders and individual procedure definitions from the Import Center XML export and deliver a written automation inventory (procedure name, folder path, trigger conditions, script content, and assigned agents) for the customer's IT admin to migrate to a dedicated automation platform (Power Automate, Runbook, ServiceNow Orchestration, or equivalent) post-migration.

VSA ticket attachments are exported as part of the Import Center XML bundle and stored in the VSA file store. They migrate to Salesforce Files (ContentVersion for file binary, ContentDocument for metadata) and are linked to the target Case via ContentDocumentLink. File type, original filename, and upload date are preserved. Files above Salesforce's 25 MB per file limit are flagged for the customer to evaluate whether they should be stored in an external document store (SharePoint, Google Drive, AWS S3) with a ContentDocumentLink reference only.

VSA technician accounts and their role assignments (Admin, IT Technician, IT User) migrate to Salesforce User records. We match VSA users by email address against the Salesforce destination org's User table. Role assignments from VSA are preserved as a custom field vsa_role__c on the User record since Salesforce roles serve a different org-wide hierarchy purpose. Any VSA user without a matching Salesforce User is placed in a reconciliation queue for the customer's admin to provision before the migration proceeds.