What a Zammad implementation involves
A greenfield self-hosted Zammad build covers the application and every service it depends on, all inside infrastructure your organization controls. The core work is installing Zammad from the package, Docker Compose or Helm options the project documents, then provisioning PostgreSQL 15 or newer for content storage and Redis 7 or newer for realtime websocket communication. Elasticsearch is optional but strongly recommended for faster search, reporting and attachment content search, so the plan should decide whether it is in scope from the start. A reverse proxy (Nginx or Apache) sits in front of the application, and channel setup covers email inbound and outbound, web forms, chat and any phone integration you choose.
Most organizations start this work for one of three reasons: a new helpdesk with no current tool, consolidation of several support tools into one queue, or a move off a hosted plan to self-hosting for data location or control. Each trigger changes the scope. A consolidation project adds source-system exports and identity mapping, while a move off a hosted plan adds a migration and cutover window. Many teams with Linux and PostgreSQL experience build the first environment in-house, and bring in a partner when channels, identity integration or a compressed go-live date add load they cannot absorb.
Zammad has no license fee, since it is licensed under the GNU Affero General Public License version 3. The quoted cost is therefore the implementation work plus the operating effort that follows. Implementation is largely one-time: design, build, testing and handover. Operating effort recurs: applying minor and security releases, maintaining database and search backups, monitoring, and staff time for administration. An optional vendor support subscription is a separate recurring line item. Ask any provider to split its quote into these components so you can compare it with an in-house estimate and with the hosted per-agent alternative.
What the work includes and what you receive
The work runs from a written scope document to a configured instance your team can operate. Migration, SSO and high availability are separate scopes and are priced apart.
Scoping workshop and scope document
The scoping workshop agrees the hosting target, expected agent and customer numbers, the channels in use and the systems Zammad must reach. Its output is a written scope document listing what is in and out, and the quote follows from it. Include your security team, mail administrators and the person who will own the instance after go-live.
Environment build by chosen method
The build uses the installation method you choose: the Zammad package, Docker Compose or the Kubernetes Helm chart. On Kubernetes, Zammad support covers the application only, so cluster issues stay with your platform team. Confirm the operating system or cluster, and where attachments are stored, before the build starts.
PostgreSQL, Redis and search configuration
Zammad stores content in PostgreSQL 15 or newer and needs Redis 7 or newer for realtime websocket communication. Elasticsearch is optional but strongly recommended for search, reporting and attachment content, and Memcached is needed when several instances run. Confirm which services you run and whether Elasticsearch sizing is part of the written scope.
Reverse proxy with TLS
Nginx or Apache sits in front of Zammad and terminates TLS for agents and customers. The configuration covers certificate installation, HTTP to HTTPS redirects and the proxy settings that websocket connections require. Confirm who issues and renews certificates and whether internal certificate authorities must be trusted by mail or telephony connectors. Hardening beyond this is a separate scope.
Channels, groups, roles and accounts
Channels cover email in and out, web forms, chat and phone, each connected to the mailboxes, widgets and telephony providers named in scope. The build also creates groups, roles, and agent and customer accounts that match your team structure. Record the channel list and role matrix in the scope document so access decisions are agreed before go-live.
Testing, runbooks and handover
Testing checks each channel end to end, including ticket creation, replies, notifications and role-based access, against acceptance criteria in the scope. You receive the configured and tested instance, runbooks for routine operations, and configuration records that document settings and their owners. A handover session walks your administrators through all three before sign-off.
What drives effort and cost
This table lists the main drivers of Zammad implementation effort, explains why each one moves cost, and shows how to keep it contained.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Agents and customers | Concurrent agents and ticket volume set database, cache and websocket load, and hosted plans bill per agent. | Size from named agents and expected peak concurrency. Confirm both with the business before design. |
| Inbound channels and mailboxes | Each email account, web form, chat and phone line needs configuration, mail flow checks and testing. | Start with the channels that carry the most tickets and add others after go-live. |
| Groups, roles and permissions | Each group, role and permission set adds access and ticket visibility tests. | Model groups on teams that handle work, and document roles before configuring anything. |
| Triggers, macros and SLAs | Every trigger, macro and SLA rule must be specified, tested and rechecked after each upgrade. | Limit custom rules to agreed processes and keep their specifications in version-controlled documentation. |
| Elasticsearch and attachment search | Elasticsearch is optional but strongly recommended for search, reporting and attachment content, and it adds a cluster to operate. | Confirm whether attachment search is required, then size and back up the cluster to match. |
| Data stores to operate | PostgreSQL 15 or newer, Redis 7 or newer and Memcached for multi-instance setups each need backup, patching and monitoring. | Reuse your existing database and cache operations standards and confirm who owns backups. |
| Identity and other integrations | SAML, OpenID Connect, Microsoft, Google, GitHub or GitLab login needs provider setup, role mapping and testing. | Choose one identity source and map roles to groups before go-live. |
| Compliance and data location | Data residency, retention, encryption and audit evidence add design and documentation work for a self-hosted setup. | Document data location and retention needs first. Independent auditors, not DeployOpen, issue assessment results. |
| Instances, environments and deployment method | Package, Docker Compose or Kubernetes each change the build, storage and upgrade work, and multiple instances need Memcached. | Choose the simplest method that meets availability needs. Kubernetes support covers the application only, so platform work is separate. |
Project phases and outputs
The sequence moves from agreed scope and sizing to a tested, documented Zammad helpdesk handed over to your team, with each phase closing on a written output.
Confirm discovery and scope
Your team and DeployOpen review ticket volumes, channels (email, chat, web forms, phone), groups, roles, existing systems and data to migrate, and the hosting location. The output is a written scope with deliverables, responsibilities and a phase plan with dates, which you should request before work starts.
Design architecture and size components
The design sets the application topology, reverse proxy, and the backing services: PostgreSQL 15 or newer for content, Redis 7 or newer for realtime websocket communication, and optional Elasticsearch for search, reporting and attachment search. Memcached is planned for multi-instance deployments, while single installations can use the file system cache. The output is an architecture document with sizing assumptions to confirm with your platform team.
Build the non-production environment
DeployOpen installs Zammad in your non-production infrastructure using the package, Docker Compose or Kubernetes method you choose, and connects the database, cache and search services. The step closes when the environment starts cleanly, backing services are reachable, and the build is recorded in a runbook your team can repeat.
Configure groups, roles and channels
Groups, roles, SLAs, email accounts, web form and chat channels, phone integration and identity login are configured against the approved design. Each configured item is traced back to a requirement in the scope. The output is a configuration baseline and a list of open decisions for your team to sign off.
Run acceptance testing
Your agents and administrators test real ticket flows, channel routing, notifications, permissions and any migrated data using test cases agreed in discovery. Defects are logged, fixed and retested. The step closes with a signed acceptance record that lists each test case, its result and any accepted residual risk.
Go live and hand over
The production environment is built from the same tested configuration, the cutover plan is executed, and monitoring and backups are verified. Handover covers runbooks, administration training and the support arrangement for updates and security releases. The output is a live system, a handover pack and a documented owner for each operational task.
Which parts stay in-house and which go to a partner
This table maps each Zammad implementation work package to who usually owns it, the skills it needs, and what your team should keep for ongoing ownership, so you can split the work before asking for a quote.
| Work package | Usually owned by | Skills needed and what to keep in-house |
|---|---|---|
| Business process and role design | Client | Support leads and operations managers define queues, groups, escalation paths and agent roles. Keep ownership of these decisions, since they change as your support model changes. |
| Linux, PostgreSQL and Redis operations | Client platform team or partner | Linux administration, PostgreSQL 15 or newer, and Redis 7 or newer for websocket traffic. Your platform team should hold the admin credentials, patching schedule and backup restore tests. |
| Reverse proxy and TLS | Either, agreed in the scope | Nginx or Apache configuration, certificate issuance and renewal, and websocket proxying. Confirm who renews certificates and who owns the proxy config after handover. |
| Elasticsearch sizing and operation | Usually the client platform team | Search cluster sizing, index rebuilds after upgrades or migrations, and monitoring of disk and heap. Elasticsearch is optional but strongly recommended, so confirm whether your team can run it long term. |
| Channel and mailbox configuration | Either, depending on mail and phone skills | Email inbound and outbound accounts, web forms, chat and phone integrations. Your mail administrators should own DNS, SPF, DKIM and mailbox credentials. |
| Acceptance testing | Client support leads with partner help | Test scripts for ticket creation, routing, SLAs, triggers and macros across each channel. Support leads should sign off, because they know which outcomes matter to customers. |
| Handover and operating documentation | Partner, with named client owners | Runbooks for upgrades, security releases, backups and restores, plus a named owner per area. Client owners should attend the handover and run one routine task themselves before go-live. |
What usually goes wrong and how to prevent it
Most Zammad delays and rework trace back to a short list of decisions made too late or not at all. Settle these before build starts so the plan and cost estimate reflect the work that will actually happen.
Unclear group and role model
Groups, roles and agent permissions drive ticket routing, visibility and reporting. When they are defined after configuration starts, triggers, macros and SSO role mapping are rebuilt. Before quoting, document each team, its escalation path, and which agents may see which groups.
Mailboxes and channels configured late
Email inbound and outbound addresses, DNS records, chat, web forms and phone integrations each need credentials, testing and sign-off from the owning team. Leaving them to the end pushes testing into cutover week. List every channel and its owner at scoping, and ask the partner to schedule channel testing as its own milestone.
No Elasticsearch decision before go-live
Zammad uses Elasticsearch for faster search, reporting and attachment content search, and the documentation describes it as optional but strongly recommended. Deciding after go-live means building the cluster under live load and rebuilding the index. Decide before quoting, since the cluster adds hosting, sizing and operations effort.
Underestimating data store operations
PostgreSQL 15 or newer holds the content, Redis 7 or newer serves realtime websocket traffic, and multi-instance deployments add Memcached. Each needs backups, patching, monitoring and capacity planning on your side. Ask who owns these components after go-live and whether backup restores have been tested.
Customizations that block later releases
Triggers, macros, custom object attributes and API scripts are cheap to add and expensive to retest after each minor or security release. Limit custom work to documented configuration where possible, keep scripts in version control, and include a regression test pass for every customization in the upgrade budget.
No named business owner for acceptance
Without one accountable person from the support organization, acceptance drifts and go-live slips while questions about routing, SLAs and reporting go unanswered. Name the owner before the statement of work is signed, give them authority to approve scope changes, and set the acceptance criteria with them in writing.
How the work changes by starting point
With no helpdesk in place, the plan starts from a blank design, and most of the effort goes into deciding how work enters and leaves the team.
- Scope: channel setup for email, web forms, chat and phone, plus groups, roles and escalation rules designed from scratch.
- Testing: build a test instance with sample mailboxes and walk each channel through a full ticket lifecycle.
- Prerequisites: agree on ticket states, priorities and ownership rules before any configuration begins.
- Data: there is no historical import, so the first weeks after go-live carry the full workload of learning the new process.
When the current helpdesk stays live during the build, the plan needs a routing design and a cutover decision, so that no inbound message is duplicated or lost.
- Scope: mail forwarding changes, routing rules and a decision on which channels move first.
- Testing: run both systems against copied traffic and check which system received each message.
- Prerequisites: mailbox access, DNS or forwarding changes and a named owner for each change window.
- Cutover: moving historical tickets, users and organizations is covered in the migration topic, so this plan only sets the timing and rollback points.
Deploying with the Helm chart changes who owns each layer. Your platform team runs the cluster, while the chart defines the Zammad application deployment.
- Scope: ingress, storage classes, secrets and persistent volume backups sit with your platform team.
- Support boundary: Zammad support covers the application only, so cluster-level faults need your own team or a Kubernetes provider you contract with.
- Testing: rehearse upgrades and rollbacks in a non-production cluster before the chart is used in production.
- Prerequisites: confirm the chart version against the Zammad release you target, and plan Memcached and Elasticsearch for multi-instance operation.
Chart configuration details are covered in the Kubernetes topic.
In restricted networks, the install depends on what can cross the boundary, so every package, container image and search component must be staged in advance.
- Scope: an internal mirror for operating system packages, container images and language dependencies, plus local copies of documentation.
- Testing: perform a clean install from the mirror with outbound access blocked, before go-live.
- Prerequisites: confirm with Zammad which external calls the chosen install method makes, including email relays and third-party login providers.
- Updates: each security release needs a new transfer cycle, so plan the time for it in the operating model.
When PostgreSQL and Redis already run as shared services, the work shifts from building databases to confirming that Zammad can share them safely.
- Version check: Zammad requires PostgreSQL 15 or newer and Redis 7 or newer, so confirm the existing service versions first.
- Scope: a dedicated database, role and Redis namespace for Zammad, with capacity reviewed alongside the other tenants.
- Testing: load test realtime websocket behavior through the shared Redis, since other workloads can change latency.
- Prerequisites: agree backup windows and restore tests with the shared service owner, and confirm whether that service runs in high availability.
What you need to provide before work starts
Most delays in a Zammad project trace back to a short list of inputs that the client has to supply before the build phase opens. Hosting comes first. Confirm the cloud account, virtual machines or data center space, and the network paths between the Zammad application, PostgreSQL, Redis, Memcached if you run more than one instance, and Elasticsearch. Ask your network team to confirm that the application servers can reach the mail servers and the identity provider, and that outbound paths for notifications are open. Without these paths, the installation phase cannot be tested end to end.
Next, supply the DNS records and TLS certificates for the public hostname and any separate hostnames for the admin interface or customer portal. Certificates need to be issued by a CA your customers' browsers trust, and the reverse proxy (Nginx or Apache) needs the certificate chain and private key in a location your team controls. Mail accounts come next. Each inbound channel needs a dedicated mailbox or forwarding rule, plus credentials or OAuth consent for outbound sending. Channel setup, including the email and chat channels, blocks ticket intake testing, so name the mailbox owner for each one.
Decisions block the configuration phase. Name one business owner who can approve group structure, role permissions, SLA rules and escalation paths without waiting for a committee. Provide a written list of groups (for example, tier 1, billing and security), the roles each group needs, and the SLA targets and calendars that apply. If login is in scope, provide the identity provider metadata or client registration details for SAML or OpenID Connect, plus the attribute mapping for roles. Sample tickets from real queues, with typical attachments and customer messages, let the team test triggers, macros and search before go-live.
Finally, name a support lead who will run acceptance testing and sign off on each phase. This person should know the current helpdesk workflow, be able to decide whether a migrated ticket is correct, and be available during cutover. Clarify early whether the client or DeployOpen owns the Zammad administrator account and the server access that goes with it. Confirm these items in writing at the start, because the fixed-scope plan and any quote depend on them.
Questions buyers ask before hiring help
What drives the cost of a Zammad implementation?
Scope drives most of the cost. The main inputs are the number of channels (email, chat, web forms and phone), the number of groups and roles, whether tickets are migrated from Zendesk, Freshdesk, OTRS or another system, which identity providers need SSO, and how many integrations or customizations are required. Infrastructure work adds to this: PostgreSQL 15 or newer, Redis 7 or newer, and Elasticsearch and Memcached where you run multiple instances. Ask each quote to separate one-time build work from recurring items such as support, upgrades and hosting.
Can our own team install and run Zammad without a partner?
Many teams can install Zammad themselves. Zammad documents package installation, Docker Compose and a Kubernetes Helm chart, so the first deployment is often the smaller share of the work. The effort usually sits in what surrounds it: database and cache operations, the reverse proxy and TLS, search, backups with tested restores, channel setup, migration and ongoing upgrades. On Kubernetes, Zammad support covers only the application, so cluster problems stay with your platform team. Assess those skills honestly before you decide.
How long does a Zammad implementation take and why isn't it quoted?
No duration is quoted before scoping because the timeline depends on inputs nobody has confirmed yet. Channels, data volume, migration sources, integrations and approvals all change the schedule. DeployOpen plans most engagements as fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A fixed-scope agreement lists the deliverables, the milestones, the responsibilities on both sides and what sits outside the agreed scope. Ask any provider for a timeline tied to named milestones.
What must our team provide before implementation work starts?
Expect to supply the list of channels and mailboxes, the group and role model, and access to the systems you plan to migrate from so the data can be exported. You will also need identity provider details for SSO, the target hosting environment with its network and TLS requirements, and named approvers for scope decisions. A tester who knows your support workflows is essential. Missing inputs often delay the schedule more than the build itself, so confirm the list in the written scope.
Is Elasticsearch required to run Zammad?
No, Elasticsearch is optional, but Zammad's documentation strongly recommends it. It makes search faster, supports reporting and enables searching the content of email attachments. Adding it means sizing and operating a separate cluster, connecting it to Zammad and rebuilding the index after upgrades or migrations. Multi-instance deployments also need Memcached. Decide early, because the choice affects hosting cost, backup scope and the quote.
Does Zammad have a license fee and what do support subscriptions cover?
Self-hosted Zammad has no license fee. The code is licensed under the GNU Affero General Public License version 3, so a quote covers implementation services, your infrastructure and any support you choose. Zammad's pricing page lists self-hosted support subscriptions: Business at 2,999 EUR per year with a 6-hour response time, Enterprise at 5,999 EUR per year with 4 hours, and Corporation at 9,999 EUR per year with 2 hours. Hosted plans bill per agent per month, at 7 EUR for up to 5 agents, 16 EUR for up to 35 and 25 EUR for unlimited agents, in a German data center. Compare these options on staff time and data location.
How DeployOpen scopes, delivers and hands over Zammad
DeployOpen plans, implements, customizes, documents and supports self-hosted Zammad inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. Engagements are fixed-scope, with the channels, groups, roles and infrastructure agreed in writing before build work starts.
How we scope
- The written scope lists the channels to connect, such as email, web forms, chat and phone, and the groups and roles each team needs.
- Scope records the PostgreSQL, Redis and Elasticsearch layout, plus whether Memcached is needed for a multi-instance deployment.
- Scope names the identity provider, migration source, integrations and the data volumes that will be moved into Zammad.
How we build
- We install Zammad with the method your team chooses, such as package installation, Docker Compose or the Helm chart, and document the reasons.
- Reverse proxy, TLS, Redis realtime settings and Elasticsearch indexing are configured and tested against the agreed channel design.
- Triggers, macros, groups and role permissions are built and tested in a non-production instance before they reach users.
How we hand over
- Handover documents the installed versions, configuration, channel connections, group and role model, and backup and restore steps.
- Runbooks cover how to apply minor and security releases and how to verify a Zammad instance after each upgrade.
- Your administrators receive a walkthrough of configuration decisions, open items and the support boundaries agreed in the scope.
How we support
- Ongoing support, upgrades and testing of customizations are available as a retainer, sized to the scope agreed for your Zammad instance.
- Upgrade work follows the Zammad release line you run, so security releases and major version moves are planned and tested first.
- Ask the vendor and DeployOpen to confirm which support responsibilities sit with each party before go-live.
