Migrate your Startly data

Tickets are the core object in Startly's ITSM module. We migrate full ticket records including status, priority, assignee, requester, description, SLA configuration, and conversation threads. Ticket IDs are preserved as a custom field in the destination to maintain cross-references to historical records.

Assets represent IT inventory items tracked in Startly's asset management module. We map asset name, type, status, assigned user, location, and custom properties. Asset-to-user assignment must be re-linked in the destination since assets do not share the same ID namespace as Users.

CMDB entries in Startly represent configuration items (servers, software, network devices) with relationships to each other and to Assets. We preserve CI-to-CI relationships and CI-to-asset linkages during migration, mapping them to the destination's equivalent configuration management object.

Projects in Startly bundle tasks, budgets, and time entries under a single project record. We migrate project metadata and linked tasks but budget and profitability fields require schema mapping against the destination's project costing model, which varies significantly across platforms.

Tasks exist both as standalone objects and as sub-objects of Projects. Startly supports task assignment, status, and custom fields. We map the primary task fields 1:1 and flag any custom task properties that require reconfiguration in the destination.

User records in Startly include name, email, role, department, and team assignment. We migrate active users 1:1 and flag inactive or disabled accounts that should not be imported to avoid inflating seat counts in the destination platform.

SLA configurations in Startly define response and resolution time targets tied to ticket priority. We preserve SLA-to-priority mappings but SLA rules themselves are platform-specific and must be recreated in the destination ITSM tool based on the same tier definitions.

Knowledge base articles in Startly are associated with ticket categories and service catalog items. We extract article content and metadata but category-to-article relationships require re-establishment in the destination since article IDs are not preserved across platforms.

Service catalog items in Startly define requestable services with associated forms, approval workflows, and KB article links. We migrate the catalog item structure but approval routing rules must be rebuilt in the destination based on the same workflow logic.

Time entries in Startly track labor against tickets and projects. We migrate time entry records with their linked ticket or project reference, but time entry IDs are not portable — they are recreated with a custom field linking back to the original Startly record for audit trail purposes.

Change requests in Startly manage change lifecycle with risk assessment and approval fields. We migrate change request records and their linked CIs from the CMDB, but approval workflows and risk matrices are destination-specific and must be re-implemented.

Post-resolution satisfaction surveys and CSAT scores are stored as a lightweight feedback layer tied to resolved tickets. These are not exported as a standalone data object and we do not include them in standard migration scopes.