Freshservice vs SysAid: Architecture, TCO & Migration Guide

Freshservice vs SysAid: Architecture, TCO & Migration Guide

Freshservice and SysAid both cover ITSM fundamentals — incident, problem, change, and asset management — but they target different buyers and impose different technical constraints. Freshservice is a cloud-only, multi-tenant ITSM platform built for mid-market teams that want fast deployment and ITIL alignment at a transparent price point. SysAid is a cloud-and-on-premises ITSM platform designed for organizations that need deployment flexibility, deeper built-in asset management, or data residency control.

Your choice hinges on five variables: deployment model requirements, total cost of ownership, AI strategy, asset management depth from day one, and migration complexity. This guide breaks down the architecture, verified pricing, feature trade-offs, and migration mechanics — including the data-model mismatch that makes migrating between these two platforms more complex than it first appears.

---

How do Freshservice and SysAid differ in architecture?

Freshservice runs on a multi-tenant cloud architecture hosted on AWS. The data model is largely fixed — you can add custom fields and define custom CI types, but you cannot alter the underlying database schema or core workflow engines. Admins configure workspaces, roles, forms, and workflows rather than building platform schemas from scratch. That constraint is a strength when speed matters and a real limitation when you need non-standard entity relationships.

SysAid offers cloud and on-premises deployment. The on-premises edition installs on local servers with full application control and supports Microsoft SQL Server, MySQL, and a bundled database. Cloud deployments run on AWS data centers across Virginia, Ireland, and Sydney. The on-prem version runs as a Java-powered web server bundled with Apache Tomcat.

On-premises system requirements for SysAid (current as of 2025–2026):

Resource	Minimum	Recommended
CPU	4 cores	8+ cores
RAM	8 GB	16 GB
Database	MySQL 5.7+, MS SQL 2016+, built-in	MS SQL 2019+ for large deployments
Java	JDK 11+	JDK 17
OS	Windows Server 2016+, RHEL/CentOS 7+	Windows Server 2022

The Service Record entity problem

The most consequential architectural difference is one most comparison articles miss: SysAid stores Incidents, Requests, Changes, and Problems in a single Service Record entity, differentiated by a type field. Freshservice uses separate, ITIL-aligned tables for each record type with independent field schemas.

This matters enormously during migration. Moving from SysAid to Freshservice means splitting one unified table into four distinct target tables. Moving from Freshservice to SysAid means collapsing four tables with divergent schemas into one unified structure. Call this the entity collapse/split problem — it is the primary source of migration complexity between these two platforms.

The mapping challenge is not just structural. Each record type in Freshservice may have custom fields that don't exist in SysAid's unified schema, and vice versa. Category trees, priority mappings, and resolution codes must be re-evaluated for every field across every record type before you write a single line of transformation logic.

Update cadence and on-prem feature gaps

SysAid Cloud users receive automatic updates approximately every two weeks. On-premises users receive one to two major releases per quarter, with patch releases in between. The gap is not just cadence — it's capability. SysAid Cloud includes the AI Service Desk, Business Value Dashboard, and the full SysAid Copilot feature set. On-prem deployments currently lack the AI Service Desk entirely, and Copilot functionality on-prem is limited to basic ticket summarization and classification; generative response drafting and knowledge synthesis require the cloud edition.

If you are evaluating SysAid On-Premises, understand that you are accepting a feature-reduced version of the product, manual update responsibility, and your own patching SLA for security vulnerabilities.

Freshservice ships updates continuously with no on-prem option. Freshworks was named a Leader in the 2026 Gartner Magic Quadrant for IT Service Management Platforms. Freshworks also acquired FireHydrant in December 2025, deepening its AI-driven incident management capabilities.

---

What does each platform actually cost?

Freshservice publishes pricing; SysAid does not. That asymmetry tells you something about how negotiations will go.

Freshservice pricing (per agent, per month, billed annually)

Plan	Annual	Monthly	Key capabilities
Starter	$19	$29	Incident management, knowledge base, SLA management, 1,000 orchestrations/month
Growth	$49	$59	Asset management, service catalog, approval workflows
Pro	$95–99	$115–119	Problem, change, release management, project management, advanced analytics
Enterprise	$119	$145	Sandbox, audit logs, 20,000 orchestrations/month

Freddy AI Copilot costs $29/agent/month on annual billing ($35 monthly) and is available only on Pro and Enterprise plans. It covers response drafting, ticket summarization, resolution suggestions, and knowledge article generation.

