Migrate from Servicetonic Helpdesk Tool to Zendesk

Servicetonic Incidents map directly to Zendesk Tickets. We pre-create a custom ticket_type dropdown field set to 'Incident' on migrated records, preserving incident status (Open, In Progress, Pending, Resolved, Closed), priority (Critical, High, Medium, Low), category, and linked Configuration Items. The original Servicetonic incident ID is stored in a zendesk_external_id reference field so customers can cross-reference historical records by the original identifier.

Servicetonic Service Requests map to Zendesk Tickets using the same pre-created ticket_type field but set to 'Service Request' rather than Incident. Request type, fulfillment steps, approval status, and requester association migrate as standard and custom Zendesk fields. Requests linked to Servicetonic Catalog Items are flagged: the request metadata migrates but the associated fulfillment workflow must be rebuilt in Zendesk as a Trigger or Automation because it represents procedural logic not stored as a ticket field.

Servicetonic Knowledge Base articles migrate to Zendesk Guide Articles with category hierarchy mapped to Zendesk Sections and Categories. Article title, body content (HTML), author, visibility settings, and attachment links transfer. Multilingual articles in Servicetonic (English, French, German, Portuguese, Spanish) require locale-aware mapping to Zendesk's article translations model. We preserve the Servicetonic article ID in zendesk_external_id on each Zendesk article record.

Servicetonic Service Catalog entries define a service offering with description, fulfillment process, and linked forms. The catalog item metadata (name, description, category) migrates as a Zendesk Article or topic entry. The fulfillment workflow logic attached to the catalog item does not transfer as a portable rule; we document every catalog item's associated approval chain and fulfillment steps in a written inventory so the customer's Zendesk admin can rebuild them as Zendesk Triggers, Macros, or Automations.

Servicetonic requester profiles (name, email, organization, location, contact preferences) map to Zendesk End Users. Email address serves as the dedupe key. Organizational affiliation maps to the Zendesk Organization lookup. We resolve Organization references during the Users phase and link End Users to Organizations before ticket import to prevent orphaned requesters. Contact preferences (language, notification channel) migrate as user fields or language locale settings in Zendesk.

Servicetonic agent profiles (name, email, role, team, permission profile) map to Zendesk Agents. We resolve agents by email match against the Zendesk destination. Role and team assignment migrates to Zendesk's Agent roles (Light Agent, Agent, Admin) and Group membership. Permission level mapping depends on whether the destination Zendesk plan includes the specific role capabilities used in Servicetonic; we flag any capabilities that require a higher Zendesk tier or an add-on during the scoping call.

Servicetonic CIs represent IT assets, systems, and components linked to incidents and service requests. Zendesk does not have a native CI management object in standard Suite plans. We migrate CI data as a custom Zendesk object (Zendesk Objects, available on Enterprise) or via a pre-installed CMDB App from the Zendesk Marketplace. CI type, name, location, and relationship to other CIs transfer. Any custom CI relationship graph beyond a two-level hierarchy requires manual reconstruction in the chosen CMDB tool.

Servicetonic SLA definitions tie response and resolution targets to priority level, request type, and time plans. We preserve the SLA metric names and threshold values (e.g., Critical = 1-hour response, 4-hour resolution) and map them to Zendesk SLA Policies with First Reply Time and Next Reply Time targets. Servicetonic's per-team and per-contract business-hour calendars do not map 1:1 to Zendesk's single Schedule object; we flag every non-standard calendar during mapping and map it to the closest Zendesk Schedule, calling out discrepancies for customer approval before import.

File attachments on Servicetonic tickets and knowledge articles migrate as Zendesk ticket attachments and article file uploads. We upload attachments via the Zendesk Attachments API and link them to the corresponding ticket or article. Large attachment batches are chunked and uploaded with retry logic to handle Zendesk's file size limits and rate limiting on the attachments endpoint.

Servicetonic notes on tickets migrate as Zendesk ticket comments. Internal notes map to private Zendesk comments (visible to agents only). Public notes map to public comments. The original note author and timestamp are preserved in the Zendesk comment metadata. Note attachments migrate as described in the Attachments mapping.

Tags applied to Servicetonic tickets migrate as Zendesk tags directly. The multi-value tag format is identical on both platforms, so tag arrays transfer without transformation. Tag-based Servicetonic reporting is noted in the handoff inventory so the customer can configure equivalent tag-based views and triggers in Zendesk.

Servicetonic custom ticket fields and custom fields on knowledge articles require pre-creation in Zendesk before data migration begins. We create Zendesk ticket fields (text, textarea, integer, decimal, date, checkbox, dropdown, multi-select, regexp) to match the Servicetonic field types during the schema design phase. Dropdown and multi-select fields require their option lists manually re-entered in Zendesk's field configuration UI. Custom fields on knowledge articles are created as article attributes in Zendesk Guide.