Migrate from Serviceaide Intelligent Service Management to Zendesk

ISM CCTIs map directly to Zendesk Tickets. Title, description, status, priority, assignee, requester, created date, and modified date transfer as standard Zendesk Ticket fields. ISM custom ticket fields migrate to Zendesk custom Ticket Fields (text, integer, dropdown, checkbox, date) which the customer provisions in the Zendesk admin panel before migration. ISM ticket comments attach as Ticket Comments preserving agent vs requester authorship via the Zendesk comment.author_type field. ISM-13232 SLA-driven group changes do not fire update events; we track these as a separate migration artifact and re-apply group assignments explicitly during the Zendesk insert phase.

ISM Configuration Items map to Zendesk Assets. ISM stores CI relationships and CI Approval Phase metadata. ISM-13238 defect allows special characters in CI Approval Phase fields to corrupt ticket workflow state; we sanitize these characters before insert. CI type (hardware, software, virtual, network) maps to Zendesk Asset Type. CI status (production, decommissioned, under maintenance) maps to Zendesk Asset status field. CI custom fields migrate as Zendesk Asset custom fields provisioned pre-migration.

ISM Knowledge Manager articles map to Zendesk Help Center articles. ISM stores approver names and comments as metadata fields separate from the article body; we extract this as a structured header block appended to the article content so the approval chain is reconstructable in Zendesk. Article publish status, author, last modified date, and tags migrate. ISM articles attached to resolved tickets re-associate via a migration reference table linking the ISM article ID to the resolved ticket so agents can still surface the source article in Zendesk. Zendesk requires Help Center to be enabled on the account.

ISM Service Catalog records represent services with associated SLAs and workflows. Zendesk has no direct service record object. We map ISM services to Zendesk Organizations with a custom service_name field and link them to tickets via the requester Organization relationship. ISM service-to-ticket associations become Organization-to-Ticket links. SLA templates require reconstruction in Zendesk as SLA Policies applied at the Group or Brand level.

ISM Asset Center records (hardware and software inventory) map to Zendesk Assets. ISM Asset Center filter bugs reported by reviewers mean we validate all exported asset field completeness against a record-count reconciliation check before staging. Asset serial number, purchase date, vendor, and assignee transfer. We skip assets with incomplete required fields and surface them in a remediation report for the customer's admin to complete before re-export.

ISM Change Manager records carry risk assessment scores and approval phases. Zendesk does not have a native change management object. We migrate change records as Tickets with a custom change_management_ticket checkbox, risk_score and change_type custom fields, and approval phase stored as a structured text field. ISM change-to-CCTI links become Zendesk Ticket-to-Ticket relationships via a custom field source_change_id for traceability. The customer rebuilds formal change approval workflows in Zendesk's native automation engine post-migration.

ISM agent and analyst accounts map to Zendesk Users with the agent role. We match by email address. ISM role assignments (analyst, approver, admin) map to Zendesk roles (agent, admin). ISM department and location fields become User Fields in Zendesk. Any ISM user without a matching Zendesk user email goes to a reconciliation queue for the customer's admin to provision before record migration continues.

ISM end-user accounts map to Zendesk end users. We match by email; new users are created during ticket import. ISM user custom fields migrate as Zendesk User Fields provisioned pre-migration. Multi-tenant ISM environments may have duplicate email addresses across tenants; we scope extraction to the specific ISM organization ID and flag any cross-tenant collisions for the customer's admin to resolve.

ISM organization records map to Zendesk Organizations. ISM multi-tenancy means we scope extraction to the specific organization ID before staging any payload to prevent cross-tenant data bleed. Organization branding and SLA template configuration at the ISM organization level require reconstruction as Zendesk Brand and SLA Policy settings. ISM organizations without a clear Zendesk equivalent become Zendesk Organizations with a custom is_tenant flag.

Files attached to ISM tickets, knowledge articles, and change records are extracted from the parent object and re-associated with the corresponding Zendesk Ticket or Article. Attachments exceeding 50 MB per file (Zendesk API limit) are flagged in the migration report for the customer's admin to handle as separate downloads. We validate attachment filename encoding during extraction; ISM users may have uploaded files with non-ASCII characters that Zendesk's UTF-8 API accepts but that require explicit handling.

ISM tags used for ticket categorization and filtering map directly to Zendesk Tags. Tags are imported as a set on each Ticket record via the Zendesk Tags API endpoint after ticket creation. ISM tags used for knowledge article classification map to Zendesk Help Center labels on the corresponding article.

ISM allows custom fields on tickets and other objects. We inventory every ISM custom field during discovery, classify its data type (text, integer, date, dropdown, checkbox), and provision matching Zendesk custom Ticket Fields before migration begins. Dropdown fields require the same value set to be created in Zendesk admin. ISM multi-select dropdowns map to Zendesk tagger (multi-select) fields if the Zendesk plan supports them; otherwise they migrate as comma-separated text fields.