Migrate from Kaseya VSA to Intercom

VSA Service Desk Tickets map directly to Intercom Conversations via the Intercom Conversations API. Each VSA ticket becomes a Conversation with message parts created from the VSA ticket body, requester details, and assignee information. VSA ticket status (Open, Pending, Resolved, Closed) maps to Intercom Conversation state values (open, closed). VSA ticket priority maps to a custom attribute or intercom conversation priority field if the workspace has Priority Inboxes configured.

VSA Organizations map to Intercom Companies using the Company object API. The Organization name becomes the Company name, and any Organization-level contact email becomes an associated Contact within the Company. Organizations without a clear company-level contact in Intercom are mapped as standalone Companies for organizational reference and reporting.

VSA Sites are sub-containers within an Organization, typically representing physical locations or client subdivisions. Site assignments on VSA tickets are translated to Intercom Tags applied to the relevant Conversation at migration time. We preserve the Organization-Site hierarchy by naming tags as 'OrgName: SiteName' to maintain the two-level structure. The customer configures tag-based routing in Intercom Inboxes post-migration if Site routing is required.

VSA Custom Fields assigned at Global, Organization, Site, or System context levels that are referenced on ticket records are translated to Intercom custom contact attributes. We map VSA field types (Text, Number, Boolean, Date) to their nearest Intercom attribute type equivalents. Attributes are applied to the relevant Contact or Conversation during migration. Custom reports referencing more than 40 VSA custom fields cannot replicate that structure in Intercom; we flag any migration where the source record references more than 40 custom fields.

VSA Service Desk Ticket Definitions define ticket categories and fields. We map VSA ticket types to Intercom Inboxes, creating one Inbox per distinct VSA ticket definition that has active ticket volume. If a VSA environment uses fewer than five ticket types, each becomes an Intercom Inbox; if more, we map them to a smaller set of Inboxes and document the remainder for manual routing or tagging configuration.

VSA user accounts that submitted or were assigned to Service Desk Tickets map to Intercom Contacts. We resolve the VSA user account to an Intercom Contact by matching the account email address. VSA user accounts without an email address in the system are created as Contacts with a generated placeholder address and flagged for the customer admin to supply a real email post-migration. VSA Agents as managed endpoints do not map to Intercom Contacts.

VSA Monitor Sets define alerting and threshold configurations for Agents. Intercom has no monitoring or alerting equivalent. We export Monitor Set configurations and their assigned agents as a structured JSON inventory document delivered alongside the migration. The customer's VSA admin uses this to configure equivalent alerting outside of Intercom or to maintain the monitoring configuration on VSA for endpoints they continue to manage.

VSA Agent Procedures are CMD, PowerShell, and VSA-native automation scripts. Intercom has no script or procedure equivalent; Intercom Fin AI Procedures use a different execution model and cannot host imported VSA procedures. We export Agent Procedure folders and their contents as a structured XML and PDF inventory document. The customer's VSA admin reviews this inventory and decides which procedures can be rebuilt as Intercom Fin Procedures or handled outside Intercom entirely.

VSA Patch Policies control automated patching schedules, approval rules, and reboot handling. Intercom does not support endpoint patch management. We export the Patch Policy configurations as a structured document and deliver it alongside the migration. If the customer continues to run any VSA or another RMM alongside Intercom, the patch policy inventory serves as the configuration reference; if they are fully departing VSA, the inventory documents what automation capability is being abandoned and must be replaced.

VSA Event Sets define which system events trigger alerts or procedures and are listed as a migratable automation solution in VSA Import Center. Intercom has no event-based automation model that maps to this. We export Event Set configurations as part of the automation inventory document. Any VSA customer that relied on Event Sets for proactive alerting will need to implement equivalent alerting through their remaining RMM platform or a separate monitoring tool; we document this gap explicitly in the migration handoff.