---
title: "Siit vs HaloITSM: Architecture, TCO, and Migration"
slug: siit-vs-haloitsm-architecture-tco-and-migration
date: 2026-09-21
author: Nachi Raman
categories: [Migration Guide, Siit, HaloITSM]
excerpt: "A technical comparison of Siit vs HaloITSM covering architecture, pricing, ITIL coverage, API constraints, and step-by-step migration guidance between both platforms."
tldr: "Siit is a chat-native AI service desk starting at $23/admin/month; HaloITSM is a full ITIL 4 platform at $49–$99/agent/month. Your choice depends on deployment model, ITIL maturity, and compliance needs."
canonical: https://clonepartner.com/blog/siit-vs-haloitsm-architecture-tco-and-migration
---

# Siit vs HaloITSM: Architecture, TCO, and Migration


# Siit vs HaloITSM: Architecture, TCO, and Migration

*Disclosure: This analysis is published by a data migration services company that has executed migrations on both platforms. All pricing and technical specifications have been independently verified against vendor documentation and third-party marketplace listings.*

Siit and HaloITSM target the same broad problem — internal service management — but they solve it from fundamentally different starting points. **Siit** is a chat-native, AI-first employee service desk built for teams that live in Slack and Microsoft Teams. **HaloITSM** is a full ITIL 4-aligned ITSM platform with incident, problem, change, CMDB, and asset management built into a single agent-based license. Choosing between them depends on your deployment model, ITIL maturity, budget structure, and how much you value on-premise control versus chat-native speed.

This guide breaks down the architectural differences, real pricing math, feature gaps, common migration failure modes, and the exact steps to migrate data between the two platforms.

## What is Siit?

**Siit is an AI-powered employee service desk that operates natively inside Slack and Microsoft Teams**, turning chat messages into structured, trackable requests without requiring employees to log into a separate portal. Siit positions itself as an employee service management platform rather than a tool limited to IT ticketing. Organizations use it to receive, route, approve, track, and report on requests across IT, HR, Finance, Legal, and Facilities.

Siit's architecture centers on a **Unified Data Model** that pulls context from connected systems — HRIS tools like BambooHR and Workday, identity providers like Okta, and device management tools like Jamf — so AI routing logic can classify and assign requests without human triage. Auto-resolution (where the system acts on a request without agent involvement) is limited to well-defined, integration-backed workflows such as software license provisioning via Okta or equipment requests routed to a fulfillment system. Siit does not publish resolution rate benchmarks publicly; any claimed automation percentage should be validated against your specific request mix during a trial.

### Key Siit characteristics

- **Cloud-only** — no on-premise deployment option
- 100+ native integrations, including Jira Service Management, ServiceNow, Zendesk, Okta, Jamf, and BambooHR (per Siit integration documentation)
- Public REST API available on Standard and Pro plans; rate-limited to 60 requests per minute by default, with quota increases available on request
- Essentials plan has no API access — a critical constraint for programmatic data extraction or migration
- SOC 2 Type 2 certified and GDPR-aligned
- No mobile app
- Supports English and French only

## What is HaloITSM?

**HaloITSM is an ITIL 4-aligned IT service management platform** covering incident management, problem management, change enablement, request fulfillment, service level management, CMDB, and asset tracking — all included in a single agent license with no module gating. HaloITSM uses a REACT-based frontend hosted on AWS with a blue-green deployment strategy that eliminates downtime during updates.

Unlike Siit's chat-first model, HaloITSM is portal-centric: the web portal and self-service front end are the primary interfaces, with Slack and Teams integrations that support ticket creation and notifications but do not replicate the full workflow engine inside chat.

### Key HaloITSM characteristics

