Migrate from InvGate Service Management to Intercom

InvGate Requests (the primary ITIL record type) map directly to Intercom Conversations. The Request title becomes the Conversation subject, description becomes the initial conversation message, and priority maps to a Conversation priority flag. We preserve the full conversation thread—public notes, internal notes, status-change notifications, and attachment references—by creating sequential messages on the Intercom conversation in chronological order. Request status (open, pending, resolved, closed) maps to Intercom's open, snoozed, and closed states. Custom properties on Requests migrate as custom attributes on the Conversation.

InvGate Incidents share the same underlying record as Requests but carry an incident type flag and impact/urgency levels. We migrate Incidents as Intercom Conversations with the incident classification preserved in a custom attribute (incident_type, impact_level, urgency_level) and a tag applied to the conversation for filtering. Major-incident associations linking multiple Incidents are not natively represented in Intercom; we document linked-incident groups in the handoff inventory for the customer's admin to rebuild as Intercom tags or separate conversations.

InvGate Agents map to Intercom Users by email lookup. The InvGate role (Agent, Admin, Manager) determines the Intercom role: Admin-level agents become Intercom Admins; standard agents become Intercom Teammates. Group memberships from InvGate map to Intercom Teams, which serve as inbox assignment containers. We flag any InvGate agents with elevated permissions (approvers, SLA managers) for manual role assignment in Intercom post-migration. InvGate's LDAP/Active Directory/Okta integration does not migrate; the customer configures SSO and directory sync in Intercom separately.

InvGate Help Desks are the top-level organizational unit, typically structured by location or department. Each Help Desk maps to an Intercom Team with its own inbox. Help Desk routing rules (based on category, priority, or requester group) require manual rebuild in Intercom's Rules Engine. If a single Help Desk covers multiple Intercom Teams (e.g., by topic), we document the split logic during scoping. SLA calendar configurations attached to Help Desks do not migrate as configuration; they are documented for the customer to configure in Intercom's SLA add-on if applicable.

InvGate Companies (external organizations linked to requesters) map to Intercom Contacts with the company name stored in the built-in company field on the Contact. The company domain, size, and custom properties migrate as custom attributes on the Contact. If the customer uses Intercom's native company tracking, we map to the Company object in Intercom with the same domain as the dedupe key.

InvGate Knowledge Articles map to Intercom Help Center Articles. Article title, body content (HTML or text), category, and publish status migrate directly. We export articles in their category hierarchy and create corresponding Collections in the Intercom Help Center. InvGate's article-to-ticket auto-suggestion and ticket linkage do not export; these require manual configuration in Intercom's Help Center settings post-migration. Published status carries over; draft articles remain draft in Intercom.

InvGate SLAs define response and resolution times tied to priority levels and business hours calendars. Intercom's SLA management is a separate add-on product on the Advanced plan. We export SLA configurations as a written document (SLA name, priority level, first response target, next response target, resolution target, business hours calendar) for the customer's admin to configure in Intercom's SLA settings post-migration. SLA breach notification triggers from InvGate are not transferable and require rebuild in Intercom's Rules Engine.

InvGate custom properties extend Requests, Agents, Companies, and other objects with user-defined field types (text, dropdown, checkbox, date, number). We extract the property schema and migrate values as Intercom custom attributes on the corresponding object (Conversation, Contact, or User). Field type mapping follows: InvGate text maps to Intercom string; InvGate dropdown maps to Intercom string (no enum); InvGate checkbox maps to Intercom boolean; InvGate date maps to Intercom date. Multi-select dropdowns require conversion to comma-separated strings.

InvGate's ticket conversations include all public and internal notes, status-change notifications, and attachment references. We migrate the full thread ordered by timestamp, creating sequential Intercom conversation messages. Attachments are downloaded from InvGate and re-uploaded as Intercom file attachments on the corresponding message. Internal notes in InvGate migrate as internal notes in Intercom if the customer's team structure supports them; otherwise they migrate as standard conversation messages with a note in the handoff document.

InvGate Service Catalog Items define requestable services with form fields, associated workflows, and approval requirements. We export catalog item schemas (item name, description, form fields, and associated category) as a written inventory document. Service catalog request routing (which catalog items route to which Help Desk or agent group) cannot migrate as automation. The customer rebuilds catalog items as Intercom conversational forms or Help Center articles with routing handled through Intercom's Rules Engine.