Helpdesk migration
Field-level mapping, validation, and rollback between Startly and Gorgias. We move data and schema; workflows are rebuilt natively in Gorgias.
Startly
Source
Gorgias
Destination
Compatibility
8 of 12
objects map 1:1 between Startly and Gorgias.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from Startly to Gorgias is a platform-type migration, not a direct equivalent swap. Startly is an ITSM tool built around Tickets, Assets, CMDB configuration items, Projects, and Change Requests with a per-seat pricing model at $15 per user. Gorgias is an eCommerce-native helpdesk that charges per resolved ticket ($10-$900/month) and structures its data model around Customers, Agents, and Tickets with deep Shopify, Magento, and BigCommerce integrations. The schema resolution work centers on three challenges: converting CMDB configuration items and their relationships into Gorgias customer records with tag-based asset metadata, reconstructing SLA policies from a structured reference document rather than a direct export, and preserving knowledge base content while accepting that service catalog approval workflows and ITSM change request workflows do not have Gorgias equivalents. We migrate ticket history, agent records, customer records, and knowledge base articles. We do not migrate ITSM workflows, change approval chains, or project financial data as portable objects.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Startly object lands in Gorgias, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Startly
Ticket
Gorgias
Ticket
1:1Startly Tickets map directly to Gorgias Tickets. We preserve ticket subject, description, status, priority, assignee (mapped to Gorgias Agent), requester (mapped to Gorgias Customer), tags (from Startly categories), and full conversation thread. Startly's ITSM lifecycle states (open, pending, resolved, closed) map to Gorgias ticket status values. SLA response times from Startly are extracted as structured metadata and handed off as a reference document for manual reconfiguration in Gorgias team settings. Ticket ID is preserved as an external_id field for reconciliation.
Startly
User / Team Member
Gorgias
Agent
1:1Startly User records (name, email, role, department, team assignment) map to Gorgias Agents. We match by email as the dedupe key. Active Startly users import as active Gorgias agents with their role preserved as a custom field or permission group. Inactive or disabled Startly accounts are excluded from import to avoid inflating agent counts and creating orphaned tickets. Agent permission levels (admin, agent, viewer) map to Gorgias role equivalents.
Startly
Customer / Requester (linked to Tickets)
Gorgias
Customer
1:1Startly requesters associated with tickets map to Gorgias Customer records. We create one Customer per unique requester email, with name, email, phone, timezone, and language preserved. Any Startly user fields beyond email and name are stored as custom fields on the Gorgias Customer record using Gorgias's custom field API (String, Boolean, Date, Number types supported).
Startly
Asset
Gorgias
Customer (tag metadata)
1:manyStartly Assets (hardware inventory, software licenses, IT equipment) have no direct Gorgias equivalent because Gorgias has no asset management or CMDB module. We resolve this by creating a dedicated customer record (or tagged existing customer) representing the asset entity, and populating asset metadata (name, type, status, assigned user, location) as custom fields and tags on that record. The assigned user reference is preserved as a tag linking to the Gorgias Customer or Agent record. This approach maintains asset context inside Gorgias without orphaning the data.
Startly
CMDB Entry (Configuration Item)
Gorgias
Customer (tag metadata)
1:manyStartly CMDB entries (servers, network devices, software configurations, CI relationships) map to Gorgias Customer records with CI-specific custom fields and relationship tags. Each CI becomes a Customer record with fields for CI type, status, and parent CI. CI-to-CI relationships are stored as tags (e.g., hosted_on, depends_on) that reference the target CI's Customer record. This flattens the CMDB relationship graph into a tag-based model that Gorgias's tag filtering can query. CI-to-asset linkages are preserved as cross-referenced tags. Note that Gorgias cannot run CMDB queries or dependency graphs natively; this is a representational migration only.
Startly
Project
Gorgias
Ticket (tagged)
1:manyStartly Projects (bundles of tasks, time entries, and budgets) map to Gorgias Tickets with a project tag applied. Project metadata (name, description, status, start date) migrates as ticket-level custom fields. Individual Startly tasks attach as child tickets linked via tag to the parent project ticket. Project budget and profitability fields from Startly have no Gorgias equivalent and are exported as a supplemental CSV rather than creating orphan fields. The customer reviews these budget values post-migration.
Startly
Task (standalone)
Gorgias
Ticket
1:1Startly standalone Tasks map to Gorgias Tickets with the task_status, assignee, and due date preserved as ticket custom fields and tags. Task priority maps to ticket priority. Completed status maps to Gorgias resolved status. Custom task properties that have no Gorgias equivalent are stored as ticket-level string or number custom fields.
Startly
Time Entry
Gorgias
Ticket (note attachment)
1:1Startly time entries (linked to tickets or projects) migrate as Note attachments on the corresponding Gorgias Ticket. Each time entry records the duration, linked user, date, and description. We link by resolving the Startly ticket ID (stored as external_id) to the migrated Gorgias ticket. Time entry IDs are not portable and are not recreated as standalone Gorgias records since Gorgias does not have a native time tracking object. The linked ticket reference is preserved so agents can read the time log in context.
Startly
SLA Policy
Gorgias
Team Settings (manual rebuild)
lossyStartly SLA policies (response time, resolution time, business hours, priority-to-SLA mappings) do not export as portable configuration objects. We extract the full SLA definition as a structured reference document listing each SLA name, its priority tier, response and resolution thresholds in hours, and business hours schedule. The customer uses this document to configure response expectations in Gorgias team settings post-migration. This is a documented handoff, not an automated import.
Startly
Knowledge Base Article
Gorgias
Help Center Article
1:1Startly KB articles migrate to Gorgias Help Center articles. Article title, body content, author, created date, and updated date transfer directly. Startly article categories map to Gorgias Help Center categories, though the category hierarchy may be shallower in Gorgias. Article-to-ticket-category relationships are extracted as tag metadata on the article record since Gorgias Help Center articles are not linked to tickets by category reference. Article-to-article internal links are preserved as full URLs; the customer updates them post-migration if the Help Center URL structure changes.
Startly
Change Request
Gorgias
Ticket (tagged)
1:1Startly Change Requests migrate to Gorgias Tickets with a change_request tag and custom fields for risk level, approval status, and affected CIs (resolved to tag references via the CMDB-to-customer resolution above). Approval workflows and risk matrices are not portable; we document the approval chain as a written inventory for the customer's admin to decide whether to recreate as Gorgias Rules or handle outside the platform. Change request linkage to CMDB CIs is preserved as tag references to the resolved Customer records representing those CIs.
Startly
Tag / Label (across objects)
Gorgias
Tag
1:1Startly tags and labels used across tickets, projects, tasks, and assets migrate to Gorgias Tags. Tags used for ITSM categorization (incident, change, problem) map to Gorgias ticket tags. Tags used for asset classification map to the Customer records representing those assets. Tag-to-object relationships are preserved by applying the same tag values during the relevant object's migration. Duplicate tag values across objects are allowed in Gorgias and do not conflict.
| Startly | Gorgias | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| User / Team Member | Agent1:1 | Fully supported | |
| Customer / Requester (linked to Tickets) | Customer1:1 | Fully supported | |
| Asset | Customer (tag metadata)1:many | Fully supported | |
| CMDB Entry (Configuration Item) | Customer (tag metadata)1:many | Fully supported | |
| Project | Ticket (tagged)1:many | Fully supported | |
| Task (standalone) | Ticket1:1 | Fully supported | |
| Time Entry | Ticket (note attachment)1:1 | Fully supported | |
| SLA Policy | Team Settings (manual rebuild)lossy | Fully supported | |
| Knowledge Base Article | Help Center Article1:1 | Fully supported | |
| Change Request | Ticket (tagged)1:1 | Fully supported | |
| Tag / Label (across objects) | Tag1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Startly gotchas
No public self-service export API for bulk data extraction
SLA policies do not export as portable configuration objects
Project budget and profitability fields require custom field mapping
Knowledge base and service catalog relationships do not survive field-level migration
Gorgias gotchas
AI Agent adds outcome-based fees on top of billable ticket costs
Overage billing for tickets scales nonlinearly
API rate limits restrict bulk export throughput
Agent data visibility cannot be restricted by role for GDPR use cases
Knowledge Base translations require separate API calls per locale
Pair-specific challenges
Migration approach
Discovery and export coordination with Startly
We audit the Startly account across all modules: ticket volume and status distribution, user count and role distribution, asset inventory and CMDB entry count, project count, SLA policy definitions, knowledge base article count and category hierarchy, and change request backlog. We simultaneously initiate the data extraction plan with the customer, requesting CSV exports for each module from Startly's grid views and coordinating with Startly's implementation team if API-assisted extraction is needed. We deliver a written data extraction checklist listing every field available per module and every field we recommend extracting. Export file delivery is the first critical path dependency.
Schema design and CMDB resolution plan
We design the Gorgias schema before any data import. This includes provisioning Gorgias Agents (from Startly Users), Customer records (for both ticket requesters and resolved CMDB entries), ticket custom fields (for ITSM-specific properties like change_request flag, ci_affected tags, and sla tier), Help Center categories (mirroring Startly KB categories), and tag taxonomy (merging ITSM incident/change/problem tags with CMDB relationship tags and asset classification tags). The CMDB resolution plan documents every unique CI type and its proposed tag representation in Gorgias. Schema is validated in a Gorgias sandbox environment before production.
Sample migration and reconciliation
We run a test migration using the first batch of Startly export files into a Gorgias test environment. We validate ticket count reconciliation (tickets in Startly export vs tickets created in Gorgias), agent mapping accuracy (assigned agent email match), customer creation (unique requester emails), tag application (ITSM category tags on tickets, CI relationship tags on customer records), and knowledge base article rendering in the Gorgias Help Center. We spot-check 25-50 records in detail and deliver a reconciliation report to the customer for sign-off before production migration begins.
Production migration in dependency order
We run production migration in dependency order: Agents (Agents must exist before ticket assignment), Customers (unique requester emails, plus CMDB customer records for asset and CI entities), Tags (created before ticket import so tag references resolve), Tickets (with external_id tracking to Startly ticket IDs), Time entries (linked via external_id to parent tickets), Help Center articles (with category assignment), and Change Requests (as tagged tickets with CI relationship tags). Each phase emits a row-count report. SLA policies, service catalog items, and change approval workflows are not imported; they are delivered as structured documentation for manual rebuild in Gorgias.
Knowledge base migration and Help Center validation
We migrate Startly KB articles to Gorgias Help Center articles using the Help Center API, preserving title, body content, author, and created/updated timestamps. Article categories are mapped to Gorgias Help Center categories. Article-to-ticket-category relationships and article-to-service-catalog-item relationships are extracted as tag metadata on each article and delivered as a relationship map CSV. We validate article rendering in the Gorgias Help Center preview and confirm category navigation works before launch. Internal links between articles are preserved as full URLs and flagged for post-migration URL updating.
Cutover, validation, and documentation handoff
We freeze new Startly ticket creation during cutover and run a final delta import of any records created or modified during the migration window. We enable Gorgias as the system of record and confirm ticket routing, tag filtering, and agent assignment are functioning correctly. We deliver four documents: the SLA reference sheet for manual recreation in Gorgias team settings, the change request inventory with CI relationship map, the service catalog replacement plan (tickets with catalog tags as a functional alternative), and the automation inventory (Startly workflow rules documented for Gorgias Rules rebuild by the customer's admin). We offer a one-week post-cutover reconciliation window.
Platform deep dives
Startly
Source
Strengths
Weaknesses
Gorgias
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 3 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Startly and Gorgias.
Object compatibility
3 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Startly: Not publicly documented.
Data volume sensitivity
Startly doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Startly to Gorgias migration scoping. Not seeing yours? Book a call.
Walk through your Startly to Gorgias migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Startly
Other ways to arrive at Gorgias
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.