---
title: "SysAid vs HaloITSM: Architecture, TCO & Migration Guide"
slug: sysaid-vs-haloitsm-architecture-tco-migration-guide
date: 2026-09-17
author: Raajshekhar Rajan
categories: [Migration Guide, SysAid ITSM, HaloITSM]
excerpt: "A direct comparison of SysAid and HaloITSM covering architecture, pricing, data models, and step-by-step migration guidance between both platforms."
tldr: SysAid leads on AI automation at $89/agent/month; HaloITSM offers all-inclusive ITIL licensing from ~$49–70/agent. Migrating between them requires careful mapping of SysAid's unified Service Record to HaloITSM's typed tickets.
canonical: https://clonepartner.com/blog/sysaid-vs-haloitsm-architecture-tco-migration-guide
---

# SysAid vs HaloITSM: Architecture, TCO & Migration Guide


# SysAid vs HaloITSM: Architecture, TCO & Migration Guide

SysAid and HaloITSM both target mid-market IT teams that need ITIL-aligned service management without the cost and complexity of ServiceNow. The right choice depends on three factors: how much you value embedded AI automation, whether you need flat all-inclusive licensing, and how your data model maps between the two platforms during migration. This guide covers architecture, verified pricing, API specifics, and the technical details of moving data between them.

**Disclosure:** ClonePartner provides ITSM migration services and has a commercial interest in both platforms discussed here. All pricing and technical claims are attributed to named sources where possible.

---

## SysAid ITSM at a Glance

**SysAid** is an AI-first IT service management platform built for internal IT departments handling employee-facing helpdesk operations. It addresses high ticket volume, inconsistent categorization, slow resolution, and agent time lost to repetitive documentation.

SysAid supports both cloud and on-premise deployment. Cloud instances run on AWS with AES-256 encryption at rest, SSL/TLS in transit, and DDoS protection. The platform holds ISO 27001, ISO 27017, ISO 27018, and SOC 2 Type 2 certifications, verified through annual third-party audits and penetration tests.

Core capabilities include:

- ITIL-aligned incident, problem, and change management with AI Agents that automate categorization, prioritization, and root cause analysis
- AI-enhanced Service Catalog and CMDB with automatic asset discovery and dependency mapping
- 120+ prebuilt AI agents plus a no-code builder for custom agents
- REST API with full CRUD operations across all primary entities

**Key architectural detail for migrations:** SysAid stores Incidents, Requests, Changes, and Problems in a single unified **Service Record** entity. This simplifies SysAid's internal logic but creates a mandatory classification step when migrating to platforms — including HaloITSM — that use distinct tables per ITIL process.

### SysAid Deployment and Update Cadence

Cloud deployments receive automatic weekly updates. On-premise deployments require manual updates 2–3 times per year, and many advanced features — including the full AI agent suite — are cloud-only.

> [!WARNING]
> **Critical on-premise security issue:** Three XXE injection vulnerabilities (CVE-2025-2775, CVE-2025-2776, CVE-2025-2777) enabled unauthenticated remote command execution on unpatched on-premise instances. All three were patched in version 24.4.60. If running on-premise SysAid, verify your patch level before proceeding with any migration that involves API access.

---

## HaloITSM at a Glance

**HaloITSM** is an ITIL-aligned IT service management platform developed by Halo Service Solutions, headquartered in the UK. It supports both cloud-hosted deployment (AWS) and on-premise installation.

On-premise hardware requirements: dual or quad-core processor at 2 GHz or faster; Microsoft SQL Server 2019 or 2022 for the database layer. Cloud instances follow the same AWS-hosted model as SysAid's cloud offering.

Unlike SysAid's AI-first positioning, HaloITSM emphasizes configurability, ITIL process breadth, and licensing simplicity:

- Every licensed agent accesses the full platform — no tiered plans, no locked modules, no separate charges for asset management, change control, or the knowledge base
- Separate native ticket types for Incidents, Changes, Problems, and Service Requests (no unified entity model)
- REST API using JSON over HTTPS with full CRUD access to tickets, assets, users, knowledge articles, and configurations
- OAuth2 authentication (Client ID + Client Secret) for API access

