Migrate from Vivantio to Intercom

Vivantio ticket types (Incident, Problem, Change, Service Request, and unlimited custom types) do not have a direct Intercom equivalent because Intercom uses a flat conversation model with no native parent-child hierarchy. We map each Vivantio ticket type to an Intercom Conversation tag (for conversational work) or to an Intercom Ticket record type (for back-office formal work), depending on whether the ticket originated from email, chat, the portal, or API. The Vivantio ticket category and priority map to Intercom conversation tags and priority labels respectively. Ticket status (Open, Pending, Resolved, Closed) maps to Intercom conversation state. All conversation messages and internal notes migrate as Intercom Conversation parts.

Vivantio Callers and Contacts map to Intercom Contacts. The canonical email address is the dedupe key. We extract the full name, email, phone (with validation disabled in Intercom workspace settings before migration per Intercom migration guidance), and any custom fields from Vivantio. Contacts must load before any Conversations or Tickets that reference them, matching Intercom's requirement that every conversation is linked to an existing contact.

Vivantio Organisations map to Intercom Companies. The organisation name becomes the company name, and domain is extracted for the website field. Companies load after Contacts in the sequence because Intercom links Contacts to Companies via the company_id attribute, and that reference must exist at the time of contact import.

Vivantio Agents map to Intercom Operators. We extract agent name, email, role, and team membership. Admin-level Vivantio agents map to Intercom Admin roles. Team membership from Vivantio maps to Intercom Team groups so that routing rules can reference the correct team inbox.

Vivantio Teams and Resolver Groups map to Intercom Teams. We preserve team names, the agents assigned to each team, and workload balancing rules where applicable. Teams must be provisioned in Intercom before agent import so that the team_id reference resolves at migration time. Intercom Teams control inbox assignment and routing rules.

Vivantio Knowledge Articles map to Intercom Help Center articles. We preserve article body (including inline images migrated as file uploads to Intercom's file storage), article categories and sections, publication status (draft/published), and publication date. Public/internal visibility from Vivantio maps to the Intercom Help Center article state. We update internal links between articles to point to the new Intercom Help Center URLs. Multilingual articles migrate as separate article records linked by a common identifier.

Modern Vivantio custom fields (single-line text, multi-line text, drop-down, radio button, date, numeric, and checkbox) map to Intercom custom data attributes of the corresponding type. These attributes must be created in Intercom before any contact, company, or conversation records are imported so that attribute values can be mapped correctly during the load. Legacy custom fields from Vivantio Service Desk cannot be migrated as-is because they are incompatible with Intercom's custom attribute model; we identify them during discovery, flag them explicitly, and map them to equivalent Intercom attributes or archive them.

Vivantio SLA configurations with priority-based response and resolution windows map to Intercom SLA Rules, which are available on the Advanced ($99/seat) and Expert ($139/seat) plans only. We verify the destination Intercom plan during scoping. If Essential plan is in use, SLA targets are noted as out-of-scope for migration and must be managed manually or the plan must be upgraded. Business-hour calendars and pause rules from Vivantio are preserved in a written configuration document for the customer to re-enter in Intercom settings.

Files attached to Vivantio tickets, articles, and contacts are extracted, downloaded, and re-uploaded to Intercom's file storage with the same parent reference. Large file batches are chunked to avoid Intercom API timeout during upload. Image attachments inline within article body are extracted and re-uploaded as Intercom-hosted assets so that article rendering is preserved.

Vivantio Self Service Portal structure (multiple portals per team or department, Service Catalog layout, and request form definitions) does not have a direct Intercom equivalent. We migrate the portal content (knowledge articles, categories, and public articles) to the Intercom Help Center. Visual branding elements, custom portal URLs, and portal-specific navigation are documented as out-of-scope for migration. The customer rebuilds the Help Center appearance in Intercom's customise panel.

Vivantio Workflows and Business Rules drive ticket routing, escalations, and automated actions. We do not migrate workflows as code because the trigger conditions, actions, and automation logic have no direct Intercom equivalent. We deliver a written inventory of every active Vivantio workflow and routing rule with its trigger, conditions, actions, and a recommended Intercom Rules engine equivalent. The customer's admin rebuilds these in Intercom's workflow builder post-migration.

Vivantio's built-in report builder is described as fussy and confusing by users. Reports and dashboards do not migrate because the data schema, field references, and visualisation types differ between platforms. We deliver a written map of every saved Vivantio report with its filters, groupings, and metrics so that the customer can rebuild equivalent reports in Intercom's analytics or in a connected BI tool.