---
title: "Crisp vs Zammad: Architecture, TCO & Migration Guide"
slug: crisp-vs-zammad-architecture-tco-migration-guide
date: 2026-08-04
author: Rishabh
categories: [Help Desk, Migration Guide]
excerpt: "Crisp vs Zammad compared on architecture, pricing, AI, self-hosting, and migration. A technical guide for teams choosing between conversation-first SaaS and open-source ticketing."
tldr: Crisp is a flat-rate SaaS messaging platform; Zammad is a per-agent open-source helpdesk with self-hosting. No native migration path exists — any move requires custom API scripting.
canonical: https://clonepartner.com/blog/crisp-vs-zammad-architecture-tco-migration-guide/
---

# Crisp vs Zammad: Architecture, TCO & Migration Guide


# Crisp vs Zammad: Architecture, TCO & Migration Guide

> [!NOTE]
> **TL;DR — Crisp vs Zammad**
>
> Crisp is a conversation-first SaaS messaging platform priced per workspace (€45–€295/mo flat). Zammad is a ticket-first open-source helpdesk priced per agent (€7–€26/agent/mo hosted, or free to self-host under AGPL). **Pick Crisp** if you want flat-rate pricing, a live-chat-centric experience, and zero infrastructure management. **Pick Zammad** if you need data sovereignty, self-hosting, AI model flexibility (since 7.0), or per-agent economics. Migration between the two requires custom integration — neither platform has a native import path for the other.
>
> *Disclosure: ClonePartner builds migration pipelines between helpdesk platforms. This guide reflects technical specifics from building those pipelines. Draw your own conclusions.*

## Crisp vs Zammad: Two Fundamentally Different Architectures

This comparison exists because teams evaluating helpdesks in 2026 keep landing on the same shortlist: a modern SaaS messaging platform (Crisp) versus an open-source, self-hostable ticketing system (Zammad). The choice isn't about which is "better" — it's about which data model, deployment model, and cost structure matches your operational reality.

