---
title: "Zammad vs Helpshift: Architecture, TCO & Migration Guide"
slug: zammad-vs-helpshift-architecture-tco-migration-guide
date: 2026-08-13
author: Rishabh
categories: [Help Desk, Migration Guide]
excerpt: "Zammad is an open-source, ticket-first helpdesk priced per agent. Helpshift is a mobile-first platform priced per issue. Compare architecture, TCO, APIs, and migration paths."
tldr: Pick Zammad for self-hosted data sovereignty and per-agent economics. Pick Helpshift for mobile SDK-level in-app support and issue-based pricing. Migration requires custom API scripting.
canonical: https://clonepartner.com/blog/zammad-vs-helpshift-architecture-tco-migration-guide/
---

# Zammad vs Helpshift: Architecture, TCO & Migration Guide


# Zammad vs Helpshift: Architecture, TCO & Migration Guide

> [!NOTE]
> **TL;DR — Zammad vs Helpshift**
>
> Zammad is an open-source, ticket-first helpdesk priced per agent (€7–€25/agent/mo hosted, or free to self-host under AGPL). Helpshift is a mobile-first, SDK-driven support platform priced per issue ($150/mo base for 250 issues, with consumption-based overages at $0.45/issue). **Pick Zammad** if you need data sovereignty, self-hosting, and email/web-centric support. **Pick Helpshift** if your product is a mobile app or game and you need native in-app messaging, device-level context, and bot-driven automation at scale. There is no native migration tool between these platforms — every production migration requires custom API scripting.
>
> *Disclosure: ClonePartner builds migration pipelines between helpdesk platforms. This guide reflects real technical constraints from building those pipelines. Draw your own conclusions.*

Teams comparing Zammad and Helpshift are almost always facing a fundamental architectural fork: **ticket-centric, infrastructure-controlled support** versus **mobile-native, issue-based support at scale**. These platforms share almost no overlap in their ideal customer profiles, but land on the same shortlist when a company is rearchitecting its support stack — especially when migrating away from a general-purpose tool like Zendesk or Freshdesk.

If your support volume is primarily email, web forms, and phone — and you care about hosting your own data — Zammad is purpose-built for that. If your customers interact with you inside a mobile app or game and you need SDK-level device metadata, bot deflection, and asynchronous messaging, Helpshift occupies that niche.

This guide covers the architecture differences, real pricing math, API constraints, and the exact migration path in both directions.

## Quick Decision Framework

```text
Is your core product a mobile app or game?
├── YES → Do you need in-app SDK support with device context?
│   ├── YES → Helpshift. Native SDKs and device metadata are its core strength.
│   └── NO → Do you need self-hosted infrastructure or data sovereignty?
│       ├── YES → Zammad (self-hosted)
│       └── NO → Evaluate both; Helpshift for scale, Zammad for cost control.
└── NO → Is your support primarily email, web forms, and phone?
    ├── YES → Zammad. Ticket-first model fits perfectly.
    └── NO → Neither may be the right fit. Evaluate general-purpose platforms.
```

**Five-question decision checklist:**

| Question | YES → | NO → |
|----------|-------|------|
| Is your primary support channel a mobile app or game? | Helpshift | Continue |
| Do you require self-hosted infrastructure or data sovereignty? | Zammad | Continue |
| Does your team handle >10,000 issues/month with >70% bot deflection target? | Helpshift consumption model | Continue |
| Is your agent count >20 and issue volume relatively low (<5,000/mo)? | Zammad per-agent model | Continue |
| Do you need to integrate device metadata (OS, app version, carrier) automatically? | Helpshift | Zammad |

## Architecture: Ticket-First vs. Issue-First

To understand the migration complexity — and to make the right platform choice — you need to understand how each system structures its data.

### Zammad: Open-Source Ticket System

**Zammad** is an open-source customer support and ticketing system built on Ruby on Rails. Its data model centers on **tickets** containing **articles** — discrete message records (customer replies, agent responses, internal notes) attached to a ticket object. Each ticket belongs to a group, has a state, priority, and owner, and can carry custom object attributes. A ticket itself contains almost no text payload; it acts as a container for state and metadata. The actual communication happens inside articles.

The architecture follows an "API First" principle. The web UI is a JavaScript client consuming the same REST API available to external integrations. Anything you can do in the UI, you can automate via API — a meaningful advantage for migration and integration work.

In production, Zammad requires **PostgreSQL 13+** and **Redis 6+**. Elasticsearch is technically optional but strongly recommended — it powers full-text search, reporting features, and attachment content indexing. Official minimum sizing starts at **2 CPU cores and 6 GB RAM**, plus **4 GB more** if Elasticsearch runs on the same machine. Zammad's own example setup for up to 40 agents is **6 CPU cores and 6 GB RAM**, plus **6 GB** for Elasticsearch. ([docs.zammad.org](https://docs.zammad.org/en/latest/prerequisites/software.html?highlight=socket))