- Deployment options: cloud (AWS), private cloud, and on-premise
- 250+ native integrations (per HaloITSM partner documentation)
- REST API covering core objects: tickets, users, assets, configuration items, contracts, and suppliers
- Certifications: ISO 27001, SOC 2 Type II, FedRAMP, GDPR, Cyber Essentials Plus, IRAP, and HIPAA
- 99.99% uptime SLA (published on HaloITSM's website)
- Native iOS and Android mobile apps
- Supported languages: English, Dutch, French, German, and Portuguese

## How do Siit and HaloITSM differ architecturally?

The core architectural split is **chat-native vs. portal-centric**.

A Slack/Teams-native service desk like Siit uses an architecture where intake, triage, workflow execution, and resolution all happen inside the collaboration tool. Employees never context-switch to a portal. The collaboration tool *is* the service desk interface. This is not a UI preference — it's a structural commitment that shapes what the platform can and cannot do. Without a portal, HaloITSM features like full CMDB visualization, change advisory board workflows, and problem management dashboards have no equivalent surface in Siit.

HaloITSM's architecture is built around an API-centric backend with a traditional web portal as the primary interface. Teams and Slack integrations exist but are notification and intake channels, not full feature surfaces. The workflow engine, SLA logic, CMDB, and reporting all live in the portal.

| Dimension | Siit | HaloITSM |
|---|---|---|
| **Primary interface** | Slack / Microsoft Teams | Web portal + self-service portal |
| **Deployment** | Cloud-only (SaaS) | Cloud, private cloud, or on-premise |
| **ITIL coverage** | Request management, basic incident handling | Full ITIL 4: incident, problem, change, CMDB, SLM |
| **CMDB** | Lightweight asset tracking via integrations | Full CMDB with CI dependency mapping and impact analysis |
| **Workflow engine** | AI routing + approval chains | No-code drag-and-drop with SLA rules, escalation, and CAB |
| **AI approach** | Automated routing and integration-backed auto-actions | AI triage suggestions, case clustering, KB article generation |
| **API architecture** | REST, 60 req/min default, plan-gated | REST, pagination-based, broader object coverage, no published rate limit |
| **Mobile app** | None | Native iOS and Android |
| **Languages** | English, French | English, Dutch, French, German, Portuguese |

The practical implication: if your team already operates inside Slack or Teams and primarily handles service requests — access provisioning, equipment, onboarding, HR inquiries — Siit's architecture reduces friction. If you need ITIL process discipline, particularly change management, problem management, or a production-grade CMDB, HaloITSM is the more complete platform.

## What does Siit actually cost?

Siit uses **admin-only pricing**. Rather than charging per employee or per ticket requester, Siit charges only for administrators who manage the platform. All employees who submit requests are included at no cost on every plan.

| Plan | Price (per admin/month, billed annually) | Key capabilities |
|---|---|---|
| Essentials | $23 | Basic ticketing, Slack/Teams integration, core workflows. No API access. |
| Standard | $45 | Advanced workflows, AI features, 100+ integrations, HRIS integration, API access |
| Pro | $89 | Full AI agent actions, advanced analytics, SLA management, API access |
| Enterprise | Custom | Dedicated support, custom integrations, compliance features |

All plans include unlimited employees (requestors) and a 14-day free trial with no credit card required.

**Example TCO for a 500-person company with 5 admins:**
- Essentials: $115/month ($1,380/year) — no API, no advanced AI
- Standard: $225/month ($2,700/year)
- Pro: $445/month ($5,340/year)

The admin-only model makes Siit cost-efficient at high employee-to-admin ratios. The key constraint: the Essentials plan has no API access, which means programmatic data extraction, integrations beyond pre-built connectors, and migration scripts are unavailable without upgrading. Most organizations land on Standard or Pro.

## What does HaloITSM actually cost?

HaloITSM uses **per-agent pricing with an all-inclusive module structure**. There are no tiered plans and no separate charges for asset management, change control, CMDB, or the knowledge base. Every agent license includes the full platform.

| Channel | Price (per agent/month) | Commitment |
|---|---|---|
| Direct | $99 | Annual |
| Authorized resellers | ~$49 | Annual |
| AWS Marketplace (Named Agent) | $109/month ($1,308/year) | Annual contract |
| AWS Marketplace (Concurrent Seat) | $215/month ($2,580/year) | Annual contract |

Additional AWS Marketplace line items: Asset Discovery Basic at $2,000/year and Asset Discovery Pro at $4,000/year.

HaloITSM offers a 15% discount for charities, educational institutions, and non-profit organizations.

> **Note:** HaloITSM does not publish pricing on its website. The figures above are sourced from AWS Marketplace listings and authorized reseller documentation. Confirm current pricing directly with Halo Service Solutions before budgeting.

**Example TCO for 10 agents:**
- Direct: $990/month ($11,880/year)
- Reseller: $490/month ($5,880/year)

Per-agent costs scale linearly. For organizations with 50+ agents, volume discount negotiation with Halo Service Solutions is standard practice and can materially reduce TCO.

**On-premise TCO addendum:** If you deploy HaloITSM on-premise, add infrastructure costs to this baseline. A production-ready Windows Server VM with SQL Server for up to 50 concurrent agents typically runs $400–$800/month in cloud infrastructure (AWS EC2 + RDS equivalent), plus 2–4 hours/month of patching and backup administration at your internal IT rate. On-premise is HaloITSM's most distinctive advantage for regulated industries; it's also a TCO line item that the per-agent comparison above does not capture.

## TCO comparison: when is each platform cheaper?

The pricing models are structurally different — admin-based vs. agent-based — so the crossover point depends on your team shape.

| Scenario | Siit Pro | HaloITSM (direct) | HaloITSM (reseller) |
|---|---|---|---|
| 3 admins/agents, 200 employees | $267/mo | $297/mo | $147/mo |
| 5 admins/agents, 500 employees | $445/mo | $495/mo | $245/mo |
| 10 admins/agents, 1,000 employees | $890/mo | $990/mo | $490/mo |
| 25 admins/agents, 2,000 employees | $2,225/mo | $2,475/mo | $1,225/mo |

At direct list price, Siit Pro and HaloITSM are within 10% across all scenarios. Through a reseller, HaloITSM undercuts Siit by 40–45% — and that reseller price includes ITIL modules, CMDB, change management, mobile apps, and on-premise deployment that Siit doesn't offer at any price.

**Total cost of ownership beyond license fees:**

- **Implementation:** Siit's pre-built integrations and chat-native model typically enable deployment in 1–3 weeks for teams under 500 employees. HaloITSM implementations are significantly faster than ServiceNow or Ivanti but still involve ITIL process design, CMDB scoping, SLA rule configuration, and workflow build-out — typically 4–10 weeks for a proper deployment.
- **Ongoing administration:** HaloITSM's no-code workflow engine is powerful but requires ITSM-literate admins who understand ITIL process design. Siit's AI-first routing reduces triage overhead but requires admin time to train routing rules and manage integration health.
- **On-premise infrastructure:** If choosing HaloITSM on-premise, add server, licensing, patching, and backup costs as described above.

## Feature comparison: where each platform wins

### Where Siit wins

- **Chat-native experience:** Employees ticket, approve, and track requests without leaving Slack or Teams. No portal adoption problem.
- **Speed to value:** Production deployment in days to weeks. No ITIL process design required to get started.
- **Low per-employee cost:** Unlimited requestors on every plan — large companies pay only for the admin count.
- **Cross-department by default:** IT, HR, Finance, Legal, and Facilities share one platform from day one with department-specific routing.

### Where HaloITSM wins

- **Full ITIL 4 process coverage:** Incident management, service request management, change management (including CAB workflows), problem management, knowledge management, service level management, asset management, and CMDB — all in one license.
- **On-premise deployment:** Required for air-gapped environments, strict data-residency mandates, and public sector organizations subject to sovereignty requirements.
- **CMDB depth:** Full CI dependency mapping and impact analysis. Siit's asset tracking is integration-backed and lacks CI relationship modeling.
- **Compliance breadth:** ISO 27001, SOC 2 Type II, FedRAMP, GDPR, Cyber Essentials Plus, IRAP, and HIPAA. Siit currently holds SOC 2 Type 2 and GDPR alignment only.
- **All-inclusive licensing:** No feature gating. Every agent gets every module including change, problem, CMDB, and asset management.
- **Mobile apps:** Native iOS and Android. Siit has no mobile app — a meaningful gap for field technicians and on-call engineers.
- **Language support:** Five languages vs. Siit's two.

## How does a migration between Siit and HaloITSM work?

Migrating between Siit and HaloITSM requires extracting data from the source platform's API, transforming it to match the target's data model, and loading it via the target's API or bulk import tools. Both platforms expose REST APIs, but the data models are substantially different — and the differences create specific, predictable failure modes that a generic migration approach will miss.

### Data objects to migrate

| Object | Siit | HaloITSM |
|---|---|---|
| Tickets/Requests | Requests (with conversations, attachments) | Tickets (typed: incident, request, change, problem) |
| Users | Employees + Admins | End Users + Agents |
| Assets | Asset records via HRIS/MDM integrations | CMDB Configuration Items + dedicated Asset objects |
| Knowledge base | AI-managed articles | Knowledge base articles with category hierarchy |
| Workflows/Automations | AI routing rules, approval chains | No-code workflow definitions, SLA rules, escalation paths |
| Custom fields | Custom fields on requests | Custom fields across all object types, with field-type constraints |

### What the API payloads actually look like

Understanding the structural mismatch requires looking at the objects directly. A Siit request retrieved from the API returns a flat object with a `department` field and a `type` field that is typically `"request"` for all record types. A HaloITSM ticket returned from the API includes a `ticket_type` integer field that maps to a lookup table distinguishing incidents (type 1), service requests (type 2), changes (type 4), and problems (type 5), with associated required fields that vary by type.

**Siit request object (simplified):**
```json
{
  "id": "req_abc123",
  "type": "request",
  "department": "IT",
  "status": "open",
  "subject": "New laptop request",
  "body": "I need a MacBook Pro for the design team",
  "created_by": { "id": "emp_456", "name": "Jane Smith" },
  "assigned_to": { "id": "adm_789", "name": "IT Admin" },
  "created_at": "2025-01-15T09:23:00Z",
  "custom_fields": { "priority_level": "normal" },
  "attachments": [{ "id": "att_001", "url": "https://..." }]
}
```

**HaloITSM ticket object (simplified):**
```json
{
  "id": 10042,
  "tickettype_id": 2,
  "summary": "New laptop request",
  "details": "I need a MacBook Pro for the design team",
  "team": "IT Support",
  "agent_id": 12,
  "user_id": 88,
  "status_id": 1,
  "priority_id": 3,
  "dateoccurred": "2025-01-15T09:23:00Z",
  "customfields": [{ "id": 45, "name": "priority_level", "value": "normal" }],
  "attachments": [{ "id": 201, "filename": "spec.pdf", "url": "https://..." }]
}
```

Key structural differences that drive migration complexity: Siit uses string IDs; HaloITSM uses integer IDs. Siit embeds user objects inline; HaloITSM uses foreign key references (`user_id`, `agent_id`) that must resolve against separate user records. Custom fields are a flat object in Siit and an array of typed objects in HaloITSM — and HaloITSM custom fields have defined types (text, number, date, lookup) that constrain what values can be written.

### What makes this migration hard

**1. Data model mismatch — ITIL type assignment.**
Siit treats everything as a "request" across departments. HaloITSM separates tickets into ITIL types: incidents, service requests, changes, and problems — each with distinct required fields and workflow paths. Migrating from HaloITSM to Siit means collapsing these types into a single request type (straightforward). Migrating from Siit to HaloITSM means classifying every historical request into an ITIL type. This classification cannot be automated reliably without a trained model or manual review, because "laptop request," "VPN not working," and "office door broken" require human judgment to assign correctly.

**2. Slack conversation threading has no HaloITSM equivalent.**
Siit requests accumulate conversation context as threaded Slack messages. HaloITSM tickets have a comment/update history but no threading model. During migration, threaded Slack conversations are typically flattened into sequential ticket updates with timestamps preserved but threading context lost. Long conversations with multiple participants and reactions lose structural fidelity.

**3. Workflow logic doesn't transfer.**
Siit's AI routing rules and HaloITSM's no-code workflow engine are completely different paradigms. No automated translation exists. [Workflows must be rebuilt manually on the target platform](https://clonepartner.com/blog/blog/how-to-migrate-automations-macros-workflows) after analyzing the source configuration.

**4. API rate limits and extraction throughput.**
Siit's API is rate-limited to 60 requests per minute by default. For an organization with 50,000 historical tickets and 5 attachments per ticket on average, extraction at 60 req/min takes approximately 14 hours of continuous API calls for tickets alone, plus separate calls for attachments. Scripts must implement exponential backoff on 429 responses and checkpoint state to resume from failures. HaloITSM does not publish a rate limit, but bulk extraction of 100,000+ records requires pagination with `page_size` parameters and should be batched rather than parallelized aggressively to avoid connection pool exhaustion.

**5. Attachment handling.**
Attachments stored in either platform must be downloaded from the source URL, stored in intermediate storage (S3 or local filesystem), and re-uploaded to the target platform's attachment endpoint. For a dataset with 250,000 attachments averaging 500KB each, that's approximately 125GB of intermediate transfer. Network throughput and temporary storage must be planned explicitly.

**6. User deduplication errors.**
Both platforms store users independently. Siit's user model is HRIS-driven (synced from BambooHR, Workday, or Okta). HaloITSM's user model is local with optional LDAP sync. During migration, users frequently appear as duplicates under different email formats (firstname.lastname@company.com vs. flastname@company.com) or with name casing inconsistencies. Unresolved duplicates cause ticket reassignment failures during load.

**7. Custom field type constraints in HaloITSM.**
HaloITSM custom fields enforce data types at write time. A Siit free-text custom field that contains values like "high," "medium," "low" must be mapped to a HaloITSM lookup-type custom field — which must be created with the correct lookup values before any tickets referencing it are loaded. Loading order matters: field definitions before tickets, lookup values before field references.

**8. API access gating on Siit Essentials.**
If you're migrating off Siit and currently on the Essentials plan, the API is unavailable. You must upgrade to Standard or Pro to extract data programmatically. Plan for at least one billing cycle of overlap cost.

### Known failure modes and how to prevent them

| Failure mode | Root cause | Prevention |
|---|---|---|
| Field truncation | HaloITSM text fields have character limits (varies by field type) | Audit max field lengths in target before migration; truncate or split during transform |
| UTF-8 encoding errors | Siit stores emoji and special characters from Slack; HaloITSM SQL backend may reject multi-byte sequences | Normalize all text to UTF-8, strip or replace problematic characters in transform layer |
| Status mapping failures | Siit statuses ("Pending Approval," "In Review") don't map 1:1 to HaloITSM status IDs | Build explicit status lookup table; map to closest equivalent; document all non-obvious mappings |
| Attachment MIME type rejection | HaloITSM's attachment endpoint rejects certain MIME types or file extensions | Run MIME type audit on attachment corpus before migration; filter or convert unsupported types |
| Broken user references | Ticket assigned to user not yet created in target | Always migrate users before tickets; enforce referential integrity checks post-load |
| Approval workflow interference | HaloITSM's Approval Process modifies ticket status on creation | Disable Approval Process before loading historical tickets; re-enable after migration completes |
| Duplicate CI records in CMDB | Siit asset records may have no unique external ID matching HaloITSM CI identifiers | Establish a CI matching key (serial number, hostname, or asset tag) before migration begins |

### Step-by-step migration approach

**Step 1 — Audit the source data.**
Export a statistically representative sample (minimum 500 tickets spanning all statuses, departments, and date ranges) from the source platform's API. Identify custom fields, status values, attachment counts, and user reference patterns.

**Step 2 — Build the field mapping document.**
Define [how each field, status, and category translates to the target platform](https://clonepartner.com/blog/blog/help-desk-data-migration-playbook). For Siit → HaloITSM migrations, explicitly assign ITIL ticket types to request categories. For HaloITSM → Siit migrations, define how ITIL type metadata will be preserved (typically as a custom field). This document is the single most important artifact in the migration — most data quality failures originate from incomplete or assumed mappings.

**Step 3 — Set up API access on both platforms.**
For HaloITSM: create a dedicated API application under Configuration → Integrations → API Applications. You'll need the Authorization Server URL, Client ID, and Client Secret. Do not reuse an existing API application — create a migration-specific credential set so it can be revoked cleanly after migration. For Siit: generate an API key under Settings → API. Confirm your plan supports API access.

**Step 4 — Create target schema before loading.**
In HaloITSM, create all custom fields, lookup values, agent accounts, team structures, and ticket categories before loading any ticket records. Attempting to load tickets that reference non-existent field values or agents will produce silent failures or partial records.

**Step 5 — Write extraction scripts with checkpointing.**
Pull data from the source API in paginated batches, writing each batch to a structured intermediate format (JSON Lines recommended for large datasets). Implement checkpointing so the script can resume from the last successful page after an interruption. For Siit extractions, implement token bucket rate limiting at 55 req/min (5 req/min below the hard limit as buffer).

**Step 6 — Transform the data.**
Apply field mappings, convert status values, resolve user references against the pre-migrated user table, assign ITIL types, and normalize text encoding. Run the transform on your full dataset and validate output statistics against source counts before loading.

**Step 7 — Disable automation in the target.**
Before loading into HaloITSM: disable the Approval Process (Configuration → Approvals), disable any automation rules that trigger on ticket creation or status change, and disable SLA timers if you're loading historical records. These automations will fire on imported records and corrupt status fields, SLA breach flags, and assignment data.

**Step 8 — Run a test migration on a non-production environment.**
Load a representative subset (5–10% of records) into a HaloITSM sandbox or Siit trial instance. Validate field mapping accuracy, attachment integrity, user assignment correctness, and record counts. Calculate an error rate. If error rate exceeds 2%, diagnose and fix before proceeding to full load.

**Step 9 — Execute the full migration.**
Run the complete data load during a low-traffic window (weekend recommended). Monitor API response codes — 429 indicates rate limiting, 422 indicates validation failures with field-specific error messages. Log all failures with the source record ID for post-migration reconciliation.

**Step 10 — Re-enable automation and validate.**
Re-enable the Approval Process, automation rules, and SLA timers. Compare record counts (source vs. target), [spot-check 20–30 tickets across departments and statuses](https://clonepartner.com/blog/blog/help-desk-data-migration-qa-checklist), verify attachment accessibility, and confirm user assignments. Produce a reconciliation report showing total records migrated, failures, and any records requiring manual remediation.

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

Timeline varies significantly by data volume, custom field complexity, and ITIL process design requirements on the HaloITSM side.

| Operation size | Historical tickets | Data extraction + loading | Total project (with process design) |
|---|---|---|---|
| Small | < 10,000 tickets | 1–2 days | 2–4 weeks |
| Medium | 10,000–100,000 tickets | 2–5 days | 6–10 weeks |
| Large | 100,000–500,000 tickets | 5–12 days | 12–16 weeks |

The data extraction and loading phase is a small fraction of total project time. The weeks around it are consumed by field mapping design, ITIL process configuration on the target, workflow rebuilding, user acceptance testing, and training. For HaloITSM specifically, organizations that have never run formal ITIL processes will need to design and configure incident, change, and problem management workflows from scratch — this is the largest time variable.

## When should you pick Siit over HaloITSM?

Choose Siit when:

- Your team operates primarily in Slack or Microsoft Teams and portal adoption is a persistent problem
- You need to go live in days to weeks, not months
- Your primary use case is employee service management across IT, HR, Finance, and Operations — not ITIL process discipline
- You have a high employee-to-admin ratio and want cost to scale with admin headcount only
- You don't need on-premise deployment, formal change management, or a CI dependency-mapped CMDB
- You don't have compliance requirements beyond SOC 2 and GDPR

## When should you pick HaloITSM over Siit?

Choose HaloITSM when:

- You need full ITIL 4 process coverage: change advisory board workflows, problem root cause analysis, service level agreements with breach escalation
- On-premise or private-cloud deployment is a regulatory or security requirement
- You need a production-grade CMDB with CI dependency mapping and impact analysis
- You must comply with FedRAMP, HIPAA, ISO 27001, IRAP, or Cyber Essentials Plus
- You want all-inclusive licensing with no feature gating as you grow
- You need a mobile app for field technicians or on-call engineers
- You operate in languages beyond English and French
- Your agents outnumber your admins — the per-agent model becomes cost-comparable or cheaper at scale when combined with reseller pricing and all-inclusive modules

## What to do when you're ready to migrate

Migrating between ITSM platforms is a data model translation, workflow rebuild, and integration re-wiring exercise — not a straightforward data transfer. The API extraction is 10–20% of the work. The rest is field mapping, ITIL type classification, failure mode prevention, and validation.

The failure modes described in this guide — UTF-8 encoding errors, user deduplication failures, custom field type constraints, Slack conversation flattening, attachment MIME type rejection, and approval workflow interference — are not theoretical. They are the specific failure modes encountered in production migrations between these platforms.

> Our engineering team builds custom migration scripts that handle field mapping, ITIL type conversion, user deduplication, and attachment transfer between Siit and HaloITSM. Book a free 30-minute scoping call to get a volume-based timeline and effort estimate for your specific dataset.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### Is Siit or HaloITSM cheaper for a mid-size company?

It depends on your team shape. Siit charges per admin ($23–$89/month) with unlimited employees, while HaloITSM charges per agent ($49–$99/month). For organizations with few admins and many employees, Siit is cheaper. Through a reseller, HaloITSM at ~$49/agent can undercut Siit Pro while including full ITIL modules.

### Can I migrate ticket history from Siit to HaloITSM?

Yes, both platforms expose REST APIs that allow data extraction and loading. The main challenge is data model translation — Siit uses a flat 'request' model while HaloITSM separates tickets into ITIL types (incidents, requests, changes, problems). Field mapping and status conversion require custom scripting.

### Does HaloITSM offer on-premise deployment?

Yes. HaloITSM supports cloud (AWS), private cloud, and on-premise deployments. Both cloud and on-premise use the same pricing structure, though on-premise adds server infrastructure and maintenance costs to your TCO.

### Does Siit have a CMDB like HaloITSM?

Siit includes a built-in CMDB and asset visibility features, but they're lighter-weight compared to HaloITSM's full CMDB with CI dependency mapping, auto-discovery, and service relationship visualization. If deep configuration management is a priority, HaloITSM is the stronger option.

### How long does a migration between Siit and HaloITSM take?

For mid-size operations, the data migration itself takes 2–5 days. The full project — including field mapping, workflow rebuilding, testing, and training — typically takes 2–4 weeks for straightforward cases or 6–10 weeks for complex setups with multiple integrations.