Teams move to Crisp when they want to consolidate around a modern live chat experience without paying the per-seat licenses charged by [platforms like Intercom](https://clonepartner.com/blog/blog/crisp-vs-intercom-2026-architecture-tco-migration-guide/). Teams migrate to Zammad when they outgrow Crisp's flat CRM structure, require on-premise hosting for compliance, or need robust email parsing and SLA escalations.

Here's what actually matters.

### Crisp: The Continuous Conversation

Crisp is an AI-powered customer support platform built around a unified inbox with automated workflows. Its data model centers on **continuous conversations** — a visitor starts chatting, and the thread persists across channels (chat, email, WhatsApp, Instagram) and over time.

Crisp's architecture revolves around the `Conversation` object, bound to a specific `session_id` and a visitor `fingerprint`. Whether a customer emails you on Tuesday, chats on Thursday, and sends a WhatsApp message on Friday, Crisp threads all of these into a single continuous timeline.

**Technical constraints:**

- **No discrete tickets.** There is no native concept of a "Ticket" with a distinct ID that opens and closes independently. A conversation is simply marked `resolved` or `unresolved`.
- **Flat metadata.** Custom data is stored as key-value pairs (`data.key = value`) on the user profile or conversation, not in structured custom fields with strict typing. Crisp does not have standalone "Company" objects with their own API endpoints — company data (name, URL, description, employment, geolocation) is stored as a property on contact profiles. This flat CRM design keeps things simple for SMBs but limits B2B account management at scale.
- **Cloud-only.** Crisp is a proprietary SaaS product. You cannot self-host it, and you cannot directly query its underlying database.
- **Data on cancellation.** Crisp does not offer a bulk export of conversation message content from the dashboard UI. On plan cancellation, contact data can be exported as CSV, but full conversation history (messages, attachments) must be extracted via the REST API before account closure. Crisp's terms do not specify a post-cancellation data retention window — extract before you cancel.

### Zammad: The Structured Ticket

Zammad is an open-source helpdesk system that manages company communication channels from a single platform. It is built on Ruby on Rails in the backend, with a WebApp/HTML5 frontend communicating via WebSockets and REST. Its data model centers on **discrete tickets**. Each customer interaction creates a separate ticket with its own lifecycle. The core entity is the `Ticket`. Every interaction inside that ticket — an email, a note, a phone call log — is an `Article`.

**Technical constraints:**

- **Strict object hierarchy.** `User` → `Organization` → `Ticket` → `Article`. You cannot have a standalone message; it must belong to a ticket.
- **State-driven.** Tickets have strict states (new, open, pending reminder, pending close, closed) and belong to specific Groups (queues). SLA escalation rules apply based on these states and business hours.
- **Open-source flexibility.** Because Zammad is AGPL-licensed, you can self-host, inspect the source code, write direct SQL queries against the PostgreSQL database, and modify Elasticsearch indexing rules.
- **API-first design.** Zammad's web UI is itself a JavaScript API client — every action available in the interface is available via REST. This means there are no UI-only features that escape the API.

This architectural split — continuous conversations vs. discrete tickets — drives every downstream difference in pricing, channels, AI, and migration complexity.

## Pricing and TCO: Per-Workspace vs. Per-Agent

The pricing models are fundamentally opposed. Crisp charges per workspace with flat-rate plans. Zammad charges per agent.

### Crisp Pricing (2026)

Crisp offers four core plans: Free, Mini (€45/mo), Essentials (€95/mo), and Plus (€295/mo) — all billed per workspace per month.

| Plan | Price | Seats Included | Key Features |
|------|-------|----------------|-------------|
| Free | €0 | 2 | Basic live chat, no CRM or AI |
| Mini | €45/mo | 4 | Email, co-browsing, basic AI credits |
| Essentials | €95/mo | 10 | CRM, knowledge base, workflows, AI chatbot (50 actions/day) |
| Plus | €295/mo | 20 | Unlimited AI, ticketing, white-label |
| Enterprise | Custom | Custom | SLAs, enhanced rate limits, dedicated support |

**Plan-jump cliff:** Only the Plus plan allows adding extra seats at $10/agent/month. Free, Mini, and Essentials all have hard agent caps with no expansion option — you must upgrade the entire plan. A team of 11 agents must jump from Essentials (€95) to Plus (€295): a 3× price increase for one extra seat. This cliff is the most common reason teams evaluate Zammad and other [Crisp alternatives](https://clonepartner.com/blog/blog/crisp-alternatives-2026-pricing-features-migration/).

### Zammad Pricing (2026)

| Plan | Price | Agent Limit | Key Features |
|------|-------|-------------|-------------|
| Starter (Cloud) | €7/agent/mo | 5 max (platform-enforced) | Email + web forms only |
| Professional (Cloud) | €17/agent/mo | Unlimited | Chat, messaging, SLAs, knowledge base |
| Plus (Cloud) | €26/agent/mo | Unlimited | Advanced reporting, custom objects |
| Self-Hosted (AGPL) | €0 license | Unlimited | Full features, your infrastructure |
| Business (Self-Hosted Support) | €2,999/year | — | Vendor support bundle |
| Enterprise (Self-Hosted Support) | €5,999/year | — | Extended support |
| Corporation (Self-Hosted Support) | €9,999/year | — | Premium support |

The Starter plan's 5-agent cap is enforced by the platform, not just by contract — you cannot add a sixth agent without upgrading. The Starter plan excludes live chat, WhatsApp, Telegram, SLA management, and the knowledge base. For a three-person team handling only email tickets, that's workable. For anything beyond pure email, Professional is the minimum viable plan.

### The Real TCO Comparison

For a **10-agent team**:

- **Crisp Essentials:** €95/mo (flat) = **€1,140/year**
- **Zammad Professional (Cloud):** €17 × 10 = €170/mo = **€2,040/year**
- **Zammad Self-Hosted:** €0 license + infrastructure costs

For a **20-agent team**:

- **Crisp Plus:** €295/mo = **€3,540/year**
- **Zammad Professional (Cloud):** €17 × 20 = €340/mo = **€4,080/year**
- **Zammad Self-Hosted:** infrastructure + optional vendor support

Crisp wins on sticker price for teams of 10 or fewer on equivalent features. The crossover depends on self-hosting economics.

> [!WARNING]
> **Self-hosting isn't free.** Zammad's architecture requires four components running simultaneously: the Ruby on Rails application server, Elasticsearch (for full-text search), PostgreSQL or MySQL (primary database), and Redis (job queuing and caching). That's four moving parts to provision, secure, back up, and patch.
>
> **Infrastructure cost breakdown for a production Zammad self-hosted instance on AWS:**
>
> | Component | AWS Service | Estimated Monthly Cost |
> |-----------|-------------|----------------------|
> | App server | EC2 t3.large (2 vCPU, 8GB) | €55–€75 |
> | Search | OpenSearch t3.medium.search | €45–€65 |
> | Database | RDS db.t3.medium (PostgreSQL) | €40–€60 |
> | Cache/queue | ElastiCache t3.micro (Redis) | €15–€20 |
> | Storage + backups | S3 + snapshots | €10–€20 |
> | Load balancer | ALB | €20–€25 |
> | **Total infrastructure** | | **€185–€265/month** |
>
> Add engineering time for patching, monitoring, and incident response: at even 5 hours/month at €75/hour internal rate, that's €375/month. Total realistic self-hosting cost: **€560–€640/month** for a baseline HA setup, or **€6,720–€7,680/year**. Vendor support (Business tier at €2,999/year) adds further. Self-hosting is a data sovereignty and compliance decision — not a cost-saving measure for small teams.

## Deployment Model: SaaS-Only vs. Self-Hosted

This is the sharpest differentiator.

**Crisp** is SaaS-only. There is no self-hosted edition. Your data lives on Crisp's infrastructure in the EU. For most SMBs, this is fine. For regulated industries, government, or organizations with strict data residency requirements, it's a non-starter — you cannot audit the infrastructure, run penetration tests on the underlying systems, or guarantee data doesn't leave a specific jurisdiction.

**Zammad** gives you both options. The entire codebase is publicly available under AGPLv3 on GitHub. Every new line of code goes into the public repository. For EU organizations evaluating GDPR compliance, Zammad's German-hosted cloud option and self-hosting path are meaningful differentiators.

Switching between self-hosted and Zammad cloud is supported and documented — you can migrate from self-hosted to cloud (or vice versa) without data loss, which reduces lock-in risk compared to Crisp's single-deployment-model approach.

## Channel Support Compared

| Channel | Crisp | Zammad |
|---------|-------|--------|
| Live Chat | ✅ All plans | ✅ Professional+ |
| Email | ✅ Mini+ | ✅ All plans |
| WhatsApp | ✅ Essentials+ | ✅ Professional+ |
| Instagram | ✅ Essentials+ | ❌ |
| Facebook Messenger | ✅ Essentials+ | ✅ (via Facebook) |
| Telegram | ✅ Essentials+ | ✅ Professional+ |
| SMS | ✅ (via integrations) | ❌ Native |
| Phone/CTI | ❌ (co-browsing instead) | ✅ (sipgate, CTI) |
| Video Chat | ✅ Essentials+ | ❌ |
| Twitter/X | ✅ Essentials+ | ✅ Professional+ |

Crisp leads on social and messaging channels. Its chat widget is lightweight, supports rich media, and includes native features Zammad lacks entirely: **MagicMap** (live visitor tracking on a geographic map), **co-browsing** (viewing the user's screen without browser plugins), and **video calls** embedded directly in the chat widget.

Zammad's live chat widget converts completed chats into standard tickets — it does not feel like an asynchronous messaging experience. Where Zammad pulls ahead is telephony and IT operations integrations: Microsoft 365, Microsoft Teams, Slack, Telegram, WhatsApp Business API, GitHub, GitLab, Grafana, Nagios Core, Zabbix, Checkmk, Icinga, and sipgate. That catalog skews toward IT/DevOps monitoring — a clear indicator of Zammad's roots in IT service management rather than consumer support.

**Email handling difference:** Zammad processes email natively with full HTML rendering, S/MIME encryption, LDAP/Active Directory integration for agent provisioning, and granular SLA escalation rules tied to business hours. Crisp handles email via forwarding and normalizes complex HTML to markdown/text. If email is your primary channel and you need routing rules, S/MIME, or LDAP agent sync, Zammad is the correct choice.

## AI Capabilities: Bundled Credits vs. Bring-Your-Own-LLM

Both platforms shipped meaningful AI features in 2025–2026. The implementation models are fundamentally different in architecture, cost structure, and data exposure.

### Crisp AI (Hugo)

Hugo handles chatbot flows, AI-assisted replies, and conversation summarization. The Essentials plan includes 50 AI actions/day. The Plus plan (€295/mo) includes unlimited AI actions. If you exhaust included credits, Hugo stops processing unless you enable pay-as-you-go billing. The LLM is Crisp-managed — you have no visibility into which model runs your data or on what infrastructure.

### Zammad AI (7.0+, released March 4, 2026)

Zammad 7.0 introduced native AI features for the first time, with a configurable AI provider layer. Three core capabilities shipped:

1. **Ticket Summary** — condenses long ticket threads into concise overviews
2. **Writing Assistant** — refines agent drafts, fixes grammar, expands short replies
3. **AI Agents** — automate routing, categorization, and ticket titling, with every AI action logged in the ticket history for auditability

**Provider options (configurable in the admin panel):** Zammad AI (managed), OpenAI, Anthropic, Azure AI, Mistral AI, Ollama (self-hosted), or any custom OpenAI-compatible endpoint (including Google Gemini-compatible APIs).

**Pricing:** €0.03 per AI call. One AI call equals one discrete invocation: generating a ticket summary is one call; one writing assistant invocation is one call; one AI Agent action (categorize, route, or title a ticket) is one call. A team processing 1,000 tickets/day with summary + categorization = ~2,000 AI calls/day = €60/day = ~€1,800/month at full utilization. Scale accordingly.

**On-premises AI:** Self-hosted Zammad instances running Ollama with open-source models (Llama 3, Mistral 7B, or similar) incur zero AI call charges and keep all inference data within the organization's network. For regulated industries — financial services, healthcare, government — this is a meaningful compliance capability that Crisp cannot match.

## API and Integration Architecture

### Crisp API

Crisp offers two token types:

- **Website tokens** — single-workspace scope, immediate setup, subject to per-minute rate limits on both global and per-route bases
- **Plugin tokens** — multi-workspace scope, bypass per-minute rate limits, subject instead to a daily **Plugin Quota** system

The Plugin Quota is a daily request budget (reset at midnight UTC) allocated to each plugin token. The specific quota ceiling is not publicly documented by Crisp and varies by workspace plan and plugin configuration — contact Crisp support to confirm your token's daily limit before designing bulk pipelines around it.

**Extraction throughput for migrations:** Retrieving conversation history requires two API calls per conversation: one to list conversations (paginated at `/v1/website/{website_id}/conversations/{page_number}`) and one to retrieve messages per conversation (`/v1/website/{website_id}/conversation/{session_id}/messages`). For 50,000 conversations, this means a minimum of 100,000+ API calls.

At a conservative sustained rate of 200 requests/minute (accounting for 429 backoff with exponential retry), 100,000 calls takes approximately **8–9 hours of continuous extraction**. With attachment downloads adding additional calls, realistic full-extraction time for 50,000 conversations with attachments is **18–24 hours**. For datasets above 100,000 conversations, plan for multi-day extraction windows with checkpointing to resume after interruptions.

**Attachment size limits:** Crisp enforces a 100MB per-file attachment limit via the API. Files above this threshold cannot be uploaded via REST and require alternative handling (external CDN reference, manual upload).

### Zammad API

Authentication supports HTTP Basic, API tokens, and OAuth2. The API is fully symmetric with the UI — no features are UI-only.

**Rate limits (Zammad Cloud):** The API returns a maximum of 100 objects per paginated request. Zammad Cloud enforces a rate limit of **500 requests per minute** per API token. Self-hosted instances have configurable limits defaulting to the same 500 req/min ceiling but adjustable by the administrator in the application configuration.

**Attachment size limits:** Zammad enforces a default maximum attachment size of **50MB per file**. Self-hosted administrators can increase this limit in `config/environments/production.rb`, but the Zammad Cloud hosted service enforces 50MB hard.

If you are self-hosting Zammad, you can bypass the API entirely and export directly from PostgreSQL using `pg_dump` or direct SQL queries, reducing full-dataset extraction from hours to minutes.

**Integration catalog:** Zammad integrates with over 20 platforms including Microsoft 365, Microsoft Teams, Slack, GitHub, GitLab, Grafana, Nagios, Zabbix, Checkmk, Icinga, sipgate, and LDAP/Active Directory. Crisp's integration catalog spans approximately 29 native apps, skewing toward marketing, CRM, and e-commerce (though Shopify-first brands often [compare Crisp against Gorgias](https://clonepartner.com/blog/blog/crisp-vs-gorgias-2026-the-ctos-technical-comparison/) for native order management).

## Migration: Crisp ↔ Zammad

There is no native migration path between these two platforms. Neither provides a built-in import/export tool for the other. Any migration requires custom scripting against both REST APIs.

### Data Model Translation

| Concept | Crisp | Zammad |
|---------|-------|--------|
| Core unit | Conversation (persistent thread) | Ticket (discrete lifecycle) |
| Contact | People profile (flat key-value) | User + Organization (relational) |
| Messages | Messages within a conversation | Articles within a ticket |
| Status | Conversation state (pending, resolved) | Ticket state (new, open, pending reminder, pending close, closed) |
| Custom data | Conversation/contact key-value segments | Custom object attributes (typed) |
| Attachments | Per-message, hosted on Crisp CDN (URL reference) | Per-article, base64 encoded or binary blob |
| Company | Property on contact profile | First-class Organization object |
| Agent | Team member (workspace-scoped) | Agent user (Group-scoped) |

### Crisp → Zammad: Splitting Conversations into Tickets

**Step 1: Extract from Crisp.** Use the REST API to paginate through conversations (`GET /website/{website_id}/conversations`). Conversation exports are not available as native CSV from the Crisp dashboard — message content must be extracted via API or a third-party migration tool. Contact data can be exported as CSV from the People dashboard.

**Step 2: Transform conversations into tickets.** This is the core complexity. Because Crisp groups all interactions with a user into a single thread, one user may have a conversation spanning years. Importing this directly into Zammad as one ticket produces an unreadable ticket with hundreds of articles.

Write a transformation script that splits Crisp conversations based on **time decay**: if there is a gap of more than N days between messages in a Crisp session, the subsequent messages become a new Zammad ticket. Fourteen days is a common starting threshold, but the right value depends on your support patterns — analyze your historical data to find the natural gap distribution before hardcoding a value. Map Crisp contact segments to Zammad custom attributes. Translate the flat user/company model into Zammad's hierarchical `User` → `Organization` structure. Build an agent ID mapping table before extraction starts.

**Step 3: Load into Zammad.** Use the Zammad REST API to create objects in strict dependency order: organizations first, then users, then tickets, then articles. Zammad's API validates foreign keys — attempting to create a ticket before its user exists returns a 422. Batch writes at 100 objects per request (the API maximum) and throttle to stay under 500 req/min on Cloud.

**Step 4: Validate.** Cross-check conversation counts, article counts, attachment integrity, and agent assignment coverage. Any articles missing their parent ticket indicate a race condition in your write order.

### Zammad → Crisp: Aggregating Tickets into Conversations

**Step 1: Extract from Zammad.** Use `GET /api/v1/tickets` with `page` and `per_page=100` parameters. Export users and organizations in separate passes. On self-hosted instances, use direct PostgreSQL export for speed — `pg_dump` a filtered dataset and process locally.

**Step 2: Aggregate tickets into conversations.** A user in Zammad may have 20 distinct tickets over a year. Crisp expects one conversation per user (or per session). Collect all Zammad `Articles` from each user's tickets, sort chronologically, and push into a single Crisp `Conversation`. Insert a system message at each ticket boundary to preserve context: `--- Zammad Ticket #1045: Login Issue [2025-03-15] ---`. Flatten `Organization` → `User` into Crisp's key-value contact model, storing the organization name as a contact segment.

**Step 3: Load into Crisp.** Before starting the import, contact Crisp support — they must temporarily block outgoing emails for your Crisp website to prevent historical messages from triggering notification sends during import.

**Step 4: Validate.** Verify imported conversations appear in the Crisp inbox. Note a key behavioral difference: imported conversation history is visible to your team in the inbox, but the end-user does not automatically see past imported exchanges in the chat widget on your website. This is a Crisp platform constraint, not a migration error.

### Handling Attachments

Attachment handling is the most failure-prone part of any cross-platform migration.

In Zammad, attachments are base64-encoded or stored as binary blobs attached to the `Article` object, with a maximum size of 50MB per file. In Crisp, attachments are hosted on Crisp's CDN and referenced by URL in the message payload, with a 100MB per-file maximum.

**The core problem:** You cannot pass source attachment URLs to the target system. Once you decommission the source platform or the source CDN reference expires, those URLs break permanently.

**Required process:**
1. Download every attachment from the source system to local or intermediate storage
2. Validate file integrity (checksum before and after download)
3. Upload to the target system's storage endpoint
4. Rewrite the URL or file reference in the message body before final insertion

Skip this process and all historical images, documents, and PDFs are lost with no recovery path. For migrations involving compliance-sensitive attachments (contracts, support evidence, medical records), treat attachment migration as a separate validated pipeline stage, not an afterthought.

**Size limit conflicts:** If your source has attachments between 50MB and 100MB (above Zammad's limit but below Crisp's), you cannot directly import these into Zammad Cloud. Options: compress the file, store externally and reference by URL in the article body, or raise the limit on self-hosted Zammad.

### Common Migration Pitfalls

- **Conversation splitting logic.** The 14-day gap heuristic is a starting point. Analyze your actual message gap distribution (histogram of inter-message intervals per conversation) before choosing a threshold. The wrong threshold produces either thousands of single-article tickets (too aggressive) or monster tickets with hundreds of articles spanning years (too conservative).
- **Crisp message ceiling.** Crisp limits the total messages a single conversation can store to approximately 10,000 messages. If this limit is reached when inserting via the REST API, the API responds with HTTP 409 `"too_many_messages"`. When aggregating Zammad tickets into a single Crisp conversation, count articles before import — if the count exceeds 9,500, split into multiple Crisp conversations and link them with a system message.
- **Agent mapping.** Both platforms use internal numeric IDs for agents. Build a mapping table (source agent ID → target agent ID) before extraction and handle the case where an agent exists in the source but not in the target — assign to a default queue or flag for manual reassignment.
- **Timestamp preservation.** Both APIs support setting creation timestamps on import. In Crisp, the `timestamp` field on a message must be in milliseconds since epoch. In Zammad, `created_at` on an Article accepts ISO 8601. Test timestamp handling on a 10-record sample before running bulk import.
- **Rate limit planning.** Crisp's daily Plugin Quota and Zammad's 500 req/min Cloud limit require different throttling strategies. For Crisp bulk imports, implement a token-bucket throttle with a 24-hour budget, not a per-minute limiter. For Zammad, a per-minute sliding window suffices.

> [!TIP]
> **Migration timeline benchmarks:** For datasets under 10,000 tickets/conversations: 3–5 days end-to-end. For 10,000–50,000: 1–3 weeks. For 50,000+: add one week per additional 50,000 records for validation. The bottleneck is almost always data transformation and edge-case resolution — not raw API throughput. Attachment migration typically adds 30–50% to the total timeline on datasets with high attachment density.

## Feature Comparison Summary

| Feature | Crisp | Zammad |
|---------|-------|--------|
| **Pricing Model** | Per workspace (flat) | Per agent |
| **Self-Hosting** | ❌ SaaS only | ✅ AGPL, full source |
| **Open Source** | ❌ | ✅ (AGPLv3) |
| **Data Export on Cancellation** | API-only (no bulk UI export) | Full DB export (self-hosted) or API |
| **AI Features** | Hugo (credit-metered, Crisp-managed LLM) | 7.0+ (7 provider options, on-prem via Ollama) |
| **AI Pricing** | Bundled per plan (50 actions/day Essentials) | €0.03/call (one call = one invocation) |
| **Knowledge Base** | ✅ Essentials+ | ✅ Professional+ |
| **SLA Management** | ❌ | ✅ Professional+ |
| **CRM** | Built-in (flat key-value) | Organizations + Users (relational) |
| **Chatbot Builder** | ✅ Visual flow builder | ❌ (AI Agents handle routing) |
| **Video/Co-browsing** | ✅ | ❌ |
| **Telephony/CTI** | ❌ | ✅ (sipgate, CTI integrations) |
| **LDAP/Active Directory** | ❌ | ✅ |
| **SSO** | SAML (Enterprise only) | SAML + OpenID Connect |
| **White-labeling** | ✅ Plus+ | ✅ Self-hosted (CSS/branding) |
| **Audit Log** | Limited | ✅ Full ticket + AI action history |
| **Multi-brand** | Separate workspaces (separate billing) | Groups + channels (single instance) |
| **API Rate Limit** | Plugin Quota (daily, undisclosed ceiling) | 500 req/min (Cloud), configurable (self-hosted) |
| **Attachment Limit** | 100MB/file | 50MB/file (Cloud), configurable (self-hosted) |
| **Starter Plan Agent Cap** | N/A | 5 agents (platform-enforced) |

## When to Pick Crisp

- **You're an SMB with ≤10 agents** and want flat-rate pricing without per-seat math at Essentials or below
- **Live chat is your primary channel** — Crisp's chat widget, co-browsing, and video chat have no equivalent in Zammad
- **You don't want to manage infrastructure** — SaaS-only means zero ops overhead
- **Social and messaging channels matter** — Instagram DMs, WhatsApp, and Messenger work natively; Zammad supports none of Instagram
- **You want lightweight built-in CRM** — flat but functional contact management for simpler B2C workflows

## When to Pick Zammad

- **Data sovereignty is non-negotiable** — self-host in your own data center or cloud; Crisp has no self-hosting path
- **You're scaling past 15–20 agents** — per-agent pricing stays linear; Crisp's plan-jump cliff hits at 11 agents
- **You need ticket-based workflows** — SLA escalation, formal state machines, parent/child ticket relationships
- **IT service management is your use case** — monitoring tool integrations (Nagios, Zabbix, Grafana), CTI, GitHub/GitLab issue linking
- **You want to choose your own AI model** — bring OpenAI, Anthropic, Mistral, or run fully on-prem via Ollama
- **You're in a regulated industry** — financial services, healthcare, government, or critical infrastructure where LLM data residency matters

## The Decision Framework

Three questions determine the correct answer for most teams:

**1. Do you need to own your data or control where AI inference runs?**
If yes to either, Zammad is the only option here. Crisp has no self-hosting path, and its LLM is vendor-managed with no model visibility.

**2. What is your primary support channel and interaction model?**
Live chat and social messaging → Crisp's architecture is natively optimized. Email-heavy ticketing with formal SLAs, routing rules, and multi-group assignment → Zammad's ticket lifecycle model is the correct fit.

**3. How many agents, and where is your growth trajectory?**
Under 10 agents with stable headcount → Crisp Essentials (€95/mo flat) is hard to beat. 11+ agents or scaling toward 20+ → Zammad's per-agent linear pricing avoids the 3× plan-jump cliff. At 20 agents, Zammad Professional Cloud (€340/mo) and Crisp Plus (€295/mo) are within 15% of each other — the decision at that scale should be driven by data sovereignty and workflow fit, not cost.

The expensive mistake is picking the wrong architectural model and spending six months forcing it to work before migrating.

If you're evaluating both platforms, our [pre-migration guide](https://clonepartner.com/blog/blog/how-to-choose-right-helpdesk/) walks through the full evaluation process. For comparisons against enterprise incumbents, see our [Zammad to Zendesk migration guide](https://clonepartner.com/blog/blog/zammad-to-zendesk-migration-the-technical-guide/).

> Planning a move between Crisp and Zammad? ClonePartner's engineering team handles API extraction, data model transformation, and attachment migration pipelines. Book a 30-minute technical scoping call.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### Can I self-host Crisp on my own servers?

No. Crisp is strictly a cloud-based SaaS platform with no self-hosted edition. If you require on-premise hosting for data sovereignty or compliance, Zammad is the better choice — it's fully open-source under AGPLv3.

### Is Zammad really free to self-host?

The license is free under AGPLv3, but self-hosting requires Elasticsearch, PostgreSQL, Redis, and Ruby on Rails — four services to maintain. Real-world infrastructure plus admin costs run €345–€810/month before you count staff time. Free to license is not free to run.

### Can I migrate data from Crisp to Zammad (or vice versa)?

There is no native import/export between the two platforms. Migration requires custom scripting against both REST APIs. Crisp conversations must be extracted via API (no bulk CSV export for chat history), transformed into Zammad's ticket-article model (or vice versa), and loaded via the target API. Expect 1–3 weeks for datasets under 50K records.

### Which is cheaper — Crisp or Zammad for a 10-person team?

Crisp Essentials at €95/month covers 10 agents for €1,140/year. Zammad Professional Cloud at €17/agent costs €170/month or €2,040/year for 10 agents. Crisp is cheaper at this scale. Self-hosted Zammad can undercut both if you already have the infrastructure and engineering staff.

### Does Zammad support AI features like Crisp's Hugo?

Yes. Zammad 7.0 (March 2026) introduced Ticket Summary, Writing Assistant, and AI Agents. Unlike Crisp's Hugo, which uses Crisp-managed credits, Zammad lets you choose your LLM — including OpenAI, Anthropic, Mistral, or a fully self-hosted model via Ollama. AI calls cost €0.03 each on the hosted plan.