Migrate from Incident IQ to Zendesk

Incident IQ Tickets map to Zendesk Tickets with status, priority, assignee, category, and timestamps preserved. The Campus field maps to a Zendesk custom field (dropdown) or Organization lookup depending on whether the district uses Zendesk Organizations to represent campuses. Custom ticket fields (dropdown, text, number) migrate to Zendesk custom fields with value mapping where field types differ. Incident IQ's Issue Category maps to Zendesk Ticket Type or a custom field. Attachments on tickets migrate as Zendesk ticket comments with file attachments.

Incident IQ Assets do not have a native Zendesk equivalent unless the customer licenses Zendesk Asset Management (available on Suite Enterprise). We map asset records in two modes: (1) If Zendesk Asset Management is purchased, we create Zendesk Assets and link them to Tickets via the native asset field. (2) If not, we store asset identifiers (serial number, asset tag, model, assigned user) as a structured custom field or linked comment on the Ticket. Districts with heavy asset-ticket workflows should enable Zendesk Asset Management during migration scoping.

Incident IQ Agents map to Zendesk Users with Agent role. We resolve by email match. Incident IQ role designations (Agent, Admin, IT Admin) map to Zendesk roles (Agent, Admin). The customer's Zendesk admin must provision Agent accounts before migration because OwnerId lookups are required on Ticket import. End-user (requester) accounts from Incident IQ map to Zendesk End Users or to Organizations if the district uses Org-based routing.

Incident IQ Students and Staff who submit tickets (requesters) map to Zendesk End Users. Incident IQ's enrollment-based user model does not map 1:1 to Zendesk's agent vs. end-user model; we extract distinct requester email addresses from Incident IQ Tickets and create Zendesk end-user accounts for any that don't already exist. Districts using Student Information System integration to auto-provision requesters should coordinate student email provisioning before migration.

Incident IQ Campus Locations are a core organizational object that governs asset and ticket assignment. Zendesk does not have a native campus concept. We recommend mapping each Campus to a Zendesk Organization (if the district uses multi-org topology) or to a Tag on the Ticket (simpler single-org deployments). The choice depends on reporting requirements: Organization enables per-org SLA and routing; Tags enable filtering but not SLA assignment. The decision is made during scoping.

Incident IQ Asset Model Categories (e.g., Chromebooks, Laptops, Projectors) define the device taxonomy used in asset tracking and ticketing. These map to Zendesk Tags on tickets and assets, or to a custom field on the Ticket (dropdown listing device type). Locked system-defined model categories from Incident IQ (e.g., Onboarding) cannot be exported and are excluded from migration scope with a notation in the data map.

Incident IQ KB Articles with category hierarchy map to Zendesk Guide Articles organized in Sections and Categories. We extract article title, body content, categories, and article-to-ticket associations. Articles with embedded Incident IQ ticket links will contain broken URLs post-migration; we flag each one in the data map for the customer's admin to update. Zendesk Guide requires activation and configuration before KB import; it is a separate license on Suite Team/Professional and included on Suite Enterprise.

Incident IQ custom ticket fields (dropdown, text, number, date, iiQ User) map to Zendesk custom ticket fields of equivalent type. Critical limitation: Incident IQ field types cannot be changed after creation, so a field created as text cannot later become a dropdown. We extract the current field type from Incident IQ and create the matching Zendesk field. Note that Zendesk's field type is mutable after creation, but changing a type on a live field can affect existing data; we flag any type-mismatch decisions for the customer's approval.

Incident IQ Support Flows are automation chains that route tickets, assign agents, and trigger actions based on conditions. We extract the flow logic and document it as a written inventory specifying trigger events, conditions, and actions. Zendesk Triggers and Macros use a different event model (ticket creation, status change, channel-based) and cannot accept Support Flow logic as a direct migration. The customer's admin rebuilds Support Flow logic in Zendesk's Trigger and Automation interface using our documented inventory as the specification.

Incident IQ Facilities Management Work Orders are a distinct object type for maintenance and facilities staff. Zendesk does not have a native CMMS or work order object. We extract the Work Order schema (status, priority, assignee, location, description) and document it as a written handoff for the customer's admin. If Zendesk's Workato or another iPaaS integration is in scope, we can map Work Orders to a Zendesk Ticket Record Type with a custom fields structure to replicate the facilities workflow. Standalone CMMS migration (e.g., to FMX or MaintainX) is a separate engagement.