Migrate from iService to Zoho Desk

iService Tickets map directly to Zoho Desk Tickets. Standard fields (subject, description, status, priority, created time, modified time) migrate 1:1. Custom ticket fields on iService are tenant-specific text, number, date, dropdown, or checkbox fields that we audit during scoping, create as equivalent Zoho Desk custom fields via the Layout Editor before import, and map by field name and data type. The iService ticket ID is stored as an external reference field ticketExtId for reconciliation. Status values are mapped to Zoho Desk Status (Open, On Hold, Pending, Closed, Closed - Unresolved) and Priority values to Priority (Low, Medium, High, Urgent). Owner resolution uses agent email match against Zoho Desk agent records.

iService Ticket Conversations contain threaded messages between agent and customer. We map iService conversation messages to Zoho Desk Thread records for customer-visible replies and Comment records for internal agent notes. Thread direction (incoming customer vs outgoing agent) must be resolved from the iService conversation source channel. Messages from the embedded portal widget and email channel carry directional metadata; messages from integrated chat channels may require review during the data audit phase. Message timestamps preserve the original iService created time to maintain the ticket timeline.

iService Customer records (end-user contact level) map to Zoho Desk Contacts. Standard fields (first name, last name, email, phone, mobile, address) migrate directly. Custom contact properties in iService map to Zoho Desk custom contact fields. The customer email is used as the dedupe key during import. If a Contact with the same email already exists in Zoho Desk, we associate it rather than create a duplicate. iService customer type (end user vs portal user) is preserved as a custom field for segmentation.

iService Company records map to Zoho Desk Accounts. The company name becomes Account Name, and the company website maps to the Website field. Company-level custom properties migrate to Zoho Desk custom Account fields. Account must be created before any Contact import so that the Contact-to-Account lookup relationship (AccountId) is satisfied at the moment of Contact insert. Phone, email, industry, street, city, state, country, and zip map to the corresponding Zoho Desk Account fields.

iService Agents (staff accounts with roles, team assignments, and email) map to Zoho Desk Agents. Agent email is the dedupe key; if a Zoho Desk agent with the same email exists, we map to the existing record. Role structures differ: iService uses a role-plus-team model while Zoho Desk assigns agents to departments with department-level permissions. We map iService team assignments to Zoho Desk department membership and default to a standard agent role with the ability to elevate per the customer's department hierarchy design. Any iService agent without a matching Zoho Desk agent goes to a reconciliation queue for the customer's admin to provision before record import.

iService live chat transcripts are stored as conversation records tied to a customer. We flag chat transcripts for explicit handling during the data audit phase because transcript format varies by channel: embedded portal widget chats and integrated third-party channel chats may carry different metadata. Chat sessions with complete directional metadata (customer message vs agent message with timestamps) map to Zoho Desk Ticket Threads with the thread origin flagged as Chat. Sessions without directional metadata are mapped as a single Thread entry with a transcript note. Zoho Desk does not have a dedicated chat object; chat history lives within the ticket conversation structure.

iService KB articles containing content, categories, and attachments map to Zoho Desk KB articles. We export iService article HTML content and import it into Zoho Desk via the KB API or Zswitch. KB Categories map to Zoho Desk category hierarchy. Article attachments are flagged for explicit handling: Zoho Desk's native Zswitch migration tool does not transfer article attachments, so we use the Zoho Desk API to upload attachments after article ingestion or flag the gap for manual re-upload by the customer's admin. Author information from iService is preserved in a custom article field.

iService custom ticket fields are tenant-specific and include text fields, numeric fields, date fields, dropdown lists, and checkbox fields. We audit every custom field during scoping: we capture the field name, data type, picklist values (for dropdown), and any conditional display rules. We then create equivalent Zoho Desk custom fields via Setup > Customization > Layouts and Fields before any ticket import begins. Picklist values map 1:1. Conditional display logic in iService does not migrate and is documented for manual recreation in Zoho Desk blueprints if required. Lookup fields from iService are recreated as Zoho Desk Lookup fields pointing to the relevant module (Contact, Account, or a custom object).

File attachments on iService Tickets and KB articles are migrated as binary blobs referenced by the parent record. We preserve attachment filenames and link them to the correct ticket or KB article in Zoho Desk. Ticket attachments are associated via the Zoho Desk Attachment endpoint linked to the Ticket object. KB article attachments require separate API upload calls after article ingestion; Zswitch does not transfer these automatically, so we either handle them via API or flag for manual re-upload. Attachment file size limits in Zoho Desk (25 MB per file) are enforced during import; files exceeding the limit are flagged for the customer to host externally and link.

iService tags are used to label Tickets and KB articles. We migrate tags as Tag records in Zoho Desk and remap tag associations to the parent object (Ticket or KB Article). Tag naming conventions between source and destination may differ; we do a name-normalization pass during scoping to merge duplicates. Tags that exist in Zoho Desk with the same name are reused rather than recreated. Zoho Desk tags are scoped per module (Tickets, Contacts, Accounts), so tag migration is module-specific.

iService workflow rules define ticket routing, status changes, and notification triggers. These automations are tightly coupled to iService's internal engine and cannot be migrated to Zoho Desk. We document every active iService workflow during scoping: trigger event, conditions, actions, and notification recipients. This documentation is delivered as a written inventory with a recommended Zoho Desk Blueprint or Macro equivalent for each workflow. The customer's admin or a Zoho implementation partner rebuilds automations post-migration. This applies to routing rules, status triggers, notification workflows, and any escalation logic.

iService portal configuration data including branding, domain settings, and portal visibility rules are platform-specific and cannot be migrated to Zoho Desk's customer portal. We document the iService portal settings during scoping: portal URL, branding elements (logo, color scheme, if extractable), and visibility rules for ticket submission and KB access. Zoho Desk's Customer Portal is configured independently post-migration. We do not migrate portal configuration as code or data.

If iService includes Product records used in ticket context (for product-issue tracking), these map to Zoho Desk Products. The product name, product code, and description migrate. Products in Zoho Desk can be linked to tickets for product-specific issue tracking and reporting. If iService does not use a Product object, this mapping is omitted from the final scope.