Asset management hidden costs: Freshservice's asset management pricing includes a baseline asset count per agent — typically 100–200 managed assets per agent depending on plan and negotiation. Overages are billed per asset above that threshold. If you manage 5,000 endpoints with 30 agents, confirm in writing the exact asset ceiling, the per-asset overage rate, and whether manually-added assets (versus auto-discovered) count against the limit. This is the most common source of bill shock on Freshservice.

Minimum seat commitments: Freshservice typically requires a minimum of two agents on paid plans, with annual contract terms. Enterprise agreements often carry minimum one-year commitments with limited mid-term exit provisions.

SysAid pricing (estimated, per user, per month)

SysAid does not publish pricing publicly. Based on G2 reviewer disclosures, Capterra data points, and procurement reports compiled through 2025–2026, the approximate ranges are:

Plan	Estimated monthly per user	Notes
Help Desk	$75–85	Ticketing, asset management, basic reporting
ITSM	$100–115	Full ITIL module suite, Copilot included
Enterprise	Custom quote	Dedicated CSM, advanced integrations, SLA guarantees

These figures should be treated as a negotiation baseline, not a published rate. Actual quotes vary by seat count, contract length, and region. Get a written quote before using any figure for budget planning.

SysAid Copilot pricing: Copilot is included in the ITSM plan. For Help Desk customers, it is available as an add-on priced at approximately $18–32 per admin per month depending on features enabled (2026 list pricing). Customers who signed Copilot contracts in 2024–2025 at early-adopter pricing — typically 40–60% below list — have reported renewal quotes at 2026 list price, representing uplifts exceeding 100% in some cases. If you are mid-contract on an early-adopter Copilot deal, negotiate an explicit price-lock clause at renewal before the contract is up for discussion.

TCO comparison: 50 agents, full AI capability

The following projections assume annual billing, no asset overages, and standard onboarding. They are illustrative arithmetic, not vendor quotes.

Cost component	Freshservice (Pro + Freddy AI)	SysAid (ITSM, Copilot included)
Base platform (50 agents × 12 months)	$59,400 ($99/agent/mo)	$66,000 ($110/agent/mo est.)
AI copilot	$17,400 ($29/agent/mo)	$0 (included)
Implementation / onboarding	$5,000–15,000	$15,000–40,000
Year 1 total (estimated)	$81,800–91,800	$81,000–106,000
Annual maintenance (Year 2+)	$76,800 (license only)	$79,200 (license only)

