Helpdesk migration
Field-level mapping, validation, and rollback between Incident IQ and Zoho Desk. We move data and schema; workflows are rebuilt natively in Zoho Desk.
Incident IQ
Source
Zoho Desk
Destination
Compatibility
7 of 12
objects map 1:1 between Incident IQ and Zoho Desk.
Complexity
CModerate
Timeline
4-6 weeks
Overview
Incident IQ is purpose-built for K-12 service management with enrollment-based pricing, module tiers spanning IT Ticketing through HR Service Delivery, and K-12-specific asset tracking by student and device. Zoho Desk is a general-purpose multi-channel help desk with per-agent pricing, a free tier for up to three users, and a documented import pipeline that accepts agents, accounts, contacts, tickets, threads, knowledge base articles, and products via CSV or the Zwitch managed migration service. The two platforms share no common schema ancestry, so every mapping is an explicit transformation: Incident IQ model categories become Zoho Desk Products, support flows become Blueprint documentation requiring rebuild, and K-12-specific custom fields (student assignment, device tag, asset type) require pre-migration custom field creation in Zoho Desk. We migrate tickets, users, asset records, knowledge base articles, and module objects in scope. We do not migrate Support Flow automation chains as code, HR request form definitions, or embedded KB article attachments; we deliver structured written inventories for the district admin to rebuild post-migration.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Incident IQ object lands in Zoho Desk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Incident IQ
Ticket
Zoho Desk
Ticket
1:1Incident IQ tickets map directly to Zoho Desk tickets. Status, priority, assignee, category, and timestamps migrate 1:1. Campus assignments map to Zoho Desk Department or a custom Location field depending on the district's chosen department structure. Custom fields on tickets (device type, building, reported-by) require pre-migration custom field creation in Zoho Desk. Thread/response history migrates as ticket comments in chronological order.
Incident IQ
Asset
Zoho Desk
Product
1:1Incident IQ assets (devices, Chromebooks, projectors) map to Zoho Desk Products as catalog items with the asset tag, serial number, and assignment status stored in custom fields. Asset-to-user assignment associations migrate as a custom Asset_Assigned_To__c field linked to the contact record. Asset status (Available, Checked Out, In Repair) requires a custom picklist field in Zoho Desk since Products do not natively track assignment state.
Incident IQ
User
Zoho Desk
Agent
1:1Incident IQ users (staff, students, agents) map to Zoho Desk agents by email match. Active Incident IQ agents become active Zoho Desk agents with the same role designation. Student user records that are ticket requestors (not agents) map to Zoho Desk contacts. Any Incident IQ user without an email address is flagged in the reconciliation report for the district admin to assign a Zoho Desk contact record before migration.
Incident IQ
Location (Campus)
Zoho Desk
Department
lossyIncident IQ campus locations map to Zoho Desk Departments so that tickets and asset assignments retain their campus context. We create the department hierarchy in Zoho Desk before ticket migration begins, then reference the department ID as a lookup on each ticket record. If Incident IQ locations use a multi-level hierarchy (District > Campus > Building), we flatten it to a two-level department structure in Zoho Desk with a custom Parent_Campus__c field for deeper hierarchy.
Incident IQ
Asset Model Category
Zoho Desk
Product
lossyIncident IQ model categories (Chromebooks, Laptops, Projectors, Lockers) define the device taxonomy and appear in the asset record. We map these to Zoho Desk product categories. Some Incident IQ system-defined model categories are locked and cannot be exported; we identify these during discovery and exclude them from migration scope, noting the exclusion in the data map. The locked-category limitation is an Incident IQ platform gotcha, not a Zoho Desk compatibility issue.
Incident IQ
Custom Ticket Fields
Zoho Desk
Custom Fields
lossyIncident IQ custom ticket fields (K-12-specific dropdowns, multi-select fields, date fields) require pre-migration custom field creation in Zoho Desk with equivalent field types. Dropdown fields in Incident IQ map to picklist fields in Zoho Desk with the same value set. Multi-select fields map to multi-select picklist fields. Value mapping is validated during the sandbox migration phase before production cutover.
Incident IQ
Custom Asset Fields
Zoho Desk
Custom Fields on Product
lossyIncident IQ custom fields on assets (student name, student ID, purchase order number, warranty expiration, location within building) require custom fields on the Zoho Desk Product record. Field type conversions apply: date fields map to date fields, text fields to text fields, and picklist fields to picklist fields. Fields referencing student identifiers require district approval for data handling since FERPA compliance applies to student record fields during migration transit.
Incident IQ
Support Flows
Zoho Desk
Blueprint Documentation
1:1Incident IQ Support Flows (automation chains that route tickets, assign agents, and trigger actions) do not migrate as code because Zoho Desk Blueprint uses a different process definition model. We extract the flow logic—trigger events, condition branches, and action sequences—and deliver it as a written process map documenting the original flow for the district admin to rebuild in Zoho Desk Blueprint. We flag trigger conditions that Zoho Desk Blueprint does not support natively so the admin knows where custom workflow rules will be needed.
Incident IQ
Knowledge Base Articles
Zoho Desk
Knowledge Base Article
1:1Incident IQ knowledge base articles with categories and article content migrate to Zoho Desk knowledge base articles. Categories map to Zoho Desk categories. Article-to-ticket linking is preserved as a custom field ticket_id__c on the Zoho Desk article record. Articles with embedded links to other Incident IQ tickets are flagged in the migration report for post-migration URL redirect updates. The embedded file attachments on KB articles are a known limitation of Zoho Desk KB import and are documented in the gotchas section.
Incident IQ
Facilities Work Orders
Zoho Desk
Ticket
1:manyIncident IQ Facilities Work Orders (distinct from IT tickets) map to Zoho Desk tickets with a custom Department field set to Facilities and a custom Work_Order__c flag set to true. Incident IQ work order-specific fields (work type, trade specialty, scheduled date) map to custom fields on the Zoho Desk ticket. If Incident IQ uses separate statuses for work orders (Pending, Scheduled, In Progress, Complete) that do not match standard Zoho Desk ticket statuses, we create a custom picklist for work order status after scoping with the district facilities director.
Incident IQ
HR Requests
Zoho Desk
Ticket or Task
1:1Incident IQ HR Service Delivery requests have no direct equivalent in Zoho Desk's standard object model. We scope the migration with the district's HR director to determine whether HR requests should migrate as Zoho Desk tickets with a custom HR category, as Tasks attached to the HR contact, or as a separate Zoho Desk department. Form submission data and completion status migrate as custom fields or attachments on the chosen target object. Form field definitions (conditional logic, required fields) do not migrate and are included in the rebuild inventory.
Incident IQ
Attachment
Zoho Desk
Attachment
1:1Ticket attachments, KB article files, and form uploads migrate as file attachments on the corresponding Zoho Desk records. We handle files over 25MB with chunked transfer. Files over the Zoho Desk API size limit (typically 20MB per attachment) are flagged for the district admin to host externally and link via URL field. KB article attachments are subject to the Zoho Desk documented limitation and are migrated separately with a post-migration reattachment guide for the admin.
| Incident IQ | Zoho Desk | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| Asset | Product1:1 | Fully supported | |
| User | Agent1:1 | Fully supported | |
| Location (Campus) | Departmentlossy | Fully supported | |
| Asset Model Category | Productlossy | Fully supported | |
| Custom Ticket Fields | Custom Fieldslossy | Mapping required | |
| Custom Asset Fields | Custom Fields on Productlossy | Mapping required | |
| Support Flows | Blueprint Documentation1:1 | Mapping required | |
| Knowledge Base Articles | Knowledge Base Article1:1 | Mapping required | |
| Facilities Work Orders | Ticket1:many | Fully supported | |
| HR Requests | Ticket or Task1:1 | Fully supported | |
| Attachment | Attachment1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Incident IQ gotchas
Enrollment-based pricing requires accurate student count
Locked system model categories cannot be migrated
Asset timeline history retention duration is undocumented
Bulk API is not publicly documented
Annual subscription price increases are non-negotiable for most districts
Zoho Desk gotchas
Agent email identity determines comment ownership after migration
Blueprints and SLA policies do not export via API
File upload capped at 10GB per migration batch
Tier-gated export and migration capabilities
Inbound migration is two-phase with a hard Phase 2 cutoff
Pair-specific challenges
Migration approach
Discovery and export coordination
We audit the Incident IQ tenant for all active modules (IT Ticketing, Asset Management, Facilities, Events, HR), record counts across tickets, assets, users, KB articles, work orders, and HR requests, and the full list of custom fields on each object. We identify locked system model categories during discovery and exclude them from migration scope. We initiate the bulk export request to the Incident IQ technical services team during this phase so that the structured export file is available when migration execution begins. The discovery output is a written migration scope with record counts per module and a list of pre-migration custom fields to create in Zoho Desk.
Zoho Desk schema pre-configuration
We create all required custom fields in Zoho Desk before any data is migrated. This includes custom fields for ticket assignment tracking (campus, building, device tag, student identifier), product fields for asset management (serial number, asset tag, assignment status, warranty expiration), and department-level configuration for the Facilities and HR modules. We set up departments to mirror the Incident IQ campus hierarchy, configure ticket status values to accommodate both IT and non-IT workflows, and create the knowledge base category structure. All schema changes deploy to a Zoho Desk sandbox or staging environment first for validation.
Sandbox migration and reconciliation
We run a representative migration into the Zoho Desk staging environment using a subset of production data (typically 100-200 records per object type). The district IT director reviews migrated tickets for field accuracy, confirms that asset associations link to the correct contacts, validates knowledge base article content, and spot-checks knowledge base article attachments. We reconcile record counts and flag any mapping discrepancies for correction before the production migration begins. Sandbox sign-off from the district admin is required before production cutover.
User and contact provisioning
We extract every distinct user referenced on Incident IQ tickets, assets, work orders, and KB articles and match them by email against the Zoho Desk agent and contact tables. Incident IQ users without email addresses (student-assigned devices where the student record lacks an email) are flagged in a reconciliation report and resolved as Zoho Desk contacts with a placeholder email or name field. The district admin provisions any missing Zoho Desk agent accounts before the production migration phase so that all ticket assignee references resolve correctly during import.
Production migration in dependency order
We migrate Zoho Desk records in dependency order: departments first (since tickets reference them), then agents and contacts, then products (since assets reference them), then tickets (with campus and assignee resolved), then work orders and HR requests (as enriched tickets or tasks), then knowledge base articles (with category links validated), and finally attachments (with file size exceptions flagged for manual reattachment). Each phase emits a row-count reconciliation report. Any Incident IQ KB article with an embedded ticket link is flagged in the migration report for post-migration URL update.
Cutover, validation, and rebuild handoff
We freeze Incident IQ write access during cutover and run a final delta migration of any records modified during the migration window. Zoho Desk becomes the system of record once delta records are confirmed. We deliver the Support Flow process map (for Blueprint rebuild), the KB article attachment reattachment guide, and the Facilities and HR module configuration notes as a structured rebuild inventory. We provide a one-week hypercare window for the district admin to report data discrepancies. We do not rebuild Support Flows, form definitions, or HR request workflows inside the migration scope; these are separate rebuild engagements for the district admin or a Zoho Desk implementation partner.
Platform deep dives
Incident IQ
Source
Strengths
Weaknesses
Zoho Desk
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 4 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Incident IQ and Zoho Desk.
Object compatibility
4 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Incident IQ: Not publicly documented.
Data volume sensitivity
Incident IQ doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Incident IQ to Zoho Desk migration scoping. Not seeing yours? Book a call.
Walk through your Incident IQ to Zoho Desk migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Incident IQ
Other ways to arrive at Zoho Desk
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.