Jira Service Management vs Zammad

Zammad does not supply change management or a configuration management database. It covers the agent side of ticketing well: email, chat, form and phone channels, sign-in through SAML and OpenID Connect, and search that can be backed by Elasticsearch. What it lacks is the ITIL change workflow that JSM users may run with approvals, change types and scheduled windows, and the Assets object model that links configuration items to tickets. Before you commit, list every JSM feature your agents use weekly and mark which ones sit in those two areas. If the answer is none, the gap does not affect your decision.

If you do rely on these features, plan a second system rather than expecting Zammad to absorb them. GLPI covers ITIL change management, asset inventory, configuration management and contract tracking, so it is the usual pairing when the CMDB has to be kept in step with change records. iTop is the other option, with a customizable CMDB and impact analysis. Either choice means two systems to run, two sets of users and roles to maintain, and an integration layer that links a Zammad ticket to a change or configuration item. Ask any implementation partner to name the integration method, who owns the data mapping, and how each system is backed up and upgraded.

Price the integration work as a separate line item. Zammad's API is the supported route for linking records, but mapping JSM Assets objects, change statuses and approval history into a second system is custom work that a Zammad migrator does not perform. Confirm with your vendor or partner which Assets fields need to be kept as references, which can be dropped, and whether historical change records must be queryable from Zammad after cutover. Those answers determine the effort far more than the ticket volume does.

Running Zammad yourself means operating a small stack of components, and the first decision is the database. Zammad stores its content in PostgreSQL 15 or newer, so the database version is a hard floor, not a preference. Redis 7 or newer handles realtime websocket communication for agent screens, and Nginx or Apache sits in front as the reverse proxy. Elasticsearch is optional but strongly recommended, since it drives faster search, reporting and searching inside email attachments. For a ticketing team that searches daily, plan for it from the start and confirm the sizing with the Zammad software requirements before you provision hosts.

Deployment shape follows from scale and how many application instances you run. Zammad documents installation with Docker Compose and a Kubernetes Helm chart. Memcached is needed for multi-instance deployments such as containers or cluster nodes, while a single installation can use the file system cache. On Kubernetes, Zammad support covers only the Zammad application, not Kubernetes-specific issues, so your platform team must own the cluster, ingress, storage, backups and upgrades. Confirm the support boundary in writing with Zammad GmbH before you pick the Helm route. Teams without that platform depth often find Docker Compose on a well-managed virtual machine easier to operate.

Plan the operating work as well as the installation. Someone must patch the database, Redis and Elasticsearch on their own schedules, test Zammad upgrades, and watch security releases, which Zammad publishes on more than one release line at a time. Decide whether an internal team or DeployOpen will own this, and what the support model is. A Zammad self-hosted support subscription is optional, but if you buy one, ask in the quote which tiers include upgrade help and which cover only troubleshooting. Your running cost depends mostly on these people hours and the infrastructure you already operate.

Plan the evaluation against Atlassian's published dates before you plan anything else. Server support for all server products, including Jira Service Management Server, ended on February 15, 2024, so an on-premises server instance no longer receives vendor support. Atlassian also stopped selling Data Center subscriptions to new customers on March 30, 2026. Existing customers can still buy licenses or expansions until March 30, 2028, and on March 28, 2029, Data Center licenses expire and become read-only. The first two dates have already passed, which means a team that is still on Data Center should treat March 2028 as the practical last point to expand and March 2029 as the point its instance stops accepting changes.

Read the dates as a sequence of decisions, not a single deadline. Before March 2028, confirm with your Atlassian account contact whether any license or expansion purchase is still needed for the users and agents you expect to keep during the transition, because a shrinking or read-only instance changes what the migration has to carry. Also confirm which Zammad channels, identity integrations and Elasticsearch search your ticket volume will need, since those decisions drive the size of the parallel run. The timing question for your organization is when the evaluation ends and when the cutover window opens, and that depends on your own change calendar and data volumes, which only your team can measure.

Keep in mind that Zammad has no built-in Jira migrator, so the migration runs through the Zammad API and needs custom mapping work for queues, customers and automation. Since Jira Cloud backups exclude automation rules and Assets, the export inventory should start early and be checked against the Atlassian export documentation for your own instance. Set internal checkpoints well ahead of March 2029 for decisions on scope, the API mapping, a test migration and sign-off on Zammad's support model, and ask an implementation partner for a written scope and timeline that fits those checkpoints rather than assuming a duration from this page.

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a Jira Service Management to Zammad move, that work starts with an evaluation of which queues, customer-facing channels, sign-in methods and reporting views need to survive the switch, and which Jira features, such as change management and Assets, will have no Zammad equivalent and need a separate plan. Most engagements of this kind are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work begins.

The migration design covers the parts a Jira backup does not carry across. Zammad has no built-in Jira migrator, so the design has to define how tickets, customers and attachments are exported and imported through the Zammad API, who holds the administrator token used for that import, and how the email, chat, form and phone channels are reconnected to the new instance. It also sets out how SAML or OpenID Connect sign-in is configured against your identity provider, whether Elasticsearch is in scope for search, and how Redis and PostgreSQL are sized and backed up. Confirm each of these items with your own administrators before the design is signed off.

The cutover is where most of the risk sits, so it is scoped separately: a rehearsal import, a parallel period if your queues allow one, the DNS and mail routing changes, and a rollback path if the first production day exposes a gap. Once the service is live, ongoing support, upgrades and continuous testing can run under a retainer, which keeps the Zammad release line, security patches and backups current without re-scoping each time. Ask any provider to put the evaluation, design and cutover deliverables in separate line items so that you can see what each phase costs and what it produces.