Zammad vs Helpshift: Architecture, TCO & Migration Guide

Zammad vs Helpshift: Architecture, TCO & Migration Guide

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

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:

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)

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)
• Email Parsing: Handles complex MIME types, nested email quotes, and inline attachments well.

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)

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)

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)

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)

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.

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)

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.

TCO Comparison Table (Annual Estimates)

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.

Feature Comparison

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)
• 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)
• 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) — and those run only on new instances, from one source only, as all-or-nothing operations. Helpshift is not listed. (docs.zammad.org)

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)
• 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)
• 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)

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

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

{
  "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:

{
  "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.

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)
• 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.
• 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.
• 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:

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.