Migrate from SMART Service Desk to Zendesk

Requests are the core ticket object in SMART Service Desk and map directly to Zendesk Tickets. We migrate request status, priority, category, requester name and email, assigned technician, conversation history (public and internal comments), and any file attachments. The SMART request ID is preserved in a Zendesk custom field for cross-reference. Priority and status values are mapped to the nearest Zendesk equivalents based on the customer's configured workflow states.

Problems carry ITIL-specific fields: root-cause description, impact assessment, urgency, priority, and a Problem-Request association linking the Problem to its originating Request. We map these to a Zendesk Ticket with custom fields for impact_level, urgency, and problem_id, plus a tag problem_record to distinguish ITIL Problem records from standard tickets in reporting. The Problem-Request linkage is preserved as a custom field reference rather than a native Zendesk object relationship.

Change records carry ITIL lifecycle metadata: Change Category, Risk level, Impact level, approval status, planned start and end dates, and associated CAB membership. We map these to a Zendesk Ticket with custom fields change_category, risk_level, impact_level, change_status, planned_start, planned_end, and cab_approvers. Approval status history migrates as internal comments with timestamps. Note that Change ID sequences (RITM-001 style) are reassigned by the destination; we raise this during scoping and flag a post-migration clean-up task if the customer requires original ID preservation.

Releases follow a scheduled deployment lifecycle with planned start and end dates, assigned technician, status, and Release-to-Change associations. We map these to Zendesk Tickets using custom fields release_planned_start, release_planned_end, release_status, and release_changes to preserve the release-change linkage. The release_description migrates to the ticket body. Release-to-Change associations are stored as a comma-separated list of Change IDs in the release_changes custom field since Zendesk does not have a native release management object.

Assets in SMART Service Desk include workstation records, components, consumables, and allocation details with name, serial number, type, location, assigned user, and status. We migrate assets as Zendesk Configuration Items when the destination Zendesk instance includes the Assets add-on. Assets without an active Zendesk Assets license are migrated as a custom Zendesk object with the same field schema so the data is not lost even if the customer does not license the native Assets feature immediately.

Solutions are the knowledge-base articles in SMART Service Desk, including article title, body content, summary, category, and publication status. We map these to Zendesk Help Center articles under the appropriate Section. HTML body content is cleaned and converted to the Help Center's article body format. Publication status (published, draft, archived) maps to the Zendesk article draft field. Articles linked to specific SMART categories are re-mapped to the nearest Zendesk Help Center section structure, which we configure before migration.

SMART Service Desk Categories are the taxonomy used to classify Requests, Problems, and Changes. We export the full category tree and re-create it in Zendesk as Help Center Section hierarchy. Category assignments on tickets are preserved as tags (prefixed with category_) for use in Zendesk's tag-based reporting and workflow routing. The customer chooses during scoping whether to use a flat tag structure or a hierarchical one matching the SMART category tree.

Contracts record vendor agreements and SLA terms attached to Requests or Assets, including contract name, type, vendor reference, start and end dates, and SLA tier. We migrate these as a Zendesk custom object contract with fields matching the SMART schema, linked to the associated Request ticket via a lookup field. Multi-document contracts are attached as files to the contract record. If the destination Zendesk instance does not yet have custom objects enabled, contracts migrate as a structured ticket field with the contract data serialized as JSON.

Vendor records store name, contact details, and type. We map these to Zendesk Organizations with the vendor type stored in a custom organization field. Vendor associations to Purchase Orders and Contracts are preserved as tags on the Organization record since Zendesk does not have a native vendor management object. If the customer uses Zendesk's native Vendor Management for Service (available in some Zendesk Suite tiers), we map directly to that object instead.

User records include name, email, department, site, and role. We map active technicians to Zendesk Agents and inactive users to End Users. Department-level role resolution is handled differently between SMART Service Desk on-premises (resolver based on requester's department) and cloud (resolver based on the request's own department field); we detect the deployment variant during discovery and remap approval routing rules to match the destination's department resolution logic so approvals reach the correct inboxes post-migration. Users without an active login in SMART Service Desk are flagged for manual provisioning in Zendesk.

Change Advisory Board members and their CAB associations migrate as Zendesk Agents with a cab_member custom field set to true and cab_board_name indicating the board affiliation. CAB approval history for each Change migrates as internal comments recording the approver, decision, and timestamp. We cross-reference all CAB member records against the user list during discovery and flag any member without an active SMART Service Desk login account, since those members are silently omitted from the export with no error message in the source platform.

SLA configurations in SMART Service Desk (first response time, resolution time by priority) map to Zendesk SLA Policies attached to the appropriate ticket types. We create Zendesk SLA Policies matching the SMART SLA terms before ticket migration begins, so that imported tickets are immediately covered by the correct SLA tier. Business hours definitions from SMART migrate to Zendesk Business Hours settings so that SLA clock pauses correctly during off-hours.