Key architectural traits:

- **Deployment:** Self-hosted (Docker, package, source) or Zammad-hosted cloud. Self-hosting is license-free under AGPL.
- **Search:** Elasticsearch-backed full-text search across tickets, articles, and attachment metadata.
- **Identity:** LDAP, Active Directory, and OpenID Connect (since 6.5) out of the box.
- **Knowledge Base:** Built-in, with multi-language support, draft/staff/public visibility, and scheduled publishing.
- **Webhooks:** HTTP webhooks fire on ticket create/update events, carrying a full ticket JSON payload. Configurable per trigger, supporting real-time integration patterns and cutover event streaming during migrations.
- **AI (since 7.0):** Ticket summaries, writing assistant, AI-powered routing and categorization. You choose the LLM — Zammad AI, OpenAI, Anthropic, Azure AI, Mistral, Ollama, or any custom OpenAI-compatible endpoint. ([zammad.com](https://zammad.com/en/company/open-source))
- **Email Parsing:** Handles complex MIME types, nested email quotes, and inline attachments well.

> [!NOTE]
> **Zammad 7.0 breaking changes:** MySQL support was removed (PostgreSQL-only going forward). Elasticsearch index must be rebuilt after upgrade. Slack integration was removed. Verify the [BREAKING_CHANGES.md](https://github.com/zammad/zammad/blob/develop/BREAKING_CHANGES.md) before upgrading.

### Helpshift: Mobile-Native Issue Platform

**Helpshift** is a mobile-first customer service platform — currently positioned as an AI-native player engagement platform for games, spanning support, engagement, trust & safety, and community. ([helpshift.com](https://www.helpshift.com/))

Its data model is built around **issues** — Helpshift's term for a support conversation initiated by a user. Each issue carries rich device metadata (OS version, app version, carrier, device model) captured automatically via the SDK. Messages flow as a continuous thread rather than discrete articles, rendering historical interactions like iMessage or WhatsApp.

The defining architectural trait is the **App** object. Every issue must be associated with a specific App (e.g., "iOS Client", "Android Client"). Helpshift's core differentiator is its **native SDK integration**: the iOS and Android SDKs embed directly into your app binary, providing in-app messaging, FAQ search, and bot flows without the user ever leaving the app. Developer docs expose SDKs for **Android, iOS, Unity, Unreal Engine, React Native, Cocos2d-x, and Xamarin**, plus **Web Chat** and **PC/console** support via webview or QR-code handoff flows. ([helpshift.com](https://www.helpshift.com/platform/tech/))

Key architectural traits:

- **Deployment:** SaaS-only. No self-hosted option. Production data hosted on AWS. Published DPA references ISO 27001, SOC 2 Type II, and HIPAA controls.
- **SDK:** Native iOS (SDK X), Android (SDK X), Unity, Unreal Engine, and more. Embeds in-app messaging UI, FAQ display, and bot flows.
- **Bot Automation:** AI agents and custom bots handle initial triage. Helpshift claims bots can automate up to 90% of user issues.
- **Channels:** In-app messaging, web chat, email, Discord (for gaming). No native phone/voice channel.
- **Integrations:** Salesforce, Slack, Zendesk (for handoff), Jira, and custom webhook endpoints — relevant when Helpshift sits alongside existing CRM or ticketing infrastructure.
- **Translation:** Proprietary machine translation built into the agent console.
- **Proactive Engagement:** Push notifications and in-app campaigns via the same SDK.
- **Smart FAQs:** AI-powered FAQ search within the SDK surfaces relevant articles before a user submits an issue, functioning as a deflection layer distinct from Zammad's knowledge base (which is agent- and web-facing, not embedded in a product UI).
- **Data Retention:** Helpshift does not publish a universal retention period; enterprise contracts specify retention windows. Data deletion requests via GDPR portability APIs are processed in weekly batches — not suitable for real-time compliance workflows.

### Why These Models Feel Different in Operations

Zammad feels like a ticket desk with channels attached. Helpshift feels like support embedded inside the product experience. Zammad's feature set centers on helpdesk primitives — groups, SLAs, knowledge base, webhooks, GitHub/GitLab links, and classic agent workflows. Helpshift's surface area centers on in-game support, searchable FAQs, escalation from AI to humans, persistent player context, and cross-platform app support.

Self-hosted Zammad is never just "free software." You own upgrade planning, database health, Redis, search, monitoring, and any high-availability design you need. For some teams that is a feature. For others it is the cost center that kills the deal.

With Helpshift, you do far less server care, but you do more client integration work: SDK rollout, identity mapping, metadata tracking, and release coordination with app teams.

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

Zammad and Helpshift use fundamentally different pricing models, and the TCO math changes dramatically depending on your team size and issue volume.

### Zammad Pricing

Zammad's hosted pricing is unusually transparent. ([zammad.com](https://zammad.com/en/pricing/table))

| Plan | Price | Key Constraints |
|------|-------|----------------|
| **Starter** | €7/agent/mo | Max 5 agents. Email and web forms only. No chat, no SLA tracking. |
| **Professional** | €16/agent/mo | Adds chat, SLA management, custom objects. Max 35 agents. |
| **Plus** | €25/agent/mo | WhatsApp, Facebook channels. Full feature set. Unlimited agents. |
| **AI Add-on** | €0.03/AI call | Available on all tiers. Choose your LLM. |
| **Self-hosted** | €0 license | AGPL-3.0. Infrastructure costs vary by provider and configuration. |

The details matter: **Chat** and **Telegram** start at Professional. **Facebook Pages** and **WhatsApp** appear only on Plus. Hosted attachment limits are **10 MB**, **35 MB**, and **50 MB** per tier, with total storage of **20 GB**, **50 GB**, and **150 GB**. ([zammad.com](https://zammad.com/en/pricing/table))

**TCO example — 10 agents on Professional (hosted):** €160/mo (€1,920/yr). Add AI at moderate usage (500 calls/mo): €15/mo. Total: ~€2,100/yr. No infrastructure, no ops labor.

**Self-hosted TCO — 10 agents:** No license fee, but infrastructure is a real cost. A representative self-hosted deployment requires:
- **Application server:** 4 vCPU / 8 GB RAM VPS (e.g., Hetzner CX41 at ~€20/mo, or comparable AWS/GCP instance at ~€60–80/mo)
- **Managed PostgreSQL:** (e.g., Hetzner managed DB, ~€20/mo; AWS RDS db.t3.medium, ~€55/mo)
- **Redis:** Shared or managed (~€5–15/mo)
- **Elasticsearch node:** 4 GB RAM minimum (e.g., Elastic Cloud Starter ~€50/mo, or self-managed on same host to reduce cost)
- **Total infrastructure:** ~€95–220/mo (budget provider) to €230–450/mo (AWS/GCP-equivalent managed services)
- **Admin labor:** 4–8 hrs/mo at €50–100/hr = €200–800/mo
- **Optional vendor support:** €2,999/yr (15 support requests) = ~€250/mo

Realistic self-hosted TCO for 10 agents: **€6,000–18,000/yr** depending on infrastructure choices, cloud provider, and whether you need vendor support. The lower end assumes a budget VPS provider with in-house Linux admin skills; the upper end assumes managed cloud services and vendor support contract.

> [!WARNING]
> **Zammad's tier gating is significant.** WhatsApp and Facebook channels are only available on the Plus tier (€25/agent/mo). If you need social messaging, budget for Plus from day one.

### Helpshift Pricing

Helpshift's main pricing page does **not** present fixed public plans. It says pricing is **solution-based and modular**, driven by interaction volume, solutions activated, capabilities used, and geography/language coverage. An official pricing page states pricing can start at **$150/month and $0.45 per issue**. Read that as a buying signal: public price points exist as a floor, but a real budget requires a scoped quote. ([helpshift.com](https://www.helpshift.com/pricing/))

| Plan | Base Price | Issues Included | Overage |
|------|-----------|----------------|--------|
| **Starter** | $150/mo | 250 issues/mo | $0.45/issue |
| **Growth** | Custom | Custom | Negotiated |
| **Enterprise** | Custom | Custom | Negotiated |

Helpshift uses **issue-based (consumption) pricing**. An "issue" is any customer conversation directed to an agent or bot — not a resolution. A bot interaction that doesn't resolve anything still counts as a billable issue.

**TCO example — 2,000 issues/mo on Starter:** 250 included + 1,750 × $0.45 = $937.50/mo ($11,250/yr). At this volume, negotiating a Growth plan is expected and pricing typically improves significantly with volume commitments.

**Hidden costs:** SDK integration requires mobile engineering resources. Every time you update your iOS or Android app, your engineering team must verify SDK compatibility, handle push notification certificates, and map custom user properties. A first-time SDK integration typically takes 1–3 engineering sprints depending on app complexity.

> [!TIP]
> **Key pricing insight:** Zammad's cost scales with agent headcount. Helpshift's cost scales with issue volume. A 50-agent team handling 500 issues/month will find Zammad far cheaper. A 5-agent team handling 50,000 in-app issues (mostly bot-deflected) will find Helpshift's model more efficient — assuming negotiated volume discounts reduce the per-issue rate materially below $0.45.

### TCO Comparison Table (Annual Estimates)

| Scenario | Zammad (Cloud, Professional) | Helpshift |
|----------|------------------------------|----------|
| 5 agents, 500 issues/mo | ~€1,560 (~$1,700) | ~$3,150 (Starter + overages) |
| 10 agents, 2,000 issues/mo | ~€1,920 (~$2,100) | ~$11,250+ (Starter) or negotiated |
| 10 agents, 20,000 issues/mo | ~€1,920 (~$2,100) | ~$36,000–$72,000 (negotiated) |
| 50 agents, 50,000 issues/mo | ~€9,600 (~$10,500) | Custom Enterprise pricing |

*Helpshift costs above 250 issues/mo are estimates based on published Starter overage rate. Volume discounts at Growth/Enterprise tiers are negotiated and not publicly documented.*

> [!WARNING]
> If your spreadsheet models Zammad as "free" and Helpshift as "expensive SaaS," it is probably wrong in both directions. Zammad brings PostgreSQL, Redis, and usually Elasticsearch into the picture, plus upgrades and ops labor. Helpshift pushes more cost into vendor-managed scope and usage tiers. Compare **full operating cost**, not just subscription lines.

## Feature Comparison

| Capability | Zammad | Helpshift |
|-----------|--------|----------|
| **Deployment** | Self-hosted or cloud | SaaS only |
| **Data model** | Tickets → Articles | Issues → Messages |
| **Primary channels** | Email, web, chat, phone, social (Plus) | In-app SDK, web chat, email, Discord |
| **Mobile SDK** | None (responsive web only) | Native iOS/Android/Unity/Unreal/React Native/Cocos2d-x/Xamarin |
| **Bot automation** | AI agents (since 7.0) for routing/categorization | Full conversational bots, up to 90% deflection claimed |
| **AI features** | LLM-agnostic: summaries, writing assist, routing | Proprietary AI: Smart Intents, Smart FAQs, translation, classification |
| **LLM choice** | 7+ providers + custom OpenAI-compatible endpoint | Proprietary only |
| **Knowledge base** | Built-in web/agent-facing, multi-language | In-app FAQs via SDK + web help center; Smart FAQ surfaces articles before issue submission |
| **SLA management** | Professional tier and above; configurable escalation and reminders | Available; plan-dependent — SLA configuration details require direct vendor confirmation |
| **Webhooks** | Yes — trigger-based, full ticket JSON payload | Yes — configurable webhook endpoints for issue events |
| **LDAP/SSO** | LDAP, AD, OpenID Connect (since 6.5) | SAML-based SSO |
| **CRM/Integrations** | GitHub, GitLab, Slack (removed in 7.0), Zapier | Salesforce, Slack, Zendesk handoff, Jira, custom webhooks |
| **Self-hosting** | Yes (AGPL-3.0) | No |
| **GDPR/data sovereignty** | Full control (self-hosted + local LLM via Ollama) | SaaS-dependent; GDPR deletion requests processed weekly |
| **Device metadata** | None | Automatic via SDK (OS, carrier, model, app version) |
| **Console support** | Not applicable | QR code handoff to mobile; PC/console via webview |
| **Storage limits (cloud)** | 20 GB / 50 GB / 150 GB by tier | Not publicly documented; enterprise contract-dependent |

### When Zammad Wins

- **Data sovereignty requirements.** Self-hosted Zammad with a local LLM (via Ollama) means zero data leaves your network. This matters for EU public sector, healthcare, and finance.
- **Agent-count-sensitive budgets.** At €16/agent/mo (Professional), a 20-agent team costs €3,840/yr. Hard to beat on pure subscription cost.
- **Email-heavy support operations.** Zammad's email parsing, SLA tracking, and trigger automation are mature and well-documented.
- **Open-source flexibility.** AGPL license means you can inspect, modify, and audit every line. No vendor lock-in on the codebase.
- **Pricing you can model before procurement.** Zammad's hosted and self-hosted pricing is public. No sales call required. ([zammad.com](https://zammad.com/en/pricing/table))
- **Real-time integration patterns.** Webhook system fires on ticket events, enabling live integration without polling.

### When Helpshift Wins

- **Mobile apps and games.** No comparable platform matches Helpshift's SDK-level integration for in-app support across iOS, Android, Unity, and Unreal Engine.
- **High-volume, bot-first operations.** If 80%+ of your issues can be bot-deflected, consumption pricing can be cheaper than per-agent models at scale.
- **Device context matters.** Automatic metadata capture eliminates back-and-forth troubleshooting on OS version, app version, and device model.
- **Gaming-specific features.** Console-to-mobile handoff, Discord integration, Unity SDK — purpose-built for the gaming industry.
- **High automation targets.** Helpshift case studies report Trailmix reached 79% FAQ deflection and 93% automation. These are vendor case studies, not neutral benchmarks, but they illustrate the workflow Helpshift is designed to support. ([helpshift.com](https://www.helpshift.com/customers/trailmix/))
- **Existing Salesforce or Jira workflows.** Helpshift's native integrations reduce the middleware burden if your support team already lives in those tools.

## API Constraints for Migration

Both platforms expose REST APIs, but their design philosophies and practical constraints differ. Understanding these before scripting any migration is essential.

### Zammad REST API

- **Authentication:** HTTP Basic Auth, API tokens, or OAuth2.
- **API-first design:** Every UI action has an API equivalent. Tickets, articles, users, organizations, groups, tags, knowledge base — all accessible.
- **Pagination:** `page` and `per_page` query parameters. Default returns up to 100 objects per page. A server-side configurable maximum (~500) caps the total returned even if you request more.
- **Ticket articles:** Each ticket's messages are separate article objects fetched via `/api/v1/ticket_articles/by_ticket/{ticket_id}`.
- **Attachments:** Fetched per article via the article's `attachments` array, each with a downloadable content endpoint.
- **Webhooks:** Configurable via Admin → Triggers. Fire on ticket create/update with full JSON payload. Useful for real-time delta-sync during migration cutover windows.
- **Official clients:** PHP and Ruby. Community clients exist for Python and others.
- **Native migrators:** Only support inbound migrations from Freshdesk, Kayako, OTRS, and Zendesk (moving the other direction requires custom API scripting, as detailed in our [Zammad to Zendesk migration guide](https://clonepartner.com/blog/blog/zammad-to-zendesk-migration-the-technical-guide/)) — and those run only on new instances, from one source only, as all-or-nothing operations. Helpshift is not listed. ([docs.zammad.org](https://docs.zammad.org/en/latest/migration/index.html))

> [!WARNING]
> **Zammad KB search pagination bug (fixed in 5.0):** In older versions, the knowledge base search endpoint ignored `page` and `per_page` parameters entirely. If you're on a pre-5.0 self-hosted instance, you'll need to work around this by fetching KB articles via the admin API rather than the search endpoint.

### Helpshift REST API

- **Authentication:** API key-based (manage keys in Settings → APIs). Separate read-only and write-only keys available. Requires the integrations feature enabled and the domain's default API key. ([support.helpshift.com](https://support.helpshift.com/hc/pt/13-helpshift-technical-support/faq/769-in-app-support-guide-api-key-management/))
- **Pagination:** 100 issues per page by default, configurable via `page-size` parameter. Maximum 1,000 issues per API call. **Hard cap of 100 pages per paginated query.** Pagination info returned in the `Link` header.
- **Rate limits:** Per-API-key, managed in the dashboard. Helpshift does not publish a universal numeric rate limit in public documentation — the specific threshold is set per account. Before building a high-volume migration pipeline, submit a controlled test burst (e.g., 200 sequential requests) and observe 429 response headers to empirically determine your account's limit. Document this before writing retry logic.
- **Core endpoints:** Issues (read/write/create), Web Messenger, FAQs, FAQ Sections. Read-only access to Agents, users, and applications.
- **Bulk APIs:** User Hub Bulk APIs support async import/export of end-user profiles, with a 10,000-payload limit per request. Larger uploads should use JSONL format. ([developers.helpshift.com](https://developers.helpshift.com/rest-api/user-hub-bulk-apis/))
- **Issue messages:** Messages are nested within the issue response — no secondary API call required to retrieve conversation history, unlike Zammad.
- **Custom issue fields:** Support only date, checkbox, drop-down, single-line text, multi-line text, and number. Dates must be Unix milliseconds. Invalid keys or type mismatches are **silently dropped** — no error is returned, the field is simply absent in the saved record. ([support.helpshift.com](https://support.helpshift.com/hc/en/13-helpshift-technical-support/faq/1144-apis-how-do-i-use-the-rest-api-to-update-custom-issue-fields-when-a-new-message-is-received-from-a-user/))

> [!WARNING]
> **Helpshift's 100-page pagination cap** is the most common gotcha in large exports. At 1,000 issues/call × 100 pages, you can retrieve at most 100,000 issues per unfiltered query. If you have more than 100,000 issues, you must use date-range filters (`created_since` / `created_before`) to partition your export into smaller windows. Failing to account for this results in silently incomplete data with no error — the API simply stops paginating at page 100.

## Migration Path: Zammad ↔ Helpshift

There is no native migration tool, no vendor connector, and no shared import/export format between Zammad and Helpshift. Every production migration requires custom API scripting.

### Object Mapping

| Zammad Object | Helpshift Equivalent | Notes |
|--------------|---------------------|-------|
| Ticket | Issue | 1:1 mapping. Ticket metadata (priority, state) maps to issue custom fields. |
| Article (customer reply) | Inbound message | Timestamps must be preserved. |
| Article (agent reply) | Outbound message | |
| Article (internal note) | Internal note / custom metadata | Helpshift's internal note support is more limited than Zammad's — decide upfront whether to migrate, tag, or skip. |
| Organization | No direct equivalent | Flatten to user-level metadata or custom fields. No Organization object exists in Helpshift. |
| User (customer) | End User / Core Profile | Map email/name. Device metadata won't exist on migrated records. |
| User (agent) | Agent | Manual setup or Bulk API. |
| Tags | Tags | Direct mapping. |
| Knowledge Base article | FAQ | Restructure into FAQ sections. Helpshift's bulk FAQ import does **not** create new FAQs — only updates existing ones. ([support.helpshift.com](https://support.helpshift.com/hc/en/13-helpshift-technical-support/faq/1013-faq-management-how-do-i-bulk-edit-update-faqs/)) |
| Attachments | Attachments | Download from Zammad, upload to Helpshift per message. Check MIME type and size limits before transfer. |
| Custom object attributes | Custom Issue Fields | Helpshift CIFs support only 6 types: date, checkbox, drop-down, single-line text, multi-line text, number. Type mismatches are silently dropped. |

When extracting a ticket from Zammad, the JSON payload contains metadata but no message text:

```json
{
  "id": 1045,
  "group_id": 2,
  "priority_id": 2,
  "state_id": 4,
  "title": "Login failure on production",
  "customer_id": 501
}
```

You must make a secondary call to `/api/v1/ticket_articles/by_ticket/1045` to retrieve the conversation thread. To load this into Helpshift, you collapse the initial Zammad article into the `message-body` of a new Issue, and subsequent articles become Messages or Private Notes:

```json
{
  "title": "Login failure on production",
  "message-body": "I cannot log into the web portal...",
  "app-publish-id": "app_123456789",
  "author-email": "user@example.com",
  "custom_fields": "{\"zammad_id\": \"1045\"}"
}
```

Note the mandatory `app-publish-id` — every Helpshift issue must be associated with a specific App. If your Zammad data comes from multiple channels, you'll need to decide which Helpshift App each ticket maps to before you begin loading.

### The HTML vs. Chat UI Collision

This is the most common failure mode in Zammad → Helpshift migrations.

Zammad stores incoming emails as rich HTML. Extract a Zammad article and you will pull `<table>`, `<div>`, inline styles, and nested blockquotes. Helpshift is a chat interface. Push raw HTML into a Helpshift message and it will either render as raw code or break the mobile UI.

**The fix:** Your migration middleware must strip HTML, convert `<br>` tags to newline characters (`\n`), and extract links into a readable format before pushing to Helpshift. A simple regex pass is insufficient for deeply nested HTML with inline styles — use a proper HTML-to-text library (e.g., `html2text` in Python or `sanitize-html` in Node.js) and test against a representative sample of your actual Zammad articles before running the full migration.

### Handling Attachments

Zammad allows large files (up to 50 MB depending on tier and server config). Helpshift has stricter MIME type restrictions and smaller file size limits.

To migrate attachments:

1. Download the file via Zammad's API (`/api/v1/ticket_attachment/{ticket_id}/{article_id}/{attachment_id}`).
2. Check the file size and MIME type against Helpshift's allowed list.
3. Upload to Helpshift via a `multipart/form-data` POST request.
4. If the file is rejected (wrong MIME type, oversized), upload it to a secure external bucket (e.g., S3) and append a link as a private note in the Helpshift issue.

For large attachment volumes, implement retry logic with exponential backoff — transfer speed and timeout behavior differ between the APIs.

### Zammad → Helpshift: Step-by-Step

1. **Audit and map custom fields.** Identify all custom attributes in Zammad and create corresponding Custom Issue Fields in Helpshift before importing. Remember: Helpshift CIFs support only date, checkbox, drop-down, single-line text, multi-line text, and number types. Any Zammad attribute outside these types must be converted or dropped.
2. **Determine App mapping.** Every Helpshift issue requires an `app-publish-id`. Decide which Zammad groups or channels map to which Helpshift Apps before writing your loader.
3. **Extract from Zammad.** Paginate through `/api/v1/tickets` and `/api/v1/ticket_articles/by_ticket/{id}`. Download all attachments. Export users and organizations.
4. **Transform.** Convert Zammad's ticket→article model to Helpshift's issue→message model. Flatten organizations to user-level metadata. Strip HTML from email articles using a proper parser, not regex.
5. **Load to Helpshift.** Push to the Issues API. Use Bulk APIs for end-user profiles (max 10,000 per request, JSONL for larger sets). Coordinate with your Helpshift Account Manager for high-volume imports — Helpshift may apply server-side throttling on bulk operations.
6. **Migrate knowledge base.** Export Zammad KB articles, restructure into Helpshift FAQ sections. Create FAQ section structures manually first — bulk import only updates existing FAQs, it does not create new ones.
7. **Validate.** Spot-check timestamps, attachment integrity, and message ordering. Verify agent assignments. Confirm custom field values were not silently dropped due to type mismatches.

### Helpshift → Zammad: Step-by-Step

1. **Extract from Helpshift.** Paginate through the Issues API (max 1,000 issues/call, up to 100 pages per query). Use `created_since` / `created_before` date-range filters to batch large datasets past the 100-page cap. Empirically verify your rate limit before running at full speed.
2. **Extract user data.** Use the User Hub Bulk Export API for end-user profiles.
3. **Transform.** Convert Helpshift's issue→message model to Zammad's ticket→article model. Note that Helpshift messages are nested in the issue response — no secondary call needed. Map device metadata to Zammad custom object attributes (create these in Zammad admin before importing).
4. **Load to Zammad.** Use the REST API to create tickets, then create articles within each ticket. Zammad's API-first design makes this straightforward — every field settable in the UI is settable via API.
5. **Configure webhooks for delta-sync.** Set up Helpshift webhooks to fire on new issue events during the cutover window. Stream these to your migration pipeline to capture open work created after your initial extract.
6. **Migrate FAQs.** Export Helpshift FAQs, restructure into Zammad knowledge base categories and articles.
7. **Validate.** Verify pagination completeness — run a count of issues extracted against the total reported by the Issues API. Helpshift's 100-page cap means you may have missed records if date-range batching was not correctly implemented.

### The Practical Cutover Pattern

The safer pattern is to migrate **historical closed records first**, preserve **legacy IDs** in custom fields (e.g., `zammad_id` or `helpshift_issue_id`), then **delta-sync open work** before final cutover. Zammad's webhook system and Helpshift's webhook endpoints both support event streaming that can drive a real-time delta-sync during the cutover window. Keep the source platform in read-only mode for audit and attachment backfill.

**Behavioral parity** — not pixel-perfect sameness — is the right migration target. Between Zammad's ticket/article model and Helpshift's issue/message model, the passing criteria are: searchable history, correct timestamps, intact attachments, preserved internal/public visibility, stable legacy IDs for reconciliation, and agent assignment accuracy. Anything that fails one of these five criteria should be flagged before go-live, not discovered during the first agent shift on the new platform.

> [!TIP]
> **Cutover validation checklist:** (1) Random-sample 50 migrated records and verify timestamps match source. (2) Confirm all attachments resolve — download a sample. (3) Verify internal notes retained correct visibility. (4) Confirm legacy IDs are searchable in custom fields. (5) Run a count comparison: source record count vs. destination record count. A variance >1% warrants investigation before go-live.

## Edge Cases That Trip Up Migrations

- **Zammad internal notes → Helpshift.** Zammad supports rich internal notes as first-class article objects. Helpshift's internal note support is more limited. Decide upfront whether to migrate these as metadata, tags, or skip them — a post-hoc decision here requires re-processing the full dataset.
- **Helpshift device metadata → Zammad.** Device context (OS, carrier, model, app version) doesn't exist in Zammad's default schema. Create custom object attributes in Zammad admin before migration begins to preserve this data.
- **Organization hierarchy.** Zammad has a proper Organization object with primary/secondary user assignments. Helpshift has no equivalent — organization context must be flattened into user-level custom fields. If reporting by organization is critical, plan this mapping before extraction begins.
- **Timestamp fidelity.** Both platforms support setting timestamps on import. Zammad stores UTC internally; Helpshift timestamps are also UTC but display formatting varies by SDK locale. Verify your target platform renders migrated timestamps correctly in the agent UI.
- **Helpshift GDPR portability APIs are not migration tools.** Those requests are processed in weekly batches, making them unsuitable for cutover-window data movement. Use the Issues API for real-time export.
- **Helpshift dashboard CSV export caps at 10,000 issues** and does not include full message body text. Use the Get Issues API for complete data — the CSV is adequate for reporting, not for migration. ([support.helpshift.com](https://support.helpshift.com/hc/pt-br/13-helpshift-technical-support/faq/1304-issue-management-export-issues-as-csv/))
- **Helpshift custom field silent drops.** Invalid field keys or type mismatches are silently dropped with no API error. Build a post-load validation step that reads back a sample of records and compares field values against what was sent.
- **Zammad LDAP sync behavior.** Zammad's LDAP sync runs on a configurable schedule (default: at login). It does not continuously sync group memberships in real-time — plan for a manual sync trigger or schedule adjustment if agent group assignments change during migration cutover.

## Who Should Not Pick Either Platform

Neither Zammad nor Helpshift is a general-purpose helpdesk. Be honest about the fit:

- **If you need strong e-commerce integrations** (Shopify, WooCommerce order lookup in tickets), look at Gorgias or Zendesk.
- **If you want flat-rate pricing with unlimited agents,** consider platforms like Crisp. See our [Crisp vs Zammad comparison](https://clonepartner.com/blog/blog/crisp-vs-zammad-architecture-tco-migration-guide/).
- **If your CRM is the center of your support workflow** (Keap, ActiveCampaign), look at CRM-native tools like FuseDesk. See our [FuseDesk vs Helpshift guide](https://clonepartner.com/blog/blog/fusedesk-vs-helpshift-2026-architecture-tco-migration-guide/).
- **If you need enterprise ITSM** (change management, CMDB, SLA hierarchies), neither platform is built for that. Evaluate ServiceNow or Jira Service Management.

## Making the Call

Zammad and Helpshift are purpose-built for different operational realities. The decision is not about features-per-dollar — it is about whether your support model is **infrastructure-controlled and agent-centric** (Zammad) or **mobile-native and volume-driven** (Helpshift).

**Use this final decision map:**

| Your situation | Recommended platform | Key reason |
|---------------|---------------------|-----------|
| B2B SaaS, 10–50 agents, email-primary, GDPR-sensitive | Zammad (self-hosted) | Data sovereignty + predictable per-agent cost |
| B2B SaaS, 10–50 agents, email-primary, no hosting preference | Zammad (cloud, Professional) | €16/agent/mo, no infra overhead |
| Mobile game or consumer app, in-app support required | Helpshift | SDK-level integration, device context, bot deflection |
| High-volume consumer product, >70% bot-deflection target | Helpshift | Consumption pricing efficient at scale with volume discounts |
| Mixed-channel operation needing Salesforce integration | Helpshift | Native Salesforce connector reduces middleware complexity |
| Need to audit or modify support platform source code | Zammad (self-hosted) | AGPL license, full codebase access |

The worst outcome is picking either platform for the wrong job. Be honest about your channel mix, volume profile, and infrastructure preferences. The architecture should follow the operational reality, not the other way around.

If you're planning a migration between these platforms and you'd rather not debug pagination edge cases and attachment timeouts yourself — that's what we do.

> Planning a Zammad ↔ Helpshift migration? ClonePartner engineers custom API pipelines to move your tickets, attachments, and metadata with zero downtime. Book a 30-minute technical scoping call.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### Is Zammad or Helpshift better for mobile app support?

Helpshift is purpose-built for mobile. Its native iOS, Android, and Unity SDKs embed directly into your app, providing in-app messaging, automatic device metadata capture, and bot-driven issue deflection. Zammad has no native mobile SDK — it offers a responsive web interface only.

### Can you migrate from Zammad to Helpshift without custom code?

No. Zammad's native migration options do not list Helpshift, and Helpshift exposes migration building blocks through REST APIs rather than a one-click importer. Every production migration between these platforms requires custom API scripting, data model transformation, and HTML sanitization.

### How does Helpshift pricing compare to Zammad?

Zammad charges per agent (€7–€25/agent/month for cloud hosting). Helpshift charges per issue — starting at $150/month for 250 issues, with $0.45 per additional issue on the Starter plan. Zammad is cheaper for large teams with low issue volume; Helpshift can be more cost-effective for small teams handling high-volume bot-deflected issues.

### Can Zammad be self-hosted for free?

The Zammad software itself is free under the AGPL-3.0 license. Self-hosting requires infrastructure (servers, Elasticsearch, PostgreSQL) that typically costs €345–810/month. Optional vendor support starts at €2,999/year for 15 support requests.

### Can I migrate Zammad HTML emails into Helpshift?

Yes, but it requires transformation. Helpshift uses a chat-based UI that does not support complex HTML tables or nested quotes. You must strip the HTML, convert line breaks to newline characters, and extract links into a readable format before loading into Helpshift.