**HaloITSM security certifications:** Halo Service Solutions does not publish an equivalent ISO/SOC certification list on their public documentation as of this writing. Teams with compliance requirements should request their current certification status directly from Halo.

### HaloITSM Update Cadence

New features ship quarterly, with beta versions available bi-weekly. Recent quarterly releases have added AI search, forecasting tools, multi-instance syncing, and service availability tracking.

---

## Pricing and TCO Comparison

### SysAid Pricing

SysAid publishes its Professional plan at **$89 per agent per month** (as of August 2026, per SysAid's public pricing page). Enterprise tier pricing is quote-only with a minimum of 20 agents. Licensing is agent-based, not process-based — enabling change management or CMDB does not move you to a higher tier.

**Add-on costs that increase TCO:**
- One-time professional onboarding fee (amount varies by scope; SysAid quotes individually)
- Copilot GenAI: separate add-on pricing
- BI Analytics, Patch Management, Remote Control: separately billed modules
- Workato automation credits: base credits included, additional usage billed

### HaloITSM Pricing

HaloITSM publishes a single list rate of **$99 per agent per month**, billed annually (source: HaloITSM public pricing page). This includes incident, problem, change, and release management; CMDB; asset management; SLA tracking; and the self-service portal. End users who submit tickets are free and unlimited — only service desk analysts consume licenses.

Negotiated pricing reported across user communities (G2, Reddit r/sysadmin, Spiceworks) ranges from **$49 to $70 per agent per month**, with volume discounts typically beginning around 25 agents. These figures are community-reported, not vendor-confirmed, and should be treated as directional rather than definitive.

Additional pricing details:
- Named licenses (one login per agent) and concurrent licenses (shared pool for shift-based teams) are both available
- 15% discount for charities, educational institutions, and non-profit organizations (per HaloITSM documentation)

### TCO Comparison: 25-Agent Team Over 3 Years

| Cost Factor | SysAid Professional | HaloITSM (Negotiated) |
|---|---|---|
| Per-agent/month (list) | $89 | $99 (list) |
| Per-agent/month (negotiated, community-reported) | ~$70–80 | ~$55–65 |
| Annual license (25 agents, negotiated) | ~$21,000–$24,000 | ~$16,500–$19,500 |
| 3-year license | ~$63,000–$72,000 | ~$49,500–$58,500 |
| Onboarding | Vendor-quoted; typically $3,000–$10,000 | Partner-dependent; typically $5,000–$15,000 |
| AI/automation add-ons | Copilot GenAI billed separately | Included in base |
| Concurrent licensing | Not publicly offered | Available |

> [!NOTE]
> HaloITSM's all-inclusive licensing produces a lower 3-year TCO for most 25-agent teams — but users consistently report that implementation complexity requires significant third-party consultant spend. SysAid's AI automation capabilities may offset higher license costs if they measurably reduce ticket handling time or headcount requirements.

---

## Feature Comparison Matrix

| Capability | SysAid | HaloITSM |
|---|---|---|
| **Ticket data model** | Unified Service Record | Separate typed tables per ITIL process |
| **Incident management** | Included | Included |
| **Change management** | Included (Professional+) | Included |
| **Problem management** | Included (Professional+) | Included |
| **CMDB** | AI-enhanced, auto-discovery | Included; Virima integration available |
| **Asset management** | Included | Included |
| **AI / automation** | Copilot GenAI, 120+ AI agents, agentic resolution | AI search, ticket summarization |
| **Self-service portal** | AI chatbot, multi-language | Traditional KB with ticket submission |
| **API protocol** | REST, full CRUD | REST (JSON/HTTPS), full CRUD, OAuth2 |
| **Multi-instance sync** | Not available | Available (released Q1 2025) |
| **Concurrent licensing** | Not publicly offered | Yes |
| **Security certifications** | ISO 27001/27017/27018, SOC 2 Type 2 | Not publicly documented |
| **On-premise AI features** | Limited; most AI is cloud-only | Full feature parity on-premise |
| **Deployment** | Cloud (AWS) + on-premise | Cloud (AWS) + on-premise |

### Where SysAid Has a Clear Advantage

SysAid's embedded generative AI layer is the most technically differentiated aspect of the platform as of 2025–2026. The AI operates autonomously: understanding the incoming request, checking authorization, routing, and in many cases resolving tickets without agent involvement. The 120+ prebuilt AI agents cover common IT workflows (password resets, access requests, software provisioning) and are configurable through a no-code builder. This is embedded, not bolted-on via third-party integration.

SysAid also holds stronger documented security certifications, which matters for organizations in regulated industries.

### Where HaloITSM Has a Clear Advantage

HaloITSM's multi-instance syncing (released Q1 2025) allows configuration alignment across development, staging, and production environments — including sync pipelines, cross-instance ticket linking, and controlled change propagation. SysAid has no equivalent capability.

Concurrent licensing makes HaloITSM more cost-effective for shift-based teams, where named licensing would require purchasing seats that sit idle across shifts.

Full feature parity between cloud and on-premise installations is a meaningful differentiator for organizations that cannot move to cloud due to regulatory or data residency requirements.

---

## Data Models: The Core Migration Challenge

Understanding [the data model of each platform is the prerequisite for any migration](https://clonepartner.com/blog/blog/help-desk-data-migration-playbook). The structural mismatch between them is the primary source of migration complexity.

### SysAid's Unified Service Record Model

SysAid stores all ITIL ticket types — Incidents, Service Requests, Change Requests, and Problems — in a single **Service Record** entity. Fields like `type` and `category` distinguish what kind of record it is, but they share one database table and one API endpoint structure.

A SysAid API response for a Service Record includes:
- `id`: internal integer identifier
- `info`: array of field objects, each with `key`, `value`, and `valueClass`
- `activities`: array of update/note history entries
- `attachments`: array with filename, MIME type, and download URL

Custom fields appear within the `info` array using the key format `custom_field_N`.

### HaloITSM's Typed Ticket Model

HaloITSM maintains separate native ticket types: Incidents, Changes, Problems, and Service Requests. Each has its own endpoint and its own custom field namespace.

**Critical import constraint:** Five HaloITSM record types are import-only and cannot be updated via the import mechanism after initial creation: Tickets, Actions, Customer Contracts, Supplier Contracts, and Knowledge Base Articles. Once imported, these records can only be modified through the API or UI — not re-imported. This means import errors in these categories require API-level correction, not a simple re-run.

**The migration mapping problem in concrete terms:** A SysAid export of 50,000 Service Records does not map to 50,000 HaloITSM records of one type. It maps to N incidents + M service requests + P changes + Q problems, where the correct split depends on SysAid category and type field values that may be inconsistently populated. This classification step is where most SysAid-to-HaloITSM migrations encounter data quality problems.

---

## How to Migrate from SysAid to HaloITSM

[A mid-size migration](https://clonepartner.com/blog/blog/help-desk-data-migration-checklist) (20,000–100,000 records, typical attachment volumes, moderate custom field complexity) typically requires 3–6 weeks end-to-end. The breakdown: 1 week for extraction and profiling, 1–2 weeks for transformation and classification, 1 week for load and validation, 1 week buffer for remediation. Attachment-heavy environments (average 3+ attachments per ticket) should add 1–2 additional weeks.

### Step 1: Extract Data from SysAid

SysAid provides a REST API with full CRUD access to all primary entities. Authentication uses an API user account that operates independently of SSO — create a dedicated API user for migration to avoid SSO-related authentication failures during extraction.

**API endpoints relevant to migration:**
- `GET /api/v1/sr` — Service Records (tickets) with pagination
- `GET /api/v1/ci` — CMDB Configuration Items
- `GET /api/v1/user` — end users and agents
- `GET /api/v1/asset` — assets
- Attachments retrieved per-record via the `attachments` array in each SR response

**Rate limiting:** SysAid's cloud API enforces rate limits, though SysAid does not publish specific requests-per-minute figures in their public documentation. In practice, sustained extraction of large datasets (100k+ records) requires throttling your client to avoid 429 responses. Implement exponential backoff and log all failed requests for retry.

**On-premise alternative:** SysAid on-premise allows direct SQL access to the underlying database (Microsoft SQL Server or MySQL, depending on installation). Direct DB queries bypass API rate limits and can increase extraction speed by 10–20x for large datasets. Risks: the internal schema is not formally documented by SysAid, and direct DB access requires DBA coordination and carries risk of schema changes across versions. Use API extraction as the primary path; direct DB as a fallback for volume-constrained situations.

**CSV export:** SysAid's admin console supports report-based CSV export for flat datasets (users, assets, basic ticket lists). This does not capture ticket activity history, relationships, or attachments. Use for supplemental validation only.

**Entities to extract:**
- Service Records with full `activities` history
- End users and agents (separate objects in SysAid)
- Assets and CMDB CIs with relationship links
- Knowledge base articles
- Attachments (binary, downloaded separately per record)
- Category tree and custom field definitions

### Step 2: Transform and Map to HaloITSM's Schema

**2a. Classify each Service Record into a HaloITSM ticket type.**

Examine SysAid's `type` field and `category` field for each record. Build a classification lookup table:

| SysAid Type Value | SysAid Category Pattern | HaloITSM Target Type |
|---|---|---|
| `1` (Incident) | Any | Incident |
| `2` (Request) | Software install, Access, Hardware | Service Request |
| `3` (Change) | Any | Change |
| `4` (Problem) | Any | Problem |
| `2` (Request) | Unclassified or blank | Requires manual review |

Records with blank or inconsistent type/category values require a data quality pass before classification. In most SysAid datasets, 5–15% of records have ambiguous classification.

**2b. Map custom fields.**

SysAid custom fields use the key format `custom_field_N` within the `info` array. HaloITSM custom fields are defined per ticket type and referenced by field name in the import template. Steps:

1. Export the full custom field definition list from SysAid admin
2. Create matching custom fields in HaloITSM under Configuration → Tickets → Custom Fields, scoped to the appropriate ticket type(s)
3. Build a mapping table: `{sysaid_key: "custom_field_3", halo_field_name: "department_code", halo_ticket_type: ["Incident", "Service Request"]}`
4. A single SysAid custom field used across all record types may need to be replicated across multiple HaloITSM ticket types

**2c. Map agents and users.**

HaloITSM supports many-to-one agent mapping during import (multiple source agents can be consolidated to a single HaloITSM agent). Document your mapping before import — this cannot be bulk-changed after ticket creation.

**2d. Normalize category hierarchies.**

HaloITSM uses `>` as the separator for nested category levels. Example: `Hardware > Laptop > Screen Issue`. Ensure your SysAid category export is transformed into this format before import.

**2e. Attachment handling.**

SysAid stores attachments as files referenced by URL in the SR response. HaloITSM accepts attachments via multipart form POST to the ticket endpoint during creation. You cannot bulk-import attachments via the spreadsheet importer — they require API calls. For large attachment volumes, run attachment migration as a separate parallel process after the main ticket import completes.

### Step 3: Configure HaloITSM Before Import

Before loading any data:

1. **Disable approval processes:** Go to Configuration → Tickets → Ticket Types, open each ticket type, click Edit, and disable the Approval Process. If this is not done, tickets imported with "Closed" or "Resolved" status will be held in approval queues rather than landing in their correct final state.

2. **Create all custom fields** in HaloITSM before importing tickets. The import will silently drop values for fields that do not exist.

3. **Create a dedicated migration API credential** under Configuration → Integrations → API. Use this credential exclusively for migration activity. Revoke it after cutover. This produces a clean audit trail and avoids entangling migration activity with production API logs.

4. **Pre-load reference data:** Create all client/organization records and user accounts before importing tickets. HaloITSM's importer requires tickets to reference existing client and user records — tickets with unresolvable foreign keys will fail at row level.

5. **Create all SLA definitions** before importing tickets with SLA assignments.

### Step 4: Load Data into HaloITSM

HaloITSM supports two import paths:

**Spreadsheet importer (Configuration → Import Data):**
- Supports 20+ record types including clients, users, assets, and tickets
- Template-based: download the template for each record type, populate, upload
- Field mapping uses column headers that must match HaloITSM's expected field names exactly
- HaloITSM processes each row independently — failed rows do not block successful rows
- Results visible in the import log; the `Result` column shows success or error per row
- Errors visible in browser developer console (Network tab) as API response bodies — check these for specific field-level error messages
- **Cannot be used for attachments**

**REST API (for attachments and complex record linking):**
- Base URL: `https://[your-instance].haloitsm.com/api/`
- Authentication: OAuth2 with Client Credentials grant (`grant_type=client_credentials`)
- Ticket creation: `POST /api/tickets` with JSON body
- Attachment upload: `POST /api/tickets/{id}/attachments` with multipart/form-data
- Rate limiting: HaloITSM does not publish specific rate limits. Test with batches of 100 records and monitor for 429 responses before scaling.

**Import sequence (order is mandatory):**
1. Organizations / clients
2. Users (agents, then end users)
3. Asset classes and asset records
4. CMDB configuration items and relationships
5. Tickets (by type: Incidents, then Service Requests, then Problems, then Changes)
6. Ticket actions / notes (linked to ticket IDs from step 5)
7. Attachments (linked to ticket IDs from step 5)
8. Knowledge base articles

### Step 5: Validate and Cut Over

Run automated validation before declaring the migration complete:

**Record count checks:**
- Total ticket count: SysAid export count = sum of all HaloITSM ticket type counts
- Count by status (Open, Closed, Pending, etc.)
- Count by assignee (top 10 agents)
- Asset count and CI count

**Spot-check sampling:**
- Randomly select 50 tickets across all types
- Verify: subject line, description, status, assignee, custom fields, category, activity count
- Open 10% of attachment links and verify file integrity

**Failure remediation:**
- Failed rows in the spreadsheet import: export the result log, filter for error rows, correct the data, and re-import only the failed records
- Failed API calls: capture the full response body (not just the status code) — HaloITSM returns field-level validation errors in the response JSON
- Missing client/user reference errors: the most common failure type. Resolution: import the missing reference record first, then re-import the dependent ticket

---

## How to Migrate from HaloITSM to SysAid

Migrating from HaloITSM to SysAid inverts the structural problem: you are collapsing multiple typed ticket tables into SysAid's unified Service Record model. This is structurally simpler — no classification step required — but you must preserve the original ticket type in a SysAid custom field or category to avoid losing ITIL process context.

SysAid treats inbound migrations as a professional services engagement, not a self-service tool. Their documentation describes it as "a custom development package." Budget accordingly.

**HaloITSM extraction:**
- [Authenticate with OAuth2 Client Credentials](https://clonepartner.com/blog/blog/how-to-export-data-from-haloitsm-api-limits-methods-portability)
- `GET /api/tickets?type=1` (Incidents), `type=2` (Changes), etc. — extract each type separately and tag with source type
- `GET /api/assets` for asset records
- `GET /api/knowledgearticles` for KB content
- Attachments: `GET /api/tickets/{id}/attachments` per ticket

**Version-specific constraint:** Self-hosted HaloITSM instances may have slower API response times or non-standard rate limits depending on server configuration. Test extraction throughput in a non-production window before scheduling the full extraction.

**SysAid ingestion:**
- SysAid does not provide a native bulk import UI for tickets. Inbound migration requires either SysAid professional services or API-based creation via `POST /api/v1/sr`
- Map HaloITSM ticket type back to SysAid `type` field and preserve in a custom field
- Activity history (notes, updates) maps to SysAid's `activities` array — import these as notes on the parent SR

---

## When to Choose SysAid

- **AI-driven ticket resolution is the primary requirement.** SysAid's embedded generative AI layer autonomously handles categorization, routing, and resolution for common request types. This is the most mature embedded AI capability in this price segment as of 2026.
- **Compliance certification requirements.** ISO 27001, ISO 27017, ISO 27018, and SOC 2 Type 2 are documented and audited annually.
- **Cloud-first deployment.** SysAid's cloud offering is significantly more capable than its on-premise version, particularly for AI features.
- **Team size 50–5,000 employees** running ITIL-aligned workflows where ticket volume is the primary operational constraint.

## When to Choose HaloITSM

- **Predictable, all-inclusive licensing.** No module upsells, no tier-gating at any agent count.
- **Concurrent licensing for shift-based teams.** Shared license pools reduce per-seat cost for operations centers with overlapping shifts.
- **Multi-instance environment management.** Sync pipelines across dev/staging/production environments with no SysAid equivalent.
- **On-premise deployment with full feature parity.** HaloITSM does not restrict features to cloud-only.
- **Budget-constrained teams where AI automation is secondary.** Negotiated HaloITSM pricing ($55–65/agent) undercuts SysAid's list price ($89/agent) by 25–35%.

---

## Common Migration Pitfalls

**1. Skipping the Service Record classification step.**
Exporting SysAid data as a flat CSV and importing without type classification results in all records landing as a single ticket type in HaloITSM. You lose ITIL process separation entirely. Classification is mandatory, not optional.

**2. Not disabling HaloITSM approval workflows before import.**
Tickets imported with "Closed" or "Resolved" status will enter the approval queue rather than landing in their final state. Disable approval processes under Configuration → Tickets → Ticket Types before any import run.

**3. Underestimating attachment volume.**
Attachments are always the slowest migration component and cannot use the spreadsheet importer. A 50,000-ticket dataset with an average of 3 attachments per ticket at 500 KB average size represents ~75 GB of binary transfer. At typical API throughput rates, this is a multi-day operation that must be planned as a separate workstream.

**4. Creating custom fields after starting the import.**
HaloITSM silently drops custom field values for fields that do not exist at import time. The import log will show the row as successful even though the custom field data was lost. Create all custom fields before loading any ticket data.

**5. Ignoring the import-only constraint on five record types.**
Tickets, Actions, Customer Contracts, Supplier Contracts, and Knowledge Base Articles cannot be updated via re-import after initial creation. Data errors in these record types require API or UI correction. Test with a 500-record sample before running the full import.

**6. API rate limit miscalculation.**
Neither SysAid nor HaloITSM publishes specific API rate limit figures. For datasets over 50,000 records, assume you will encounter rate limiting and build retry logic with exponential backoff into your extraction and load scripts from the start. Do not wait to add this after your first 429 response at scale.

**7. Missing rollback planning.**
Before cutover, define: (a) the point-in-time at which SysAid or HaloITSM becomes the system of record, (b) what constitutes a rollback trigger, and (c) how you will reconcile tickets created in the new system between migration start and rollback execution. For most teams, maintaining read-only access to the source system for 30 days post-cutover is the minimum viable rollback posture.

---

## Market Position and Review Data

| Platform | Gartner Peer Insights Rating | Gartner Review Count | G2 Rating | G2 Review Count | ITSM Market Mindshare |
|---|---|---|---|---|---|
| HaloITSM | 4.6 / 5 | 164 | 4.8 / 5 | 19 | 2.7% |
| SysAid | 4.5 / 5 | 665 | 4.5 / 5 | 739 | 0.7% |

*Sources: Gartner Peer Insights and G2, figures as cited in source material. Mindshare figures sourced from PeerSpot ITSM category data. Verify currency before using for procurement decisions.*

SysAid's substantially higher review count (665 vs. 164 on Gartner; 739 vs. 19 on G2) provides greater statistical confidence in its ratings. HaloITSM's higher G2 rating from a small sample size should be weighted accordingly.

The mindshare inversion — HaloITSM at 2.7% vs. SysAid at 0.7% — reflects Halo Service Solutions' broader product family visibility (HaloPSA serves the MSP market in addition to HaloITSM's internal IT focus) rather than ITSM-specific adoption rates.

---

## Decision Framework: Weighted Scoring Model

Rate each criterion from 1–5 for your organization's needs, multiply by the weight, and sum.

| Criterion | Weight | SysAid Score (typical) | HaloITSM Score (typical) | Your Score: SysAid | Your Score: HaloITSM |
|---|---|---|---|---|---|
| AI/automation maturity required | 25% | 5 | 2 | — | — |
| Licensing cost predictability | 20% | 3 | 5 | — | — |
| On-premise feature parity needed | 15% | 2 | 5 | — | — |
| Security certification requirements | 15% | 5 | 2 | — | — |
| Multi-instance management needed | 10% | 1 | 5 | — | — |
| Concurrent licensing needed | 10% | 1 | 5 | — | — |
| Implementation simplicity | 5% | 4 | 2 | — | — |

**How to use:** Score each criterion 1–5 based on how critical it is for your organization (1 = not important, 5 = essential). The platform with the higher weighted sum is the better fit given your priorities. This model reflects typical platform capabilities — adjust the platform scores if your evaluation reveals different capabilities.

---

## Planning a Migration

Whether you're moving from SysAid to HaloITSM or the reverse, the technical risks are concrete and addressable:

- **SysAid's unified record model** requires mandatory type classification before HaloITSM import — this cannot be skipped or automated without first profiling your data quality
- **HaloITSM's import-only constraint** on five record types means data errors require API remediation, not re-import
- **API rate limits** on both platforms require throttled extraction with retry logic for datasets over 50,000 records
- **Attachment volumes** must be planned as a separate workstream with independent timeline estimates
- **Custom field mismatches** between SysAid's unified entity and HaloITSM's per-type fields require advance configuration on the destination side

At ClonePartner, ITSM migrations are a core service. We have built extraction and transformation tooling for SysAid's API and have direct experience loading data into HaloITSM's import system. If you're evaluating a platform switch and want a concrete timeline and scope estimate, we're available for a scoping conversation.

> Planning a SysAid or HaloITSM migration? Book a 30-minute scoping call for a concrete estimate covering timeline, record volume, data coverage, and cost.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### How much does SysAid cost per agent compared to HaloITSM?

SysAid Professional is $89/agent/month at list price. HaloITSM lists at $99/agent/month but street prices range from $49–$70 through resellers and volume discounts. HaloITSM includes all ITIL modules with no tier-gating; SysAid may incur add-on costs for Workato credits, BI Analytics, and Patch Management.

### Can I migrate data from SysAid to HaloITSM?

Yes, but SysAid stores all ticket types in a unified Service Record entity while HaloITSM uses separate types (Incident, Change, Problem, Service Request). Each record must be classified and mapped to the correct HaloITSM ticket type. Extract via SysAid's REST API or direct SQL (on-prem), then load via HaloITSM's spreadsheet importer or API.

### Does HaloITSM offer on-premise deployment?

Yes. HaloITSM supports both cloud (AWS-hosted) and on-premise deployment. On-prem requires Windows Server 2016/2019/2022 and Microsoft SQL Server 2019/2022 with a minimum of 8 GB RAM and a dual-core 2 GHz processor. The per-agent pricing model is the same for both deployment types.

### Which is better for AI automation, SysAid or HaloITSM?

SysAid is significantly ahead on AI. Its platform includes embedded generative AI (SysAid Copilot), 120+ prebuilt AI agents, and agentic automation for ticket resolution. HaloITSM has added AI search and ticket summarisation but uses a more traditional ITSM workflow architecture with limited autonomous automation.

### How long does a SysAid to HaloITSM migration take?

Expect 2 to 5 weeks for a mid-size deployment of 20,000–100,000 records. The main variables are attachment volume, custom field complexity, CMDB relationship depth, and API rate limits on both sides. Larger migrations with 100k+ records may need multi-day extraction windows.