Migrate from iService to Zendesk

iService Tickets map directly to Zendesk Tickets. We map ticket status, priority, and requester (customer) by email lookup against the Zendesk End User created before the ticket import. The iService ticket ID is preserved in a custom ticket field zendesk_original_id__c for cross-reference. Custom ticket fields in iService require explicit mapping to Zendesk custom ticket fields, which must be pre-created in the Zendesk Admin panel before migration begins because Zendesk enforces field type constraints on import.

Each iService Ticket contains a threaded Conversation history. Conversation messages map to Zendesk Comments on the corresponding Ticket. The message author (agent vs customer) is resolved by email match against the Zendesk User or End User table. Public vs private comments are inferred from the iService visibility flag. Conversation timestamps are preserved as the Zendesk Comment created_at value to maintain the thread's chronological ordering.

iService Customer records (end-user side: name, email, phone, custom properties) map to Zendesk End Users. Email is used as the dedupe key. If a Customer is associated with an iService Company, the Zendesk End User is linked to the corresponding Zendesk Organization after the Organization record is created. Custom properties on iService Customer records migrate to Zendesk End User custom fields, which must be pre-created in Zendesk Admin.

iService Company records map to Zendesk Organizations. Organization name is the primary field, and domain or website becomes the Zendesk Organization domain field. Company-level custom properties map to Zendesk Organization custom fields. We create Organizations before the End User import so that the organization_id reference on End Users is satisfied at insert time.

iService Agent accounts (email, name, role, team assignment) map to Zendesk Agents. Role and team assignment from iService are stored as custom fields or agent notes in Zendesk rather than mapping to Zendesk's native Role and Group model, which differs structurally. The customer's Zendesk admin configures Groups and Group membership after migration based on the documented team assignments from iService.

Chat sessions conducted via the iService portal widget are stored as conversation records tied to a customer and can map to Zendesk Comments on the corresponding Ticket if a ticket ID linkage exists in iService. Chat sessions from third-party integrated channels are flagged during data audit because the transcript structure and metadata vary by integration and may not contain a stable ticket reference. These transcripts are migrated as End User profile notes or as standalone Comments with a manual ticket reference where no ticket linkage exists.

iService KB Articles map to Zendesk Guide Articles. The iService KB Category hierarchy maps to Zendesk Guide Sections under a top-level Category. Article body migrates as HTML, with embedded images preserved as file attachments linked to the Article via Zendesk's article attachment API. We flag any articles with HTML or script injection that Zendesk Guide sanitizes on import.

Custom ticket fields in iService vary by tenant configuration. We treat each distinct custom field as requiring explicit mapping during scoping. Field names, data types, and picklist values are documented from the iService admin export and matched to pre-created Zendesk custom ticket fields of the equivalent type (text, dropdown, checkbox, date, number). Multi-select picklists in iService map to Zendesk tag fields or multi-select custom fields.

File attachments on tickets and KB articles are migrated as binary blobs referenced by the parent Ticket or Article record. We preserve the original filename and content-type, and link the attachment to the correct Zendesk Ticket or Article via the Zendesk Attachments API. Attachments exceeding Zendesk's size limits are flagged for the customer to store externally with a reference link migrated to the record.

Tags from iService Tickets and KB Articles migrate to Zendesk Tags. Tag associations are preserved as tag references on the corresponding Zendesk Ticket or Article. Zendesk Tags have a different data model from labels in some other platforms; we map the tag strings directly without transformation and document the complete tag vocabulary for the customer's Zendesk admin.