Migrate from Siit to Zoho Desk

Siit Requests map directly to Zoho Desk Tickets. The request title becomes Ticket Subject, description maps to the initial thread comment, submitted_from (slack, ms_teams, employee_portal, mail) maps to an incoming channel field we create as a Zoho custom field. Status maps to Zoho Ticket Status, priority maps to Priority, and assignee_admin_uid resolves to a Zoho Agent record matched by email. Thread history (communication) migrates as Zoho Ticket Threads in chronological order. First-replied-at and first-completed-at SLA timestamps migrate as typed custom fields.

Siit People records migrate to Zoho Desk Agents. The critical mapping distinction is Siit Admin vs non-Admin provisioning: Siit Admins (resolvers) map to Zoho Desk Agents; Siit non-Admin employees who only submitted requests map to Zoho Contacts or remain unprovisioned if the Zoho Desk plan is lower-tier. We audit the Siit Admin list before migration, provision Zoho Agents only for the resolver count, and flag any discrepancy so the customer avoids a month-one billing spike on Zoho Desk's per-agent model.

Siit Services with catalog-item structure and configuration metadata map to Zoho Desk Products (for billable or trackable service items) or Knowledge Base Articles (for self-service request types). We classify each Siit Service during scoping based on whether it has pricing, SLA configuration, or approval workflow associations. Services with workflow dependencies are flagged as requiring manual Zoho Blueprint reconstruction post-migration. Services without workflow associations migrate directly as Knowledge Base articles linked to the relevant Zoho Desk department.

Siit Equipment records include lifecycle attributes, ownership details, and device configuration fields. Zoho Desk does not have a native equipment inventory object. We migrate Equipment as structured records with key fields (name, serial, status, owner, location) mapped to Zoho custom fields on a Zoho Desk Ticket or a linked Zoho Creator application. If the customer requires a full CMDB, we recommend Zoho Creator as a separate module; we document the schema and deliver the Creator application definition as part of the migration handoff.

Siit Application inventory records track software assets with ownership fields, lifecycle status, and category metadata. These map to Zoho Desk Products with the product type set to Services to distinguish software assets from physical products. We preserve application-to-person associations as Zoho custom fields on the Product record.

Siit Communication exports include outbound messages and satisfaction survey responses linked to requests. We map these to Zoho Ticket Threads with direction (inbound/outbound) preserved, timestamps preserved, and agent/authorship information resolved to the matching Zoho Agent. Satisfaction survey responses migrate to Zoho Desk CSAT scores and survey response records where the destination schema supports them.

Siit tags migrate to Zoho Desk Tags as a flat taxonomy. Tag associations with requests are preserved through a tag-apply step after ticket import. Zoho Desk tags are applied post-ticket-creation via the tag API endpoint, so we run tag assignment as a second pass after all tickets are in place.

Siit Inboxes route requests to specific teams or queues. We map each Siit Inbox to a Zoho Desk Department with the same team membership. Agents are assigned to the target Department during provisioning. Inboxes with conditional routing rules are documented as Zoho Desk Routing Rules and handed off to the customer's admin for Blueprint or macro configuration.

Siit SLA data (first_replied_at, first_completed_at, SLA timers, escalation configurations) migrates as Zoho custom fields on the Ticket record. We preserve the original SLA configuration as a separate reference document so the customer's admin can reconstruct Zoho Desk SLA policies (available on Professional and Enterprise tiers) against the migrated timers.

Siit requests carry custom_form_inputs as label/value pairs with no fixed schema across organizations. We extract every unique label during the migration scan, create matching Zoho Desk custom fields of the appropriate type (text, picklist, number, date), and map values at the field level. Where the destination field type does not support a Siit input (e.g., complex nested data), we serialize the inputs as a structured JSON attachment on the Ticket record.

Siit Workflows include trigger conditions, approval chains, and automated actions. We do not migrate workflow logic as code because Zoho Desk Blueprint operates on linear ticket processes rather than the event-driven workflow model Siit uses. We capture every active Siit Workflow as a written inventory document covering trigger type, conditions, actions, and usage counts, with a recommended Zoho Blueprint or macro equivalent for the customer's admin to rebuild post-migration.

Siit Admin seat records (including role-based access control assignments) map to Zoho Desk Agent profiles. We resolve each Siit Admin by email to a Zoho Agent, preserving role information (Admin, Resolver, Viewer) as Zoho Desk agent roles. Non-Admin Siit users are optionally migrated as Zoho Contacts if the Zoho Desk plan supports Contact records and the customer wants a full employee directory in the help desk.