At comparable feature tiers with AI included, first-year costs are roughly similar. The divergence appears in onboarding (SysAid's implementation is more complex, particularly on-prem) and in Year 2+ when Freshservice's modular add-ons — ITOM, additional orchestration tiers, project management seats — accumulate. Enterprise SysAid deployments should budget $85,000–240,000 in first-year integration costs for complex environments, plus $30,000–85,000 annually in maintenance.

Contract terms to negotiate for either platform:

• Annual price increase caps (CPI or fixed percentage)
• Asset count thresholds in writing, including what counts as a "managed asset"
• Minimum seat commitments and mid-term scaling provisions
• AI add-on pricing lock for multi-year deals
• Exit clause conditions and data export assistance obligations

---

Freshservice vs SysAid: feature-by-feature breakdown

Capability	Freshservice	SysAid
Deployment	Cloud only (AWS)	Cloud + on-premises
ITIL alignment	Full (incident, problem, change, release as separate entities)	Full (unified Service Record model, type-differentiated)
Asset management	Growth plan and above ($49+/agent/mo); 100–200 asset baseline per agent	Included in Help Desk tier; no separate tier gating
CMDB	Included; auto-discovery via network probes; simpler CI relationship modeling	Included; agent and agentless discovery; RDS required for cloud discovery; more CI relationship types
AI copilot	Freddy AI — $29/agent/mo add-on, Pro/Enterprise only	SysAid Copilot — included at ITSM tier; generative features cloud-only
ESM (non-IT use)	Native Workspaces for HR, facilities, legal, finance	Supported but less structured; no dedicated workspace model
Native integrations	Broader marketplace; Freshworks ecosystem (Freshdesk, Freshchat, Freshsales)	Fewer pre-built connectors; strong Microsoft 365 and Jira integrations
Reporting	Built-in analytics; PDF/CSV exports capped at 200 records per query	BI Analytics module (Qlik-powered); deeper data access but noted as complex to configure
Security certifications	SOC 2 Type 2, ISO 27001, GDPR	ISO 27001, 27017, 27018, SOC 2 Type 2, GDPR
Deployment timeline	Days to two weeks (self-service cloud)	Cloud: 2–6 weeks; On-premises: 4–12 weeks
G2 rating	4.6/5 (1,307 reviews as of mid-2025)	4.5/5 (741 reviews as of mid-2025)
Gartner Peer Insights	4.4/5 (873 reviews)	4.5/5 (683 reviews)

CMDB depth: Freshservice's CMDB supports standard CI types, dependency mapping, and impact analysis with an interface designed for ease of use. SysAid's CMDB supports more CI relationship types and federation with external data sources but requires more configuration investment. Neither platform approaches ServiceNow-level CMDB complexity — if you need multi-level CI federation, attribute inheritance, or reconciliation engines, both platforms will hit limits.

User sentiment patterns across G2 and Gartner Peer Insights are consistent: SysAid users praise ticketing flow and integrated asset tracking. Freshservice users highlight the same strengths plus faster workflow automation setup and lower onboarding friction. Common criticisms: SysAid users flag workflow customization complexity and integration friction. Freshservice users cite limited reporting flexibility and specific integration gaps (Jamf Cloud being the most-cited example).

---

When should you choose Freshservice over SysAid?

Choose Freshservice when:

• Time-to-value is the primary constraint. Freshservice deploys in days to two weeks with self-service configuration. SysAid cloud takes 2–6 weeks; on-prem takes 4–12 weeks.
• ESM expansion across multiple departments is in scope. Freshservice's Workspace model natively supports HR, Facilities, Legal, and Finance service desks with separate queues, forms, and SLAs — no custom development required.
• You want the Freshworks platform ecosystem. Freshdesk, Freshchat, and Freshsales integrate with Freshservice natively, which matters if you're consolidating customer and employee service tooling.
• Budget predictability matters more than flexibility. Published pricing means you enter negotiation with a baseline. SysAid's opaque pricing puts more leverage on the vendor side.
• Your team is new to ITSM. The onboarding path, documentation quality, and UI complexity favor Freshservice for teams standing up ITSM for the first time.

When should you choose SysAid over Freshservice?

Choose SysAid when:

• On-premises deployment is a hard requirement. Freshservice has no on-prem option. If your regulatory environment (HIPAA, FedRAMP alignment, data sovereignty mandates) requires local hosting, SysAid is one of the few mid-market ITSM platforms still offering it.
• Asset management must be included from day one without tier gating. SysAid includes ITAM in its base Help Desk tier. Freshservice gates it behind the Growth plan at $49/agent/month minimum.
• AI cost bundling reduces your total outlay. At the SysAid ITSM tier, Copilot is included. Adding Freddy AI Copilot to Freshservice costs $29/agent/month — $17,400/year for 50 agents — on top of the base plan.
• You need a self-contained ticketing engine with deep category hierarchies. SysAid's unified Service Record model with custom fields baked in gives administrators more schema flexibility within its own structure, even though that same structure complicates external migration.
• Direct database access for integrations is a technical requirement. SysAid On-Premises gives your team MySQL or MS SQL access to the underlying schema, enabling direct ETL pipelines without API rate limits.

---

How do the APIs compare for data migration?

API constraints define how fast — and how painfully — a migration will go. Both platforms impose rate limits that require explicit planning for large datasets.

Freshservice API

• Rate limit: plan-dependent, typically 200–400 requests/minute on standard tiers
• Migration partners can request elevated limits of 700 requests/minute through a formal request process (not available to standard customers)
• Freshservice offers dedicated Bulk Migration APIs for partner-level access; public APIs do not support all migration scenarios
• Attachment size limit: any single attachment exceeding 40 MB is rejected entirely, but the parent entity (ticket, comment) is still created successfully — creating orphaned records with missing files
• Attachments above the count limit per record fail as partial failures — the ticket creates but the attachment does not
• Advanced custom filter logic is not supported via API; use Freshservice's reporting export to pre-filter datasets before migration

SysAid API

• Rate limit: 2 login requests and 1,000 other requests per 5-minute window — approximately 200 requests/minute sustained
• Maximum page size: 500 records per request
• Extraction math for large datasets: 500,000 Service Records ÷ 500 per request = 1,000 API calls minimum. At 1,000 requests/5 minutes, theoretical extraction time is 5 minutes of pure network time. In practice, payload processing and network latency reduce effective throughput to roughly 30,000–50,000 records per hour
• Attachments require individual per-record API calls. For a dataset with 50,000 attachments, that is 50,000 additional API requests — approximately 4+ hours of extraction time at the rate ceiling, before any transformation or loading
• The rate limit applies per session, not per IP — parallel sessions do not increase effective throughput

Pre-migration checklist for both platforms: Disable workflow automations, notification rules, email triggers, and scenario automations before running any bulk import. Failing to do so triggers cascading notifications to agents and end users as historical records are created, generating hundreds or thousands of automated emails during migration.

---

The entity collapse/split problem: a mapping framework

This is the core technical challenge when migrating between Freshservice and SysAid. Neither direction is trivial.

Direction 1: SysAid → Freshservice (entity split)

SysAid's single ServiceRecord table must be split into four destination tables in Freshservice:

SysAid ServiceRecord type	Freshservice destination	Schema notes
request (type 1)	Tickets (service requests)	Map category tree, priority, SLA
incident (type 2)	Incidents	Map severity, impact, urgency fields
change (type 3)	Changes	Map change type, approval chain, risk
problem (type 4)	Problems	Map known error flag, workaround fields

Custom fields in SysAid exist at the Service Record level and may apply to all types or be type-specific via conditional display. You must audit each custom field and determine which Freshservice record type it maps to — and what happens when a field exists in SysAid for "all types" but Freshservice requires it only on one.

Direction 2: Freshservice → SysAid (entity collapse)

Four Freshservice tables must be collapsed into SysAid's ServiceRecord with a type discriminator:

1. Audit all custom fields across all four Freshservice record types
2. Identify field name conflicts (same field name, different data type across record types)
3. Define the target field schema in SysAid, consolidating where possible
4. Map priority/severity/urgency combinations to SysAid's unified priority model
5. Handle ticket references that cross record types (a ticket linked to an incident linked to a problem) — these relationships must survive the collapse

What does not transfer automatically in either direction:

• Workflow automations and business rules (must be rebuilt from scratch)
• SLA policies and breach escalation logic (must be reconfigured)
• Dashboard configurations and saved report definitions
• SSO and identity provider settings
• Agent permission structures and role hierarchies
• Canned responses / predefined reply templates

---

What data can you migrate?

From SysAid: Service requests with full conversation history, end users and agents, public and internal notes, file attachments from tickets and comments, custom fields and their values, and category hierarchies.

From Freshservice: Tickets (all types), conversation threads, contacts and companies, asset records, knowledge base articles, and custom field data via API or Bulk Migration endpoints.

Realistic migration timeline for mid-size deployments (20,000–100,000 records, 30–80 agents):

Phase	Duration
Planning, field mapping, and schema audit	3–5 days
Script development and environment setup	5–10 days
Test migration and stakeholder validation	2–3 days
Full migration execution	1–3 days
Post-migration validation and cleanup	2–3 days
Total	13–24 business days (2.5–5 weeks)

Timeline drivers: attachment volume is the single largest variable. Custom field complexity and the number of record types in scope are second and third.

---

What are the biggest migration risks?

1. Broken ticket relationships Parent-child ticket links, related CI associations, and merge histories are stored differently in each platform. A naive CSV export loses these relationships entirely. Extraction scripts must explicitly query relationship tables and reconstruct links in the target system's schema before importing child records.

2. Attachment volume exceeding API budget At SysAid's rate limit, 50,000 attachments consume 50,000 API requests — approximately 4+ hours of extraction time before any other data is touched. Test attachment extraction on a sample dataset during the planning phase, not after contracts are signed.

3. Custom field type mismatches A multi-select dropdown in one platform may need to become a checkbox group, tag field, or text area in the other. Audit every custom field's data type, allowed values, and whether it accepts null before writing transformation logic. Multi-select fields with comma-separated values are particularly prone to splitting errors.

4. Requester and agent deduplication Email address mismatches, inactive accounts, SSO-linked identities with different canonical addresses, and shared mailbox accounts all create duplicate user records in the target instance. Build a user reconciliation step before any ticket import — orphaned tickets with no valid requester reference cause import failures or silent data loss.

5. SysAid on-prem direct database access (underutilized) This is the most technically significant migration advantage for SysAid On-Premises that almost no migration guide covers adequately. If you are migrating off SysAid On-Premises, you likely have direct access to the underlying MySQL or MS SQL database. This bypasses the 200-request/minute API ceiling entirely.

Key SysAid database tables for direct extraction:

• ServiceLog — the primary Service Record table containing all ticket types
• ServiceLogArchive — archived/closed records (often excluded from API exports)
• Users — end user records
• AdminUser — agent records
• Attachments — file metadata (binary content stored on filesystem or as BLOB depending on configuration)
• CustomColumns — custom field definitions and values

Direct SQL extraction on a well-indexed production or snapshot database can process 500,000+ records in minutes rather than hours. Confirm database access with your DBA and your SysAid support contact before defaulting to API-only extraction. For large on-prem migrations, this difference can compress the extraction phase from days to hours.

6. SysAid ServiceLogArchive exclusion Many SysAid API queries return only active/recent records by default. The ServiceLogArchive table — which contains closed tickets past a configurable age threshold — may be excluded from standard API exports. If historical ticket data is required for compliance or audit purposes, direct database access or a custom archive export is mandatory.

---

On-premises security: risks of choosing SysAid On-Prem

SysAid On-Premises appeals to regulated industries, but the security posture requires active management. Multiple XML External Entity (XXE) injection vulnerabilities (CVE-2025-2775, CVE-2025-2776, CVE-2025-2777) were discovered in on-premises installations in 2025, enabling unauthenticated remote command execution. In November 2023, a zero-day vulnerability (CVE-2023-47246) was actively exploited in the wild by the Cl0p ransomware group, affecting on-prem customers who had not applied patches.

Running SysAid On-Premises means your security team owns the full patch lifecycle. With quarterly release cadence, you may wait 6–12 weeks between a vulnerability disclosure and an available patch — longer than SysAid Cloud customers, who receive fixes as part of the continuous deployment cycle.

This is not a reason to categorically reject on-prem. Organizations with genuine data sovereignty requirements may have no alternative. It is a reason to staff your patching SLA accordingly and maintain a vulnerability monitoring subscription (NVD, SysAid security advisories) as part of your operational commitment.

Freshservice sidesteps this by being cloud-only, with Freshworks owning infrastructure security. The trade-off is that you accept Freshworks' data-residency model and have no path to on-prem hosting if requirements change.

---

Decision framework

If your primary constraint is…	Choose…	Reason
Fastest deployment and lowest onboarding friction	Freshservice	Days to two weeks vs. 2–12 weeks
On-premises or hybrid deployment	SysAid	Only option; Freshservice has no on-prem path
AI included at mid-tier without per-agent add-on fees	SysAid (ITSM plan)	Copilot included; Freshservice charges $29/agent/mo extra
ESM across HR, legal, facilities with native workspaces	Freshservice	Dedicated Workspace model; SysAid lacks equivalent structure
Asset management from the base tier	SysAid	Included in Help Desk; Freshservice gates at $49/agent/mo
Published, predictable pricing	Freshservice	SysAid requires direct vendor negotiation
Gartner Magic Quadrant Leader recognition	Freshservice	2026 ITSM MQ Leader
Direct database access for migration or integration	SysAid On-Premises	MySQL/MS SQL access; no equivalent in Freshservice
Broader third-party integration marketplace	Freshservice	Larger connector library; Freshworks platform ecosystem
Security patch control over your own timeline	Neither — evaluate carefully	On-prem = you own it; cloud = vendor owns it

Neither platform is universally better. The right choice depends on where your constraints actually bind. If on-prem is non-negotiable, the decision is already made. If AI cost bundling and asset management depth matter from day one and your team can handle more onboarding complexity, SysAid ITSM is competitive. If speed, ESM breadth, and pricing transparency are the priority, Freshservice wins on all three.

---

Migration planning: what to do before you sign anything

Regardless of which direction you're migrating, these steps apply before you commit to a timeline or vendor:

1. Audit your current record counts by type. Incidents, requests, changes, problems, assets, knowledge articles — separately. This determines API extraction time and directly sets the migration timeline.
2. Count your attachments. Total attachment count is often 3–5x the ticket count and is the single largest driver of extraction time.
3. Export your custom field schema from both platforms. Map every field: name, data type, allowed values, required/optional, record type scope.
4. Identify your relationship graph. Parent-child tickets, CI-to-ticket links, problem-to-incident links. These must survive migration or be explicitly written off.
5. Confirm SysAid database access (if migrating from on-prem) before planning API-based extraction. The difference is hours vs. days.
6. Disable all automations in the target system before any test or production import.
7. Run a test migration on a representative sample — not just 100 records, but a slice that includes edge cases: tickets with multiple attachments, tickets with all custom fields populated, tickets with parent-child relationships.
8. Validate requester and agent records before ticket import. Every ticket import failure caused by a missing user reference creates orphaned records that are difficult to clean up post-migration.