Migrate from Vision Service Desk to Intercom

Vision Service Desk Tickets map to Intercom Conversations. The ticket subject becomes the conversation title, the ticket status (Open, Pending, Resolved, Closed) maps to Intercom's open, closed, snoozed state, and priority maps to a custom priority attribute on the conversation. Threaded ticket comments migrate as conversation parts in chronological order, with internal-only comments mapped to internal notes in Intercom using the comment privacy flag. Requester information links to the migrated Intercom User record.

Vision Service Desk Clients (end-users submitting tickets via portal) map to Intercom Users. We extract client profile fields including name, email, phone, and portal preferences. Client-side custom fields migrate as custom user attributes in Intercom. Clients without email addresses present a challenge because Intercom requires an email for User creation; we flag these records during scoping and either map to a placeholder email domain or exclude per the customer's preference.

Vision Service Desk Staff records map to Intercom Teammates with their display name, email, and admin status. Super-Admins and Team Managers from Vision Service Desk become Admin roles in Intercom; standard agents become Member roles. Staff hierarchy (team structure, reporting lines) does not have a direct Intercom equivalent and requires manual team configuration in Intercom's inbox settings post-migration.

Vision Service Desk Companies (organization-level groupings for clients) map to Intercom Companies. Company-to-contact relationships preserve so that Intercom's unified contact profile shows all tickets and conversation history for a given company. Company-specific custom fields migrate as company attributes in Intercom.

Vision Service Desk KB Articles map to Intercom Help Center Articles. Article content migrates as HTML body, title migrates directly, and author information is preserved as an article attribute. Article-to-category associations are remapped to Intercom Collections during import. Custom article fields require field-type mapping because Intercom's article attribute model differs from Vision Service Desk's extended field support.

Vision Service Desk KB Categories map to Intercom Collections. The hierarchical category tree is preserved as a flat collection structure in Intercom because Intercom Collections do not support nested sub-collections at the same depth as Vision Service Desk's category hierarchy. We flatten the structure and confirm the collection mapping with the customer during scoping.

Vision Service Desk custom fields (drop-down, multi-select, date, string, boolean, numeric) defined on tickets and clients are extracted as supplementary properties and mapped to Intercom Custom Attributes. Intercom supports string, integer, float, boolean, date, and list attribute types; complex nested or relational custom fields from Vision Service Desk may require simplification or decomposition into multiple Intercom attributes. We build the custom field manifest during discovery to avoid silent data loss.

Vision Service Desk ticket tags, labels, and flags migrate as Tags on the corresponding Intercom Conversation. The tag taxonomy is preserved at the record level. Intercom's tag model is flat (no hierarchical tag groups), so nested Vision Service Desk label structures are flattened and delivered with a tag-naming convention that preserves hierarchy visually (e.g., product::feature::issue).

Vision Service Desk SLA Plans with calendar-based response and resolution targets are documented but not recreated as code. Intercom's SLA features are implemented through the inbox SLAs settings and First Response Time rules, which operate differently from Vision Service Desk's plan-based SLA model. We deliver a written SLA mapping document specifying which Intercom SLA rule corresponds to each Vision Service Desk plan, including target hours and business hours configuration.

Vision Service Desk Problem Management records (Pro Service Desk tier and above) have no direct Intercom equivalent. Intercom does not expose a separate Problem object or incident-linking model. We extract Problem records and their linked incident associations and deliver them as a structured CSV for the customer's admin to review. If the customer requires this data in Intercom, we discuss a custom object implementation as a separate scope item.

Vision Service Desk Change Management records with approval workflows and schedules do not map to any Intercom construct. Intercom has no native change request or approval chain object. We export Change records with approval status history as a structured data file and flag them for manual reference. If ITSM compliance is required post-migration, the customer should evaluate adding a dedicated ITSM tool alongside Intercom for this scope.