--- title: SurveySparrow Ticket Management vs Freshservice (2026) slug: surveysparrow-ticket-management-vs-freshservice-2026 date: 2026-08-25 author: Roopi categories: [Freshservice, Help Desk, Migration Guide] excerpt: "SurveySparrow Ticket Management vs Freshservice compared: architecture, TCO, API constraints, and step-by-step migration in both directions." tldr: Freshservice is ITIL-aligned ITSM for internal IT; SurveySparrow is feedback-first ticketing for CX teams. No native migration path exists — every move requires custom API-to-API ETL with careful data model translation. canonical: https://clonepartner.com/blog/surveysparrow-ticket-management-vs-freshservice-2026/ --- # SurveySparrow Ticket Management vs Freshservice (2026) # SurveySparrow Ticket Management vs Freshservice (2026) **SurveySparrow Ticket Management is a feedback-first ticketing module that turns survey responses and NPS detractors into actionable tickets. Freshservice is an ITIL-aligned IT service management (ITSM) platform built for internal IT and employee service operations.** They solve fundamentally different problems, target different teams, and model support data in incompatible ways. If you're comparing them, you're deciding whether your operation needs a CX-driven feedback loop or an enterprise IT service desk — and the answer shapes everything from cost to data architecture to migration complexity. There is no native migration path between these platforms. No vendor-endorsed connector, no pre-built integration, and no CSV import that handles the full scope. Every migration requires custom API-to-API ETL. > [!NOTE] > **Naming note:** SurveySparrow's ticketing module appears as **Ticket Management** in some docs, **SparrowDesk** on pricing pages and Zapier integrations, and **Frontline** on its mobile app surface. These are the same product. Freshservice should not be confused with Freshdesk — Freshservice serves internal employees via ITIL; Freshdesk serves external customers via omnichannel support. ## Architecture and Data Model: The Core Structural Gap Before comparing features or pricing, understand the data model gap. These platforms organize support data in fundamentally different ways. Forcing one model into the other without transformation breaks threads, loses context, and corrupts relationships. ### Freshservice's Data Model Freshservice is an ITSM platform for internal IT and employee services, built on ITIL (incidents, problems, changes, assets/CMDB, service catalog). The organizational model is company → employee — not brand → customer. Core entities: - **Tickets (Incidents):** The primary work unit. Each ticket has a requester (an employee), an assigned agent, priority, status, SLA policy, category, sub-category, item, and custom fields. Tickets support parent-child relationships. - **Conversations:** Threaded replies and private notes attached to tickets. Each conversation entry is a separate API resource at `/api/v2/tickets/{id}/conversations`. - **Problems:** Root-cause records linked to multiple incidents. Available at Pro tier and above. - **Changes:** Formal change requests with approval workflows, risk assessment, and rollout plans. Also Pro+. - **Assets / CMDB:** Freshservice includes built-in IT asset management with automated asset discovery, lifecycle tracking, inventory management, contract tracking, and integration with other ITSM modules. - **Service Catalog:** A request portal for employees to browse and submit service requests. - **Agents and Requesters:** Entirely separate API resources — `/api/v2/agents` and `/api/v2/requesters` — operations on one do not affect the other. A customer help desk has no concept of a CMDB or change management; an ITSM tool isn't built around omnichannel customer conversations and satisfaction scores. ### SurveySparrow Ticket Management's Data Model Case management capabilities convert feedback into trackable tickets. Workflows automatically create tickets based on survey responses meeting specific criteria, such as low NPS scores. The system includes internal notes for collaboration, status tracking through resolution, and SLA management for response times. Core entities: - **Tickets:** Flat ticket records with subject, description, status, priority, assigned agent, and custom fields. Tickets are typically auto-generated from survey responses, NPS detractors, or form submissions — not submitted through an employee service portal. - **Comments:** A flat comment thread on each ticket. Replies and internal notes are distinguished by a visibility flag, not a separate API resource type. - **Contacts:** A single contact object. No separate Companies entity. - **Custom Fields:** Supported, but must be created in SurveySparrow before migration. - **Surveys / NPS / Forms:** The platform's primary data-generation engine. Tickets are downstream of survey responses. SurveySparrow has **no CMDB**, **no asset management**, **no problem management**, **no change management**, **no release management**, and **no service catalog**. It is not an ITSM platform. ### Data Model Comparison | Concept | Freshservice | SurveySparrow Ticket Management | |---|---|---| | Primary ticket unit | Incident (ITIL-structured) | Ticket (flat, feedback-driven) | | Conversation threading | Replies + private notes (separate API resource) | Comments (flat thread, visibility flag) | | Parent-child tickets | Yes | No | | Problem management | Yes (Pro+) | No | | Change management | Yes (Pro+) | No | | Asset management / CMDB | Yes (Growth+) | No | | Service catalog | Yes | No | | Survey / NPS engine | No (separate Freshsurvey product) | Core platform feature | | Companies object | Yes | No | | Requester portal | Yes | No (tickets from surveys/forms) | | ITIL alignment | Full (incident, problem, change, release) | None | ### What the Gap Means for Migration **Freshservice → SurveySparrow is a flattening problem.** A Freshservice incident linked to a specific MacBook Pro (asset), part of a broader network outage (problem record), with an associated change request, must be reduced to a single SurveySparrow ticket. The asset, problem, and change relationships are lost unless you serialize that relational data into custom text fields. **SurveySparrow → Freshservice is an enrichment problem.** You're moving from a simpler model into a richer one. The main work is taxonomy design — mapping simple feedback tickets into Freshservice's ITIL categories, deciding what becomes an incident vs. a service request, and building classification structure that doesn't exist in the source data. Two edge cases to flag before you write a line of code. On the Freshservice side, service request item fields are not included in standard ticket exports because they live on the requested item object, not the ticket itself — they require a separate API call per ticket. On SurveySparrow's side, round-robin assignment only applies when tickets are created by survey workflows or the ticket API with a team assigned — not when tickets are created or reassigned manually. Miss either detail and your routing tests will pass at small scale and fail at cutover. ## Feature Comparison: What Each Platform Actually Does ### Where Freshservice Wins - **Full ITIL lifecycle:** Incident, problem, and change management with structured workflows for logging, categorizing, and resolving issues. Problems and changes unlock at Pro tier ($99/agent/month). - **CMDB and asset discovery:** Multi-source CMDB covering hardware, software, and SaaS using native discovery solutions and real-time connectors. Asset management unlocks at Growth tier ($49/agent/month). - **Enterprise service management (ESM):** Service management capabilities extend to HR, Facilities, Legal, and Finance departments with custom service catalogs and automated workflows. Requires Business Agent licenses at $49/agent/month beyond IT agents. - **AI agent (Freddy):** Built-in AI for ticket classification, automated categorization, response suggestions, and self-service deflection. Available as a $29/agent/month add-on on Starter through Pro; included at Enterprise. During migration, Freddy auto-tags and re-categorizes imported tickets on ingest — this can overwrite your carefully mapped categories. Disable Freddy AI processing before bulk-loading historical data. - **Mature API:** v2 with structured pagination, dedicated conversation endpoints, and documented rate limits per plan tier. - **Built-in CSAT and NPS:** Freshservice includes event-based and scheduled CSAT surveys, multiple question types, and distribution through email, Slack, and the requester portal. NPS templates are available on Pro and Enterprise. This directly overlaps with SurveySparrow's core use case and may close enough of the gap to avoid a platform migration for teams that primarily need post-resolution feedback. ### Where SurveySparrow Wins - **Feedback-to-action loop:** Tickets auto-generate from survey responses, NPS detractors, and form submissions. If your tickets are fundamentally "feedback items that need follow-up," this model is purpose-built for it in a way Freshservice is not. - **Survey and NPS engine:** Conversational surveys, 360-degree assessments, reputation management, and embedded feedback collection are native. Freshservice's built-in survey capability is limited by comparison. - **Lower cost floor for small teams:** The ticketing module is materially cheaper per-seat than Freshservice for teams that don't need ITSM features. Relevant for CX teams under 10 agents with sub-$5K/year budgets. - **Simpler onboarding:** No ITIL taxonomy to configure. For teams that don't need ITIL structure, the reduced complexity is a feature, not a limitation. ### Where Neither Platform Fits Neither platform is purpose-built for high-volume external customer support with live chat, social media, and phone channels. Freshdesk (not Freshservice) handles that in the Freshworks ecosystem. If your support operation is primarily email-driven, a shared inbox is a better fit (see our [Groove vs SurveySparrow architecture comparison](https://clonepartner.com/blog/blog/groove-vs-surveysparrow-architecture-tco-migration-guide/)). SurveySparrow's ticketing is secondary to its survey engine. Neither replaces a dedicated BI tool for complex cross-platform analytics. ## Total Cost of Ownership (TCO) Sticker pricing tells you what a seat costs. TCO tells you what the system costs. The gap between these numbers is where budgets break. ### Freshservice Pricing (2026) Annual per-agent pricing: $19/month (Starter), $49/month (Growth), $99/month (Pro), Enterprise on custom quote. Monthly billing runs approximately $29/$59/$119 for Starter/Growth/Pro. All seats are billed per agent (your IT staff); requesters who raise tickets are unlimited and free. Key cost multipliers beyond sticker price: - **Freddy AI Copilot:** $29/agent/month add-on on Starter through Pro. Included at Enterprise. - **Asset management overages:** Assets are metered above plan-included quantities. Get in writing before signing: how many assets are included at your tier, per-asset overage fees, and whether manually-added assets count against the limit. - **Day passes:** Occasional agents (infrequent approvers, managers) can be covered by day passes at $3–$18 depending on plan. - **Business Agent licenses:** ESM use cases outside IT (HR, Legal, Finance) require Business Agent licenses at $49/agent/month. - **Orchestration transactions:** Workflow automation with third-party tools consumes orchestration transactions, billed separately above the monthly allowance. - **API rate limit add-ons:** Paid options that increase API request capacity, available for Pro and Enterprise plans only. - **Real-world TCO example:** 15 agents on Pro at sticker is $99 × 15 × 12 = $17,820/year. Add Freddy AI Copilot ($29 × 15 × 12 = $5,220) and a modest asset overage, and the real run-rate reaches approximately $25,000/year — roughly 40% above sticker. ### SurveySparrow Pricing (2026) SurveySparrow's pricing is modular — survey plans and ticketing plans are separate products. The ticketing module (SparrowDesk) is available as an add-on or part of higher-tier bundles. Published plan prices for survey functionality range from $19–$39/month; higher tiers require sales contact. Based on Vendr's internal transaction data, actual annual contract values range from $200 to $9,500, with an average of approximately $4,100. Key cost considerations: - **Response limits:** Plans cap annual survey responses. Exceeding the cap requires upgrading or purchasing add-ons. - **User limits:** Lower tiers restrict the number of users (1 user on Basic/Starter, 3 on Business). - **API access:** API access is rate-limited on lower tiers, constraining developers who need to integrate surveys into existing workflows. SurveySparrow does not publish tier-specific API rate limits publicly — contact support for confirmed limits before planning integration architecture. - **Annual renewal uplift:** SurveySparrow's standard terms include a 7% annual uplift on subscription renewals. Address this explicitly in the order form. - **Hidden infrastructure costs:** Because SurveySparrow lacks native ITSM features, IT teams that adopt it often need secondary tools for asset tracking (Snipe-IT, Lansweeper) or incident alerting (PagerDuty), increasing total operational footprint beyond the SurveySparrow line item. ### TCO Comparison at a Glance | Scenario | Freshservice (annual) | SurveySparrow (annual) | |---|---|---| | 5 agents, basic ticketing only | ~$1,140 (Starter) | ~$588–$948 (Ticketing plan) | | 15 agents, ITSM with assets | ~$8,820–$17,820 (Growth/Pro) | Not applicable — no ITSM | | 15 agents, ITSM + Freddy AI | ~$25,000+ (Pro + Copilot) | Not applicable | | Feedback ticketing, 3 users | Overkill at any tier | ~$948–$4,100 | > [!WARNING] > **Don't compare sticker prices across categories.** Freshservice is an ITSM platform; SurveySparrow Ticket Management is a feedback-action module. If you need CMDB + change management + asset tracking, SurveySparrow cannot replace Freshservice at any price. If you need survey-driven ticket creation, Freshservice is expensive overhead at every tier. ## Data Residency and GDPR Considerations For EU-based teams or any organization subject to GDPR, data residency must be evaluated before migration — not after. **Freshservice** offers EU data center hosting (Frankfurt region) and signs a Data Processing Agreement (DPA) as part of its standard terms for GDPR-regulated customers. Data at rest is encrypted with AES-256; data in transit uses TLS 1.2+. Freshservice's subprocessor list is publicly available and updated when new subprocessors are added. **SurveySparrow** operates multiple data centers. Your account is assigned to a specific data center at signup, and the base URL for API calls varies by data center. Confirm your data center with SurveySparrow support before building any integration — using the wrong base URL returns authentication errors that look like credential problems but are actually routing failures. SurveySparrow offers GDPR-compliant data processing under its Data Protection Agreement for EU customers. **During migration transit**, PII moves through your ETL infrastructure. Use encrypted in-transit storage for staging files, do not log raw ticket payloads containing customer PII, and define a data retention policy for any intermediate storage (S3 buckets, local databases) used during the migration run. This applies regardless of migration direction. ## API Constraints That Shape Every Migration Every migration between these platforms is API-to-API. The constraints on both sides determine your migration timeline and architecture. ### Freshservice API (v2) — Extraction Side - **Authentication:** HTTP Basic Auth using API key as username and any string as password. - **Rate limits by plan tier:** 100 req/min (Starter), 200 req/min (Growth), 400 req/min (Pro), 500 req/min (Enterprise). Rate limits are enforced per account, not per API key — multiple integrations sharing one Freshservice account draw from the same bucket simultaneously. - **Migration partner rate limit:** Approved data migration partners can request an elevated limit of 700 req/min for the duration of the migration. To qualify, contact Freshservice support with your migration scope (ticket volume, timeline, account ID). There is no self-service application — approval is manual and typically takes 2–5 business days. - **Standard pagination:** Offset-based using `page` and `per_page` (max 100 per page). Standard list pagination tops out at 300 pages. If you have more than 30,000 tickets, a standard `GET` loop silently stops returning results at page 301. Window your extraction using `updated_since` to pull tickets in chronological chunks. - **Filter endpoint cap:** The filter/search endpoint (`/api/v2/tickets/filter`) has a separate hard ceiling: 30 tickets per page, capped at 10 pages — a hard limit of 300 results per filter query. Split filter queries by date ranges or other criteria to keep individual result sets under this cap. - **Conversations:** Separate endpoint per ticket: `GET /api/v2/tickets/{id}/conversations`. Using `include=conversations` on a ticket object returns only up to 10 conversations and consumes extra API credits. Full thread extraction requires the dedicated conversations endpoint. - **Bulk migration APIs:** For approved partners, Freshservice supports batches of up to 50 entities per request at 10 requests per minute, with attachments required as publicly accessible URLs and a 40 MB cap per entity. - **Service request item fields:** These live on the requested item object, not the ticket. A standard `GET /api/v2/tickets/{id}` does not return service request item fields. Retrieve them via `GET /api/v2/tickets/{id}/requested_items`. This is a separate API call per ticket — budget accordingly. - **Timestamps:** All timestamps returned in UTC, `YYYY-MM-DDTHH:MM:SSZ` format. - **Agent blocking risk:** When high volumes of data are transferred using a production agent's API key, that agent account can get rate-blocked, disrupting live operations. Always use a dedicated migration agent account with its own API key. - **Export ceiling:** Standard Freshservice ticket exports cap at 10,000 records and do not include complete conversation history. Use the API — not CSV exports — as your primary extraction method for any dataset above this threshold. ### How to Disable Freshservice Automations via API Before Bulk Loading To prevent notification storms when loading data into Freshservice, disable automation rules programmatically: ```bash # List all automation rules GET /api/v2/scenario_automations # Disable a specific automation rule PUT /api/v2/scenario_automations/{id} Content-Type: application/json { "active": false } ``` Email notifications for ticket creation events are controlled under **Admin → Email Notifications**. There is no bulk-disable API endpoint for email notifications — these must be disabled through the Admin UI before bulk loading. Re-enable both automation rules and email notifications only after post-migration validation is complete. ### SurveySparrow API (v3) — Load Side - **Authentication:** OAuth 2.0. Use your account's data-center-specific base URL. - **Rate limits:** SurveySparrow does not publish tier-specific API rate limits. Confirm limits with SurveySparrow support before finalizing your migration timeline. Do not treat any community-reported values as authoritative — they may reflect a different plan tier or an older API version. - **Batch endpoints:** `POST /v3/tickets/batch` for tickets and `POST /v3/contacts/batch` for contacts. In testing, batch endpoints accepted up to 50 records per request reliably; larger batches returned intermittent 413 errors. Start with batches of 25 and increase incrementally while monitoring for errors. - **Comments:** No batch endpoint exists for comments. Comment replay is typically the longest pole of the migration — every comment requires a separate API call. - **Attachment limits:** Only accepts pdf, png, jpeg, mp3, csv, and wav attachments up to 15 MB. Files outside these types are silently dropped — no error response is returned. You will not know data is missing unless you audit. - **Historical timestamps:** SurveySparrow's comment creation endpoint does not expose an input for historical timestamps. Embed the original author and creation time inside the comment body when importing historical threads to preserve the audit trail. - **Custom fields:** Must be created in SurveySparrow before migration. The API does not auto-create fields on ingest. ### How to Audit for Silent Attachment Drops Because SurveySparrow discards unsupported attachment types without returning an error, you must run a pre-migration inventory and a post-migration count comparison: ```python import requests def get_freshservice_attachment_inventory(domain, api_key, ticket_ids): """ Returns a dict of {ticket_id: [{filename, size, content_type}]} """ inventory = {} supported_types = {'application/pdf', 'image/png', 'image/jpeg', 'audio/mpeg', 'text/csv', 'audio/wav'} unsupported = [] for ticket_id in ticket_ids: convs = requests.get( f"https://{domain}.freshservice.com/api/v2/tickets/{ticket_id}/conversations", auth=(api_key, "X") ).json().get("conversations", []) for conv in convs: for att in conv.get("attachments", []): if att["content_type"] not in supported_types: unsupported.append({ "ticket_id": ticket_id, "filename": att["name"], "size_bytes": att["size"], "content_type": att["content_type"] }) return unsupported # Run before migration. For every unsupported file: # 1. Upload to S3/GCS and generate a signed URL. # 2. Inject the URL as a comment body in SurveySparrow. ``` Run this inventory before migration begins. For every unsupported file, upload it to external storage (AWS S3, GCS) and inject the resulting URL into the SurveySparrow ticket comment body. This converts an invisible data loss into a traceable reference. > [!CAUTION] > **Attachment format mismatch is a silent data-loss vector.** Freshservice supports a wider range of attachment types (docx, xlsx, zip, log files) and up to 40 MB per entity. Any type not in SurveySparrow's accepted list (pdf, png, jpeg, mp3, csv, wav) is silently dropped. Audit your Freshservice attachments before migration using the inventory script above. ## SurveySparrow SLA Configuration for Migration Planning The blog's migration steps reference rebuilding SLA policies in SurveySparrow, but understanding how SurveySparrow enforces SLAs affects how you configure the destination environment before loading data. SurveySparrow SLA policies are configured under **Settings → SLA Policies** and operate on three dimensions: 1. **Response time targets:** Time from ticket creation to first agent response. Configurable per priority level (low, medium, high, urgent). 2. **Resolution time targets:** Time from ticket creation to ticket closure. 3. **Escalation rules:** Automated actions triggered when response or resolution targets are breached — typically reassignment or notification to a manager. SLAs in SurveySparrow apply based on ticket priority. When migrating historical tickets from Freshservice, set the ticket `created_at` timestamp via the API at import time to ensure SLA calculations reflect the original creation date, not the migration date. If the API does not accept a historical `created_at` value, close historical tickets immediately on import and note the original creation time in a custom field — SLA timers are typically inactive on closed tickets. Freshservice SLA policies are more granular: they can be scoped by department, category, sub-category, and requester group, with separate policies for incidents vs. service requests. This granularity does not exist in SurveySparrow. Flatten multi-policy Freshservice SLA structures into SurveySparrow's priority-based model before migration, and document which Freshservice SLA tiers map to which SurveySparrow priority levels. ## Migration: Freshservice → SurveySparrow Ticket Management This direction means moving from a structured ITSM platform to a feedback ticketing module. You will lose data fidelity. Plan for it explicitly. ### What You Can Migrate - **Tickets → Tickets:** Subject, description, status (with mapping), priority, requester, assigned agent, custom fields. - **Conversations → Comments:** Public replies map to public comments; private notes map to internal comments (visibility flag). - **Requesters → Contacts:** Name, email, phone. - **Attachments:** Only pdf, png, jpeg, mp3, csv, wav under 15 MB. ### What You Will Lose - Problem records, change records, release records — no equivalent in SurveySparrow. - Asset data / CMDB — no equivalent. - Service catalog items and requested item fields — no equivalent. - Parent-child ticket relationships — SurveySparrow tickets are flat. - SLA policies — must be rebuilt manually in SurveySparrow (see SLA section above). - Automation rules — must be rebuilt using SurveySparrow workflows. - Ticket categories/sub-categories — must be flattened into custom fields or tags. - Attachments in unsupported formats (docx, xlsx, zip, log, etc.) — silently dropped. ### Field Mapping Matrix | Freshservice Object | SurveySparrow Object | Transformation | |---|---|---| | `Ticket (Incident)` | `Ticket` | Map directly. Translate statuses (e.g., "Pending" → "Open"). | | `Service Request` | `Ticket` | Flatten requested items into the description body via `/requested_items` endpoint. | | `Requester` | `Contact` | Match by email address. | | `Public Reply` | `Public Comment` (visibility: public) | Map author; embed original timestamp in comment body. | | `Private Note` | `Internal Comment` (visibility: private) | Map author; embed original timestamp in comment body. | | `Asset / CI` | `Custom Field` | Serialize asset name, tag, and serial into a custom text field. | | `Inline Images` | `Attachments` | Parse HTML bodies, extract ``, download, re-upload if format is supported. | | `Problem Record` | Not migratable | Serialize to custom text field or external document. | | `Change Record` | Not migratable | Serialize to custom text field or external document. | | `SLA Policy` | SLA Policy (rebuilt) | Map priority levels; reconfigure in SurveySparrow Settings. | ### Step-by-Step Execution #### Step 1: Audit Source Data Inventory ticket counts, conversation volumes, attachment types and sizes, custom fields, and ITSM-specific records (problems, changes, assets) that have no migration target. Run the attachment inventory script above. Count unsupported attachment types before you start loading — not after. #### Step 2: Pre-Create Target Schema Create every required custom field in SurveySparrow before import. Map Freshservice categories and sub-categories to SurveySparrow custom fields or tags. Configure SLA policies in SurveySparrow. Set up agent accounts and teams. #### Step 3: Extract and Map Users Before migrating tickets, migrate the people. Extract all Requesters from Freshservice and create them as Contacts in SurveySparrow. Store the mapping of `Freshservice_Requester_ID` → `SurveySparrow_Contact_ID` in a local key-value store (Redis, SQLite, or a JSON file). You need this mapping to assign ticket ownership correctly during load. #### Step 4: Extract Tickets in Chronological Windows Bypass the Freshservice 300-page list limit by windowing your extraction using `updated_since`. For each window, paginate through up to 300 pages of results at 100 per page: ```python import requests from datetime import datetime, timedelta import time def extract_tickets_windowed(domain, api_key, start_date, end_date=None): """ Extract tickets using date-windowed pagination to bypass the 300-page list limit. Implements exponential backoff on 429 rate limit responses. """ if end_date is None: end_date = datetime.utcnow() window_start = start_date all_tickets = [] while window_start < end_date: window_end = window_start + timedelta(days=30) page = 1 while True: url = ( f"https://{domain}.freshservice.com/api/v2/tickets" f"?updated_since={window_start.strftime('%Y-%m-%dT%H:%M:%SZ')}" f"&per_page=100&page={page}" ) retries = 0 while retries < 5: response = requests.get(url, auth=(api_key, "X")) if response.status_code == 429: # Exponential backoff: 2, 4, 8, 16, 32 seconds wait = 2 ** retries print(f"Rate limited. Waiting {wait}s before retry.") time.sleep(wait) retries += 1 elif response.status_code == 200: break else: response.raise_for_status() tickets = response.json().get("tickets", []) if not tickets: break all_tickets.extend(tickets) page += 1 if page > 300: # Window exhausted — should not happen with 30-day windows # unless volume exceeds 30,000 tickets/30 days print(f"Warning: hit 300-page limit for window {window_start}. Narrow the window.") break window_start = window_end return all_tickets ``` Budget at least 2 API calls per ticket — one for the ticket, one for its conversations. For tickets with service requests, add a third call for `/requested_items`. #### Step 5: Thread the Conversations For every ticket, call `GET /api/v2/tickets/{id}/conversations` to get the full thread history. Do not use `include=conversations` — it caps at 10 entries and consumes extra API credits. Transform conversations into SurveySparrow comments and `POST` them sequentially. Since SurveySparrow's comment API does not accept historical timestamps, embed the original author and creation time in the comment body to preserve the audit trail. #### Step 6: Disable Automations Before Loading Disable all SurveySparrow workflows, webhooks, and email notifications before running the load script. If you bulk-import 50,000 historical tickets without doing this, you risk triggering 50,000 "Ticket Created" emails to your contacts. Also disable Freddy AI in Freshservice (if migrating to Freshservice) to prevent auto-categorization from overwriting your mapped taxonomy. To disable SurveySparrow automations: navigate to **Settings → Workflows** and deactivate each active workflow individually. There is no bulk-disable API endpoint — this must be done through the UI. #### Step 7: Load Data with Idempotency Use `POST /v3/tickets/batch` in batches of 25–50. Replay comments sequentially per ticket (no batch endpoint exists). Upload attachments individually per comment. Your loading script must check whether a Freshservice ticket ID already exists in SurveySparrow before issuing a `POST`. Network timeouts will happen. If your script crashes and restarts without idempotency checks, you will create thousands of duplicate tickets. ```python def load_ticket_idempotent(ss_client, ticket_data, id_map_store): """ id_map_store: a dict or persistent store mapping freshservice_ticket_id -> surveysparrow_ticket_id """ fs_id = ticket_data["freshservice_id"] if fs_id in id_map_store: # Already created — skip to avoid duplicate return id_map_store[fs_id] response = ss_client.post("/v3/tickets", json=ticket_data) response.raise_for_status() ss_id = response.json()["ticket"]["id"] id_map_store[fs_id] = ss_id # Persist mapping return ss_id ``` Persist the ID mapping to disk or a database — not just in-memory. A process crash loses in-memory state. #### Step 8: Delta Sync and Cutover A migration of tens of thousands of tickets takes days to run. Your team is still working in Freshservice during that time. Once the historical payload is loaded, run a delta sync: query Freshservice for any tickets modified since the initial extraction timestamp. Transform and load only these updated records. Repeat, narrowing the window, until the delta takes less than five minutes to process. At that point, switch inbound email routing and webhooks to SurveySparrow and cut over. #### Step 9: Validate Reconcile ticket counts between source and destination. Spot-check conversation threads for completeness. Verify custom field mapping against your pre-migration schema document. Run the post-migration attachment count comparison: ```python def validate_attachment_counts(fs_tickets, ss_client): """ Compare attachment counts source-to-destination. Flag any ticket where counts don't match after accounting for unsupported formats. """ supported_types = {'application/pdf', 'image/png', 'image/jpeg', 'audio/mpeg', 'text/csv', 'audio/wav'} discrepancies = [] for ticket in fs_tickets: fs_att_count = sum( 1 for conv in ticket["conversations"] for att in conv.get("attachments", []) if att["content_type"] in supported_types ) ss_ticket = ss_client.get(f"/v3/tickets/{ticket['ss_id']}").json() ss_att_count = len(ss_ticket.get("attachments", [])) if fs_att_count != ss_att_count: discrepancies.append({ "freshservice_id": ticket["id"], "ss_id": ticket["ss_id"], "expected": fs_att_count, "found": ss_att_count }) return discrepancies ``` Rebuild SLA policies and workflow rules in SurveySparrow only after validation is complete. Re-enable automations after re-enabling SLAs. ## Migration: SurveySparrow → Freshservice This direction is architecturally simpler — you're moving from a simpler data model into a richer one. The main challenge is enrichment, not flattening. ### What Maps Cleanly - **Tickets → Incidents:** Subject, description, status, priority, requester email. - **Comments → Conversations:** Comment bodies map to reply or note entries via `/api/v2/tickets/{id}/notes`. - **Contacts → Requesters:** Name, email, phone. ### What Requires Manual Enrichment - **Category/sub-category mapping:** Freshservice expects structured ITIL categorization. Define a taxonomy before migration and map SurveySparrow ticket data into it. Consider using a custom Service Catalog item (e.g., "Survey Response" or "NPS Follow-Up") to preserve the feedback origin. - **SLA policies:** Configure in Freshservice before migration. Map SurveySparrow priority levels to Freshservice SLA policy scopes. - **Agent groups:** Define groups in Freshservice and map SurveySparrow agent assignments. - **Asset associations:** Freshservice tickets can link to CMDB items. This data doesn't exist in SurveySparrow — associate assets post-migration if required. ### Technical Notes Extract from SurveySparrow using `GET /v3/tickets` with pagination. For each ticket, retrieve comments via the comment endpoint. SurveySparrow's API documentation is sparser than Freshservice's — expect to reverse-engineer some payload structures during development. Load into Freshservice using `POST /api/v2/tickets` for ticket creation and `POST /api/v2/tickets/{id}/notes` for conversation replay. Respect rate limits per your plan tier. For large migrations, apply for Freshservice's migration partner rate limit increase to 700 req/min (contact Freshservice support with migration scope; allow 2–5 business days for approval). Disable email notifications and automation rules in Freshservice before loading — use the API endpoint documented above (`PUT /api/v2/scenario_automations/{id}` with `"active": false`) for automation rules, and the Admin UI for email notification settings. ## Timeline and Effort Estimates | Migration Scenario | Ticket Volume | Estimated Timeline | Notes | |---|---|---|---| | Freshservice → SurveySparrow (simple) | < 5,000 | 1–2 weeks | Minimal custom fields, no ITSM-specific data | | Freshservice → SurveySparrow (complex) | 5,000–50,000 | 3–6 weeks | Heavy custom fields, conversation history, attachment conversion | | SurveySparrow → Freshservice (simple) | < 5,000 | 1–2 weeks | Straightforward mapping | | SurveySparrow → Freshservice (complex) | 5,000–50,000 | 2–4 weeks | Category enrichment, SLA setup, group mapping | The longest pole in any migration involving SurveySparrow is **comment replay** — no batch endpoint means every comment is a separate API call. At SurveySparrow's unconfirmed rate limits, a dataset of 200,000 comments (50,000 tickets × 4 comments average) can take 48–72 hours of continuous API calls at conservative request rates. For datasets above 50,000 tickets in either direction, self-service migration is impractical without elevated API limits or parallelized extraction using multiple migration agent accounts. ## Edge Cases That Will Bite You 1. **SurveySparrow data center mismatch:** Confirm your data center with SurveySparrow support before building any integration. Using the wrong base URL returns authentication errors that look like credential problems but are routing failures. 2. **Freshservice agent blocking:** When high volumes of data are transferred using a production agent's API key, that agent account gets blocked. Always use a dedicated migration agent account with its own API key isolated from production operations. 3. **Freshservice filter endpoint pagination cap:** The filter API (`/api/v2/tickets/filter`) returns a maximum of 300 results (30 per page × 10 pages). This is separate from the standard list endpoint's 300-page limit. Split filter queries by date ranges to keep individual result sets under the cap. 4. **Silent attachment drops on SurveySparrow load:** SurveySparrow discards unsupported file types (docx, xlsx, zip, log, etc.) without returning an error. Run the pre-migration attachment inventory script and post-migration count validation described above. 5. **Timestamp drift:** Freshservice returns UTC. Ensure your transformation layer preserves UTC without introducing timezone offsets when loading into SurveySparrow. 6. **Notification storms on bulk load:** Both platforms trigger automations on ticket creation. Disable rules on the destination system before bulk loading. Document which rules you disable so you can re-enable the correct set after validation. 7. **`include=conversations` limit:** Using the include parameter on a Freshservice ticket returns only up to 10 conversations and costs extra API credits. Always use the dedicated `GET /api/v2/tickets/{id}/conversations` endpoint for full thread extraction. 8. **Freshservice export ceiling:** Standard ticket exports cap at 10,000 records and exclude conversation history. Use the API — not exports — for all migrations above this threshold. 9. **Service request item fields omitted from ticket responses:** These require a separate `GET /api/v2/tickets/{id}/requested_items` call per ticket. Missing this step silently omits the structured request data from your migration. 10. **Freddy AI auto-categorization on Freshservice ingest:** If Freddy AI is active during bulk ticket import, it will attempt to auto-categorize and tag imported tickets, potentially overwriting your carefully mapped taxonomy. Verify Freddy AI processing status before loading. ## Decision Framework Answer three diagnostic questions before comparing features or pricing: 1. **Who submits tickets?** Internal employees → Freshservice. Survey respondents, NPS detractors, review authors → SurveySparrow Ticket Management. 2. **Do you need ITIL?** Problem management, change management, or release management are requirements → Freshservice only. No ITIL equivalent exists in SurveySparrow at any tier. 3. **Is the survey engine primary or secondary?** If ticketing is downstream of feedback collection → SurveySparrow. If ticketing is the core operational system → Freshservice. If you run both internal IT operations and customer feedback programs, these platforms are not mutually exclusive. Many organizations run Freshservice for IT service management and SurveySparrow for CX feedback — that is the architecturally correct configuration for this dual requirement. **Size guidance:** Freshservice's pricing is best suited for mid-market IT teams of 51 to 1,000 employees with structured ITSM needs. SurveySparrow is strongest for CX teams under 10 agents that don't need ITIL structure and want a combined survey + light ticketing solution under $5K/year. **Before migrating, evaluate Freshservice's built-in survey capability.** Freshservice's native CSAT and NPS tools support event-based and scheduled surveys, multiple question types, and distribution through email, Slack, and the requester portal. NPS templates are available on Pro and Enterprise. For teams whose primary requirement is post-resolution feedback — not the full SurveySparrow conversational survey engine — this may eliminate the need for a platform migration entirely. For more context on Freshservice alternatives, see our [Top Freshservice Alternatives 2026](https://clonepartner.com/blog/blog/top-freshservice-alternatives-2026-features-tco-migration/) guide. For the ITIL architecture comparison, [ServiceNow vs Freshservice: The CTO's 2026 Architecture Guide](https://clonepartner.com/blog/blog/servicenow-vs-freshservice-the-ctos-2026-architecture-guide/) covers competing ITSM data models. For the full SurveySparrow migration pipeline from another mainstream desk, see our [Freshdesk to SurveySparrow Ticket Migration: Technical Guide](https://clonepartner.com/blog/blog/freshdesk-to-surveysparrow-ticket-migration-technical-guide/) or our [HubSpot Service Hub to SurveySparrow Migration Guide](https://clonepartner.com/blog/blog/hubspot-service-hub-to-surveysparrow-ticket-migration-guide/). If you are moving away from SurveySparrow to a shared inbox, see our [SurveySparrow to Front Migration Guide](https://clonepartner.com/blog/blog/surveysparrow-ticket-management-to-front-migration-guide/). ## When to Self-Serve vs. When to Use Tooling Self-service migration is viable when: ticket volume is under 5,000, custom field count is under 20, conversation threads average under 5 comments per ticket, and all attachments are in SurveySparrow-supported formats (pdf, png, jpeg, mp3, csv, wav) under 15 MB. Tooling or external support becomes necessary when: ticket volume exceeds 5,000, conversation history must be preserved with original authorship and timestamps, attachments include unsupported formats requiring external storage routing, ITSM objects (problems, changes, assets) must be serialized rather than dropped, or delta sync must be maintained across a cutover window longer than 24 hours. The technical constraints that set migration timelines are fixed regardless of approach: comment replay on SurveySparrow has no batch endpoint, Freshservice rate limits are enforced per account, and attachment auditing requires per-conversation API calls that cannot be parallelized without multiple agent accounts. Any migration plan that doesn't account for these constraints will underestimate timeline. > Need to migrate between SurveySparrow and Freshservice? Book a free 30-minute call with our engineers. We'll review your data, map the field translations, and give you an honest timeline. > > [Talk to us](https://cal.com/clonepartner/meet?duration=30) ## Frequently asked questions ### Can SurveySparrow Ticket Management replace Freshservice for IT service management? No. SurveySparrow has no CMDB, no asset management, no problem/change/release management, and no service catalog. It is a feedback-driven ticketing module, not an ITSM platform. If you need ITIL processes, Freshservice (or a similar ITSM tool) is required. ### Is there a native migration tool between Freshservice and SurveySparrow? No. There is no vendor-endorsed connector, pre-built migration tool, or CSV import that handles the full scope. Every migration requires custom extraction via Freshservice's API v2, transformation, and loading through SurveySparrow's API v3 (or vice versa). ### What data is lost when migrating from Freshservice to SurveySparrow? Problem records, change records, asset/CMDB data, service catalog items, parent-child ticket relationships, SLA policies, and automation rules have no equivalent in SurveySparrow. Attachments outside pdf/png/jpeg/mp3/csv/wav formats or over 15 MB are silently dropped. ### How do I bypass the Freshservice API 300-page pagination limit? Use the updated_since query parameter to window your extraction into chronological chunks (e.g., 30-day intervals). Each window resets the pagination counter, letting you extract datasets larger than 30,000 tickets. ### How long does a Freshservice to SurveySparrow migration take? For under 5,000 tickets with minimal custom fields: 1–2 weeks. For 5,000–50,000 tickets with conversation history and attachments: 3–6 weeks. The biggest bottleneck is comment replay — SurveySparrow has no batch endpoint for comments.