Migrate from Startly to Zendesk

Startly Tickets migrate directly to Zendesk Tickets. We map status (open, pending, resolved, closed), priority (low, medium, high, critical), assignee, requester, description, and full conversation threads. Startly SLA configuration maps to Zendesk's built-in SLA engine (Business Hours, First Reply Time, Next SLA Breach) which we configure as a reference guide from the Startly export. Zendesk's 28-day auto-close rule for Solved tickets is documented during scoping; customers on Suite Growth and above can adjust the automation timing in Zendesk Admin Center.

Startly Assets (hardware inventory, software licenses, peripherals) have no native Zendesk equivalent. We split the mapping: asset name, type, and status migrate to Zendesk Organizations with a zdsk_asset_type__c custom field; assigned user maps to the Organization's linked Users; location maps to a custom field. Asset lifecycle status (active, maintenance, retired) becomes a zdsk_asset_status__c tag. Customers on Suite Enterprise with Service Cloud can alternatively model assets as Custom Objects with a lookup to the requester Organization.

Startly CMDB entries (servers, network devices, software instances) with CI-to-CI and CI-to-asset relationships require a two-part mapping. We export CI name, type, serial, and relationship references, then load the CIs as Zendesk Organizations with zdsk_ci_type__c and zdsk_serial__c custom fields. CI-to-CI relationships become Zendesk Tags using a naming convention (e.g., depends_on_<ci_name>) because Zendesk has no native relationship graph for organizations. CI-to-asset linkages are preserved as tags on the linked Organization record.

Startly Users (agents and team members) map directly to Zendesk Users. We match by email address as the dedupe key. Role (admin, agent, requester) maps to Zendesk's role structure (admin, agent, light agent on Suite Team). Inactive or disabled Startly accounts are excluded from the primary import to avoid inflating Zendesk seat counts on Suite Growth and above. The customer provisions any new Zendesk Users before production import begins.

Startly Projects with tasks, budgets, and profitability data have no native Zendesk equivalent. We migrate project name, description, task count, and linked task metadata as a structured CSV. Budget and profitability fields are extracted and delivered as a supplemental reference document because Zendesk has no project module and most destination tools handle financial tracking differently. We document the original project-to-task linkage so the customer's admin can reassign task-level work in their chosen project management tool post-migration.

Startly Change Requests with risk assessment, approval fields, and linked CIs map to Zendesk Tickets with zdsk_change_request__c, zdsk_risk_level__c, zdsk_approval_status__c, and zdsk_affected_ci__c custom fields. The change lifecycle (draft, submitted, approved, rejected, implemented, closed) maps to a zdsk_change_status__c drop-down field. Zendesk Service Cloud customers may prefer Custom Objects for change management; we design the schema during scoping based on the customer's Zendesk tier.

Startly SLA definitions (response time, resolution time, business hours tied to priority tiers) are platform-specific configuration that does not export as portable objects. We extract the SLA schedule values from Startly's export as a structured reference document and deliver it to the customer before cutover. The customer's Zendesk admin recreates the SLA in Zendesk Admin Center > SLA Policies using the Startly reference values. We do not migrate SLA rules as code because they are not accessible in a portable format from Startly.

Startly Knowledge Base articles with title, body, category association, and author migrate to Zendesk Guide Articles. We map article content 1:1 and set the Zendesk Guide section mapping based on the Startly category hierarchy. Startly's article-to-category and article-to-catalog-item relationships are not exported as foreign keys; we document the original linkages and re-establish them in Zendesk Guide's section structure. Zendesk Guide must be activated before article import; we coordinate this with the customer during Zendesk preparation.

Startly Service Catalog items (requestable services with associated forms, KB links, and approval routing) do not have a direct Zendesk equivalent. We extract catalog item name, description, associated KB articles, and approval chain as a written reference document. Requestable service types map to a zdsk_service_catalog__c drop-down field on Zendesk Tickets so agents can categorize incoming requests by the original service type. Approval routing rules are documented for manual rebuild in Zendesk's workflow or a third-party ITSM integration.

Startly Time Entries linked to tickets and projects migrate as private Zendesk Ticket Comments with a zdsk_time_entry__c label and duration preserved in the comment body. We extract time entry records with linked ticket reference, date, duration, and billable/non-billable flag as a supplemental CSV for the customer's admin to import into a dedicated time tracking tool if Zendesk's native time tracking is not available on their tier. Time entry IDs are not portable across platforms.

Startly post-resolution satisfaction surveys and CSAT scores are not exported as a standalone data object and cannot be included in the migration. We flag this gap in the scoping document and recommend that the customer activate Zendesk's native CSAT survey (available on Suite Growth and above) after cutover to begin collecting satisfaction ratings from the migration date forward. Historical Startly survey data is preserved in the Startly export file for any ad-hoc reporting needs.