When Zammad is the better fit than Intercom for email-led support
Zammad fits support teams whose work runs mostly through email and ticketing, and who want that workflow on self-hosted infrastructure with no license fee. Intercom fits teams that depend on live chat and in-app messaging as their main front door. Both can handle a shared inbox, but the channel mix usually settles which one matches the work. If most of your customers write to a support address, a ticket queue and an agent who replies by email are the core of the job, and Zammad's channels and ticket model are built around that pattern. The decision turns on four questions. First, channel mix: count how many conversations arrive by email, web form or phone compared with live website chat, and whether you need a chat widget at all. Second, data control: if a renewal or a data residency requirement means ticket content must stay in your own cloud account or data center, a self-hosted Zammad instance keeps that content under your control. Third, identity: check whether your team needs SAML or OpenID Connect sign-in for agents, since Zammad supports both and you should confirm the exact setup with your identity provider. Fourth, operations: name who will patch, back up and upgrade the stack, because Zammad needs PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy, and Elasticsearch is strongly recommended for search. Put the answers on one page before you talk to either vendor. Teams that answer "email and tickets" to the channel question and "our infrastructure" to the data question usually have a shorter evaluation. Teams that depend on proactive chat, in-app messages or AI-led resolution should test those flows in Intercom first, because replicating them in Zammad may require different tooling or custom work that you should scope before deciding.
Which product fits which support scenario
This table maps common support setups to the better fit between Intercom and self-hosted Zammad, with the condition that makes each choice sensible. Read each row against your own channel mix, staffing and data rules, since the right answer often depends on one deciding factor rather than on feature counts.
| Scenario | Better fit | Why and the condition that decides it |
|---|---|---|
| Email-heavy ticket queues with shared mailboxes | Zammad | Zammad is built around email, ticket states, groups and SLAs, so it suits queues that arrive mostly by email. Confirm that your mailbox connections and ticket workflows work as needed in a test instance. |
| Live website chat as the main channel | Intercom | Intercom's Messenger and live chat are its core strength. Zammad handles chat as one channel among several, so choose Intercom if real-time website chat drives most of your volume. |
| In-app messaging and product onboarding | Intercom | In-app messages and product tours are Intercom features tied to its client SDKs. Confirm whether Zammad covers the specific in-app use case you need before you plan a move. |
| Internal team already owns and runs servers | Zammad | A team with Linux, container and database skills can run Zammad, PostgreSQL, Redis and optional Elasticsearch on its own infrastructure. The condition is that someone owns patching, backups and upgrades from day one. |
| Team with no ops capacity | Intercom or a supported Zammad deployment | Without people to run the stack, self-hosting shifts uptime, security patching and backups onto you. Either keep the hosted tool or budget for a paid support or implementation partner before you move. |
| Regulated conversation data that must stay in-house | Zammad | Self-hosting keeps transcripts, attachments and customer records inside your own environment, which can support data residency and access control duties. Confirm that the controls you need are yours to configure and evidence. |
| Login through corporate identity provider | Zammad | Zammad supports SAML and OpenID Connect login, so staff can sign in with your existing identity provider. Confirm the exact attribute mapping and group rules with your identity team. |
Where support data lives and who controls it
Moving from Intercom's hosted model to Zammad changes who holds the conversation data, who runs the servers and who must prove the controls work. The cards below separate the hosting choice, the login integration and the evidence work so each can be scoped and checked on its own.
Where the data sits
Intercom stores conversations, contacts and attachments in its own hosted environment, so your data location follows its service terms. A self-hosted Zammad keeps the database, file storage and search index in the cloud account or data center you choose. Ask Intercom to confirm where its customer data is stored for your plan, and record the region and facility you select for Zammad in your own data map.
Hosted plans or self-hosting
Zammad GmbH sells hosted plans that run in German data centers, which keeps the operator inside a single vendor relationship. Self-hosting moves operation into your own environment, so you own patching, backups and access to the hosts. Choose the hosted plan only if its location and contract terms meet your residency rules, and cost the self-hosted option against your own staff time.
Single sign-on with SAML or OIDC
Zammad supports third-party login through SAML and OpenID Connect, among other providers, so agents can sign in with the identity provider you already run. Confirm that your identity provider can issue the attributes Zammad needs for role mapping, and test that deprovisioning a leaver blocks access. Plan a break-glass administrator account that does not depend on the identity provider.
Access and admin roles
Under Intercom, Intercom staff operate the platform and you manage workspace roles. With Zammad, your team holds full administrator rights on the application, the database and the reverse proxy. Define who may change authentication settings, export tickets and read customer data, and log those actions. Review the list of administrators on a fixed schedule.
Evidence you must produce
Your organization must produce the evidence that controls operate, including access reviews, backup restore tests, change records and encryption settings. DeployOpen prepares these controls and evidence for your assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so agree the evidence list with them before the migration starts.
Ownership of the support record
After cutover, your organization is the controller of the full ticket history, including attachments and agent notes. Decide how long closed tickets are retained, how deletion requests are fulfilled, and where exports are stored. Intercom's terms and your own retention schedule may differ, so confirm both before you delete data from the old platform.
What a self-hosted Zammad stack contains
A self-hosted Zammad stack is more than the application. The core is the Zammad application itself, which stores its content in PostgreSQL 15 or newer and needs Redis 7 or newer for realtime websocket communication, so agents see new tickets and replies without reloading. Nginx or Apache sits in front as the reverse proxy and terminates TLS. Your team owns each of these tiers: the database backups, the Redis instance, the proxy configuration and the certificates. Before you size the environment, confirm the exact supported versions for the Zammad release you plan to install against the software requirements page, because those minimums change between releases.
Two components are optional but change how the system behaves at scale. Elasticsearch is optional but strongly recommended: it speeds up search, powers reporting and indexes the content of email attachments, which matters if your support history is mostly email. Memcached is needed for multi-instance deployments such as containers or cluster nodes, while a single installation can use the file system cache. If you plan more than one application node, decide early whether you will run Elasticsearch and Memcached in your own cluster, since they add operating work that a single-server pilot does not show.
Deployment method sets who maintains what. Zammad documents package installation, Docker Compose and a Kubernetes Helm chart. Docker Compose is the simplest path for a pilot or a single-host production setup. On Kubernetes, Zammad support covers only the Zammad application, not Kubernetes-specific issues such as cluster networking, storage classes or node upgrades, so ask who in your organization or in your implementation partner owns the cluster layer and its runbooks. Whichever route you choose, confirm the backup and restore procedure for PostgreSQL and the attachment storage before cutover.
What each option costs to run, and what recurs
Intercom bills mainly through subscriptions and add-ons, while self-hosted Zammad moves the bill to infrastructure, operations, and people. Each card below marks what is one-time, what recurs, and what changes the total, so the figures can be checked against a written quote.
Intercom subscription and add-ons
Recurring. Intercom charges per seat, and add-ons for messaging, reporting, and AI features are typically priced on top of the base plan. Ask the vendor which seats, channels, and add-ons your current contract includes and which ones renew automatically. Seat count and add-on scope are the main drivers, so review them against the number of people who actually answer tickets.
Zammad license and support subscription
Recurring, optional. Self-hosted Zammad has no license fee. The Zammad pricing page lists self-hosted support subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year. These are optional, so decide whether your team can handle upgrades and incidents without a vendor contract before budgeting for one.
Hosting and infrastructure
Recurring. Zammad runs on your cloud account, data center, or cluster. Costs include compute for the application, PostgreSQL, Redis, and reverse proxy, plus storage that grows with attachments and email history. Ask your platform team to size environments for production, staging, and test, since each one repeats the infrastructure bill.
Database, search, and cache operation
Recurring, staffed. Zammad needs PostgreSQL 15 or newer and Redis 7 or newer, and Elasticsearch is optional but strongly recommended for search, reporting, and attachment content. Memcached is required for multi-instance deployments. Each service adds patching, monitoring, and capacity work, which is usually the largest recurring labor item.
Backups, upgrades, and security patching
Recurring. Plan for regular backups of the database and attachments, restore tests, and Zammad release upgrades. Zammad published security releases on more than one line in the same period, so an operator needs a process for applying patches quickly. Ask any implementation partner to price backups and upgrades as a retainer or as a fixed-scope service.
Implementation and migration labor
One-time. Setup, channel configuration, login integration, knowledge base content, and data migration are the main one-off costs. Zammad's built-in migrators cover Freshdesk, Kayako, OTRS, and Zendesk, but Intercom is not among them, so conversation history usually needs API extraction and custom work. Ask for a fixed scope, named deliverables, and a cutover plan in writing.
How a move from Intercom to Zammad usually runs
The sequence turns Intercom conversations, contacts and routing into a self-hosted Zammad instance that is tested with real traffic before Intercom is switched off. Each step ends with a check that the previous one is complete.
Scope channels, inboxes and volumes
The support lead and an Intercom administrator list every inbox, the Messenger widget, the email addresses that route into Intercom, and the teams that work each queue. They also note which conversations must be kept, how far back history should go, and which contacts carry personal data that needs a retention rule. The output is a written inventory that the Zammad design can be checked against. Done when every channel has an owner and a decision on whether its history migrates.
Export conversations and contacts from Intercom
The Intercom administrator pulls contacts and conversation data, and the migration team pulls full message history through the Intercom Conversations API. CSV and Amazon S3 exports omit transcripts, so they cover reporting metadata but not what customers and agents actually wrote. The team stores the raw export in a controlled location with access logging. Done when a sample of conversations can be read back with complete message content and matching contact identifiers.
Build the Zammad instance
The infrastructure team installs Zammad inside the organization's own environment, using the documented Docker Compose or Kubernetes Helm chart route, with PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy such as Nginx or Apache. They decide whether Elasticsearch and Memcached are needed for their topology, since the software requirements page treats Elasticsearch as strongly recommended and Memcached as required for multi-instance deployments. Done when the instance runs, backups and restores have been tested, and the team has confirmed its hosting and upgrade responsibilities in writing.
Configure channels, login and knowledge base
Administrators connect email channels, set up the web form or chat channels the business needs, and configure single sign-on through SAML or OpenID Connect with the identity provider the organization already uses. They also set up the knowledge base with public and internal articles in the required languages. Confirm with the vendor which channels and login options match the chosen edition. Done when test tickets arrive through each channel and a test agent signs in through the identity provider.
Import history with a custom Zammad API script
Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, not Intercom, so Intercom history needs a custom import through the Zammad API, usually written by the migration team or by a partner. The script maps contacts to Zammad customers, conversations to tickets and articles, and agent names to users, and it should be run first against a test instance. Done when a reconciliation report shows matching counts of contacts and conversations and a sample ticket displays the original message order and attachments.
Map teams, groups and automation rules
The team rebuilds Intercom teams as Zammad groups, sets agent roles and permissions, and rewrites routing and automation rules such as assignment, tagging and escalation as Zammad triggers, overviews and schedules. Intercom automation rules do not transfer automatically, so each one is documented and recreated, then tested with sample tickets. Done when every routing rule in the inventory has a Zammad equivalent and a test case that passes.
Run both systems during cutover
The team keeps Intercom live while Zammad receives new traffic on the cut-over channels, then moves channels one at a time and watches response handling, missed messages and agent feedback. Incremental catch-up of conversations created after the main import is handled by the script, since differential migrations are not supported by the built-in tools. Done when each channel has carried live traffic without loss and the open-conversation backlog in Intercom is empty or formally transferred.
Retire Intercom and confirm records
After the last channel has moved, the organization updates its website widget, email routing and links, confirms that the Intercom export and any retained data are stored under the retention rules set in the first step, and cancels the Intercom subscription at the end of its term. Audit logs and access records are kept according to the organization's own policy. Done when Intercom no longer receives traffic, the retained archive is verified, and the owner signs off on the decommissioning record.
Questions buyers ask before moving from Intercom to Zammad
How much does moving from Intercom to a self-hosted Zammad cost?
The Zammad software itself carries no license fee when self-hosted, so the cost is made up of infrastructure, staff time, migration work and any support you buy. Infrastructure is recurring and depends on your hosting model and user count. Migration and configuration are largely one-time costs, and their size depends on how many inboxes, macros, automations and integrations you need to rebuild. Zammad sells self-hosted support subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to its pricing page. Ask any implementation partner for a written quote based on a defined scope, and ask which costs recur each year.
How long does an Intercom to Zammad move take?
The timeline depends on the scope you agree, not on a fixed duration. The main drivers are the number of channels to connect (email, web forms, and any chat or social sources), how much history you need to bring across, how many automations and roles you must rebuild, and how many people must test and sign off. Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, but not Intercom, so an Intercom move relies on exporting or pulling data through the API and a custom import. Confirm the approach and milestones in writing before work starts, and ask for a schedule that includes a parallel-running period.
What does the work need from our own team?
Your team needs to make decisions and provide access. That means naming an owner for the business rules, supplying the list of inboxes, teams, SLAs and macros, approving the email routing and domain changes, and testing real conversations before cutover. Your IT or platform team will need to supply hosting, a database, Redis, a reverse proxy and identity provider settings. Your support leads should review how agents will work in the new interface. Ask the partner to list these inputs in the written scope so that responsibilities are clear from the start.
Can our internal team run the migration without a partner?
Yes, a capable internal platform team can deploy Zammad using the documented Docker Compose or Kubernetes Helm installation paths. The harder part is the data move and the redesign of your support processes. Zammad's documentation notes that its Kubernetes support covers the application only, not Kubernetes-specific issues, so your team must own the cluster. Consider a partner if you lack experience with PostgreSQL, Redis, Elasticsearch and identity integration, or if you need an independent cutover plan. Whichever route you pick, write down who owns each component after go-live.
Does Zammad replace Intercom live chat?
Zammad is built primarily around email and ticket-based support, with a knowledge base and channels that connect to your existing contact points. Confirm the current channel options directly in Zammad's documentation and on a test instance before you commit, since capabilities change between releases. If your support depends on a website chat widget and real-time visitor messaging, compare that requirement with Intercom vs Chatwoot in the same series, which covers a different chat-first option. Map each Intercom feature you use to a Zammad feature or a documented workaround.
How does Zammad handle SAML or OIDC login?
Zammad supports third-party login through SAML and OpenID Connect, along with providers such as Microsoft, Google, GitHub and GitLab. Configuration is done in the admin settings under security and third-party applications, so you will need your identity provider metadata, client details and the callback URLs Zammad expects. Confirm the exact steps for your identity provider and Zammad version in the admin documentation, and test role mapping and account provisioning with a small group before moving all agents. Your identity team should also decide how deprovisioning works when someone leaves.
What happens to our full Intercom conversation history?
Intercom conversation history is not carried across automatically, because Zammad does not ship a built-in Intercom migrator. Intercom's standard exports do not contain full transcripts, so the usual route is to pull conversation content through Intercom's API, map contacts and conversations to Zammad tickets and users, and import them through the Zammad API or a custom importer. Confirm how much history you need, whether you want closed tickets archived in read-only form, and how attachments will be handled. Zammad's migration documentation also notes that its built-in migrations are all or nothing and work only on a new instance, so plan a test import first.
What does ongoing support cost after go-live?
Ongoing cost has three parts: infrastructure and its operation, your own staff time for upgrades and monitoring, and any support subscription you buy from Zammad GmbH or a partner. Zammad's Business, Enterprise and Corporation tiers are listed at 2,999, 5,999 and 9,999 EUR per year respectively on its pricing page. Upgrades follow Zammad's release cycle, including security releases published across its 6.5 and 7.x lines, so you need a regular patching routine. Ask any partner to define in writing what retained support covers, response expectations and how upgrades are handled.
What the decision turns on before you commit
The first question is how much of your support runs through live chat compared with email and ticket queues. Zammad is built around email, ticketing and a shared inbox across channels, so teams whose volume arrives mostly by email will find the fit natural. If the Messenger widget, proactive chat and real-time visitor conversations are central to how you sell or support customers, confirm with Zammad which channels it covers today in the version you plan to run, and compare that against the Intercom features your agents use every day. Also settle whether your knowledge base needs to be public, internal, or both, and in how many languages, since that shapes the setup work.
The second question is where the data must live and who operates the stack. Self-hosting moves hosting, backups, patching and monitoring to your side, and Zammad's own requirements list PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy, with Elasticsearch and Memcached added for search and multi-instance deployments. Decide who owns those components, how restores are tested, and whether you need a partner for the initial build. Upgrades deserve a written process: Zammad publishes minor releases such as 7.2 alongside security releases on parallel lines, including 6.5.5 for the 6.5 line, so your team needs a rule for which line it runs and how quickly it applies security fixes.
The third question is identity and the budget view. Confirm whether your identity provider supports SAML or OpenID Connect, since Zammad documents both for third-party login, and check how agent roles and provisioning will be handled. On cost, Zammad itself has no license fee for self-hosted use, so the recurring spend is infrastructure, operations time and any support contract. The optional Business, Enterprise and Corporation support subscriptions are listed on Zammad's pricing page, and the budget owner should compare that line with Intercom's per-seat and usage charges on a like-for-like basis, including the staff time needed to run the platform.
How DeployOpen helps evaluate and implement a Zammad move
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Intercom to Zammad, we start with a written scope that fits how your support actually runs through email and tickets.
How we scope
- Map which Intercom conversations, inboxes and help center content need to move, and which can be retired
- Confirm Zammad channels, SAML or OIDC login and the identity provider your team already uses
- Agree deliverables, timelines and responsibilities in writing before any build work starts
How we build
- Install Zammad with its supported deployment method, with PostgreSQL 15 or newer and Redis 7 or newer
- Configure email channels, groups, roles, knowledge base content and single sign-on for your agents
- Run security testing on the deployed application and its APIs before go-live
How we hand over
- Document the architecture, configuration decisions, backup procedures and upgrade steps for your own team
- Walk through admin tasks with the people who will run Zammad after the engagement ends
- Provide evidence of configuration and controls that your auditors can review, without issuing any attestation
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Track Zammad security releases for both supported lines and plan patching in your environment
- Agree the support scope in writing so responsibilities for hosting and application issues stay clear
