When Zammad replaces TOPdesk for ticketing, and when it does not
Zammad fits a team that uses TOPdesk mainly as a ticket desk, where most work is requests arriving by email, chat or portal, being routed to agents, and answered from a knowledge base. That describes many IT help desks and non-IT departments such as facilities or HR. GLPI fits a team that also depends on TOPdesk for asset records, change control, or a configuration database that links incidents to hardware and software. The decision turns on three questions: how much of your TOPdesk use is asset management, how much is change management, and whether your desk needs a CMDB that incidents and changes reference. Answer those questions before comparing feature lists, because they determine which platform you migrate to.
Start with a usage audit of your TOPdesk instance. Count how many incidents are linked to a specific asset, how many changes go through approval, and whether agents look up configuration items from the desk. Zammad handles channels and ticket workflow well, including email, chat and portal intake, routing and a knowledge base. The gaps in asset and change management mean you should confirm with the Zammad project whether your required functions exist in the version you would deploy, and not assume parity from marketing material. GLPI covers incident, problem, change and service level management, asset inventory, configuration management and a knowledge base under the GPL-3.0 license, so it becomes the candidate as soon as the audit finds asset or change use. Its source repository documents these modules in detail.
If the audit shows only ticketing, Zammad avoids the GLPI data model work, and self-hosting carries no license fee. The costs that remain are your own servers, PostgreSQL and Elasticsearch operation, backups, upgrades and any support contract. Zammad's pricing page lists a self-hosted support subscription named Business at 2,999 EUR per year, which is optional. If the audit shows both kinds of use, a split is possible, with Zammad for requester-facing desks and GLPI for IT operations, but that means two systems, two sets of roles and an integration that you should scope in writing before you decide. Keep your TOPdesk renewal date in view while you run the audit.
Which platform fits which scenario
This table maps common TOPdesk ticketing scenarios to the platform that fits each one better, with a short reason tied to what the supplied capabilities cover. Read it against your own queues: if a row describes most of your volume, that platform is the likelier starting point, and the rows where Zammad is weaker show where GLPI or a separate tool should take over.
| Scenario | Better fit | Reason |
|---|---|---|
| Customer-facing ticket queues | Zammad | Email, chat and portal channels with a knowledge base suit external requesters who never log into an ITSM console. |
| Internal IT incident queues | GLPI | GLPI covers ITIL incident management alongside assets, so incidents link to the devices and contracts involved. |
| Shared inboxes for departments | Zammad | Email-based ticket handling and reporting fit teams that work from a common mailbox rather than an asset register. |
| Asset tracking and inventory | GLPI | GLPI provides asset inventory and configuration management, and GLPI Agent collects hardware and software data; Zammad has no equivalent asset model. |
| Formal change approval (CAB) | GLPI | GLPI covers ITIL change management, while Zammad lacks change management, so confirm the approval workflow you need against GLPI before committing. |
| Facility or shared service requests | GLPI | GLPI's wider service management and contract tracking cover service requests tied to premises and suppliers; confirm facility-specific workflows in a pilot. |
| Reporting on ticket volumes | Zammad | Zammad uses Elasticsearch for reporting features, so confirm the reports your managers need in a trial with real data. |
| Knowledge base for end users | Zammad | Zammad includes a knowledge base and portal for self-service, aimed at requesters outside IT. |
Where Zammad fits a ticket-first desk
Zammad fits a ticket-first desk when the work arrives mostly as email, web chat and customer or employee portal requests, and when the team wants one queue for all of them. Its ticket channels cover email, chat and a portal, and it ships a knowledge base that agents and requesters can both search. If your TOPdesk use is mainly incident and request handling for IT or another department, these are the areas to map first, because they carry most of the daily load. Before you commit, list the channels you actually use today and confirm in the Zammad admin documentation which of them your version and configuration support, since channel setup and knowledge base features differ between editions and releases.
Identity is the second check. Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. This matters most when your staff already sign in through a central identity provider, because it removes a separate password store for agents and lets offboarding happen in one place. Confirm which provider you run, how group or role mapping is handled, and how requesters outside your directory will authenticate. The self-hosted edition carries no license fee, but Zammad is licensed under the GNU Affero General Public License version 3, so review its terms with your legal team if you plan to modify the code and offer it to others. Support contracts named Business, Enterprise and Corporation are optional and priced separately.
Search and reporting depend on Elasticsearch. Zammad uses it for faster search, reporting features and searching the content of email attachments, and the requirements page describes it as optional but strongly recommended. This matters if your desk relies on ticket history, attachment search or management reports, and less if you handle small volumes with simple queues. Plan for it as an extra service to run, back up and patch, and ask your team to test report output against the views your managers use in TOPdesk today.
What Zammad does not cover in asset and change management
Zammad is built around ticket channels, knowledge and reporting, so the asset, configuration, change and contract work that TOPdesk users may rely on sits outside its core. Confirm each gap against Zammad's current documentation before you decide, and compare it with what GLPI covers.
Asset inventory
TOPdesk teams often track hardware, licenses and assigned equipment inside the service desk so a ticket can point to the device involved. Zammad's ticketing model centers on tickets, customers and organizations, so check whether it can hold a managed asset register with lifecycle status and assignment history. GLPI covers this with asset inventory and optional agent-based hardware and software collection through GLPI Agent.
Configuration management database
A CMDB links servers, applications and services to each other, so an incident shows what it affects and a change shows what depends on it. Ask Zammad's maintainers whether it offers relationships between configuration items beyond tags and custom fields. GLPI lists CMDB and configuration management among its core functions, which is why it is the usual fit when dependency mapping matters.
Formal change workflows
ITIL-style change management needs change types, risk assessment, approval steps and a schedule that the desk can audit. Zammad handles approvals only if you build them with triggers, macros and ticket states, which you should test against your own change policy. GLPI includes ITIL change management as a built-in process, so it is the better starting point if change control is a formal audit topic.
Contract and license management
Renewal dates, license counts and supplier contracts drive cost and risk, and TOPdesk teams often track them next to tickets. Zammad does not document contract tracking as a core feature, so confirm this with Zammad before you plan to rely on it. GLPI includes contract management and financial management, which let you tie contracts to assets and suppliers.
Problem and service level management
Problem records group repeated incidents to a root cause, and service level agreements define response and resolution targets per service. Zammad supports SLAs and reporting, but confirm whether it has a dedicated problem record type linked to known errors. GLPI covers problem management and service level management, including group-managed OLAs in its 12.0.0 release.
Inventory-driven discovery
Some desks need the tool to discover devices on the network and update records without manual entry. Zammad does not describe network discovery or inventory collection as part of its product, so confirm this in its documentation. GLPI Agent runs on Windows, macOS and Linux and performs inventory and network discovery, making it the fit when records must stay current automatically.
Hosting, data location and compliance implications
When you run Zammad in your own data center or cloud account, every ticket, attachment and log stays where you place it, and your team decides who operates each tier. The application stores its content in PostgreSQL 15 or newer and uses Redis 7 or newer for live websocket communication. Elasticsearch is optional but strongly recommended for search, reporting and attachment content, and Memcached becomes necessary once you run several instances as containers or cluster nodes. The Zammad software requirements page lists these dependencies.
- Database tier: Your team patches, backs up and restores PostgreSQL, whether it runs as a managed service in your account or as a cluster you operate.
- Redis and search: Redis carries live connections, so its network exposure and failover need the same review as the database. Elasticsearch indexes attachment text, which can contain personal data, so its access and retention settings need documenting.
- Identity integration: Zammad supports SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab logins, so staff access can follow your directory and multi-factor policy.
- Evidence you produce: Data flow maps, architecture diagrams, access reviews, restore test records and patch logs all come from your team.
Confirm with your security team which of these tiers already fall under existing controls before you choose a deployment model.
Zammad GmbH sells hosted plans that run in German data centers. This places the primary data store in one European hosting location, but the operator, its subcontractors and its support access become part of your assessment. Residency for the main store does not automatically cover backups, logs, monitoring or support tooling, so ask the vendor to describe each of these in writing. Compare the written answers with your data classification before you accept the hosted terms.
- Hosting location: Confirm which German facility holds your primary data and where backups and logs are replicated.
- Operator access: Ask who can reach your database, attachments and logs, under what approval, and how that access is recorded.
- Sub-processors: Request the current list of subcontractors and the data processing terms that apply to them.
- Identity: Confirm whether single sign-on to your directory is included on the plan you buy and which login providers you can federate.
- Exit: Ask how you export all tickets and attachments at termination and how long deleted data stays in backups.
Check these answers against your contract and data classification rules, because your own compliance evidence will still need to cover the vendor relationship.
TOPdesk hosts its SaaS offering on Microsoft Azure in several regions, and the region assigned to your tenant defines where your service desk data sits. Moving to Zammad or GLPI changes the operator, the hosting location and the evidence trail together, so the migration is a compliance change as well as a software change. Before you compare options, collect your current contract, data processing terms and region so that you can show exactly what changes for each data category.
- Region: Record the Azure region your tenant uses today, because a replacement that stores data elsewhere needs its own approval.
- Operator responsibilities: Under SaaS, TOPdesk operates the database, search and patching. Each of these moves to your team or to a provider you contract.
- Attachments and history: Include attachments, person records and audit history in your data map, since these often hold personal data.
- Termination terms: Confirm the data copy process and the post-termination backup window with TOPdesk in writing, since deletion timing shapes your plan.
- Assurance material: Gather the reports and documents TOPdesk provides to your procurement team, then map which of your own controls they support today.
Ask TOPdesk for its current assurance documents and the terms that govern data location before you settle the target hosting model.
GLPI is self-hosted on your own servers or in your cloud account, so the database, file store and agent traffic stay under your control. The README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs for GLPI 11.0 list older minimums, so confirm the versions against the release you deploy. Only MySQL and MariaDB are supported for the database, which narrows the database controls you need to document. The GLPI installation prerequisites describe the web server setup.
- Database operation: Your team owns MariaDB or MySQL backups, encryption and access. The glpi.key and glpicrypt.key files need the same protection as the database because they are required to read stored secrets.
- Authentication order: GLPI checks the internal database, then LDAP, IMAP and external methods such as REMOTE_USER, so confirm which source is authoritative for each user group.
- Inventory data: GLPI Agent collects hardware and software inventory and can run network discovery, which brings device data into your residency scope.
- Plugins and updates: Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so change records should cover them.
- Hosted option: Teclib' offers GLPI Network in public and private cloud, which brings the operator and location questions back into play.
Document where the database, file store and agents sit, and confirm with your provider which party could access each of them.
What each option costs over time
TOPdesk bundles hosting, updates and support into a per-agent subscription that recurs. Zammad removes the license fee but moves hosting, database services, backups, upgrades and staff time to your budget, with optional support subscriptions on top. The cards below separate one-time setup from recurring spend so you can build a like-for-like comparison.
TOPdesk per-agent subscription
This is the recurring line that covers the license, hosting, updates and vendor support in one fee. The per-agent basis means cost moves with the number of people who work tickets, not with the number of requesters. Ask TOPdesk for the agent count tier, the included regions and what is excluded from support before comparing it with self-hosted totals. Confirm whether the quote includes data export and any post-termination backup period.
Zammad support subscriptions
Zammad's software has no license fee for self-hosted use. The optional Business, Enterprise and Corporation support subscriptions are recurring and priced per year at 2,999 EUR, 5,999 EUR and 9,999 EUR respectively, according to Zammad's pricing page. Choose a tier by how much vendor response you need, not by feature access. Confirm what each tier covers before signing.
Servers and database services
Zammad stores content in PostgreSQL 15 or newer and requires Redis 7 or newer for realtime communication, so you carry hosting for the application, database and cache. These are largely recurring cloud or hardware costs, and they grow with agent count, ticket volume and attachment storage. Your team or your implementation partner must size the environment and set high availability. Ask for a sizing estimate tied to your own ticket volumes.
Search and multi-instance caching
Elasticsearch is optional but strongly recommended for faster search, reporting and attachment content search, which makes it a practical recurring component for a busy desk. Memcached is needed when you run multi-instance deployments such as containers or cluster nodes, while a single installation can use the file system cache. Each added node or index adds hosting and patching work. Confirm which of these your architecture needs before estimating infrastructure.
Backups and recovery testing
TOPdesk backs up the hosted service as part of the subscription. With Zammad you own the backup schedule for PostgreSQL, attachments and configuration, plus periodic restore tests. This is recurring operational work and a storage cost that scales with retained history. Ask your implementation partner for a written backup and restore runbook, and confirm retention periods your compliance team requires.
Upgrades and staff time
Zammad ships minor releases and security releases on parallel lines, such as 7.2 and 6.5.5 in October 2026, so you need a recurring routine to test and apply them. Staff time for administration, third-party login setup, migrations and user support is usually the largest recurring cost and the one TOPdesk's subscription otherwise absorbs. Set a monthly patch window and name an owner, then cost that time honestly against the subscription.
How a move from TOPdesk to Zammad is planned
The sequence turns a TOPdesk ticketing desk into a tested Zammad instance with agreed scope, reconciled data and a controlled switch-over, so each step produces evidence the business can sign off.
Request a complete data copy from TOPdesk
Your TOPdesk administrator asks TOPdesk Support in writing for a full copy of the service desk data, including incidents, attachments, persons, operators, groups and knowledge base articles. Confirm the format, whether attachments are included and the date of the copy, since TOPdesk documents the scope of its exports and backups. Store the copy in a restricted location under your retention rules. This step is done when you hold the copy, have opened it read-only and confirmed that record counts match what the TOPdesk user interface shows.
Inventory ticket types, attachments and users
Your service desk lead and a TOPdesk power user catalog the data: request types, categories, statuses, priorities, custom fields, escalation rules, email templates, operator and customer accounts, groups, and the size and type of attachments. Record which of these are used daily and which exist only in old records. Mark items that have no direct Zammad equivalent, such as facility or shared service objects. The output is a field inventory that maps each TOPdesk element to a Zammad object or flags it as dropped.
Decide what to migrate and what to archive
The business owners decide which open tickets move, how much closed history is kept, which departments and channels are in scope, and how long archived TOPdesk data must remain accessible. Agree which knowledge base articles are rewritten or imported, and which reports must be recreated in Zammad. Because a Zammad migration runs all or nothing on a new instance, decide the scope before any import is built. Done when the signed scope lists included and excluded data, with an owner for each decision.
Choose the import path for TOPdesk data
Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk only, so TOPdesk data usually needs an import through the Zammad API or custom development. The Zammad migration documentation describes the existing migrators and their limits: one source system per migration and no partial runs. Ask your implementation partner or Zammad for the import approach in writing. For object mapping ideas, the TOPdesk to GLPI migration guide covers many of the same TOPdesk structures, though Zammad's model differs. Done when the import design is written and reviewed.
Build and configure the new Zammad instance
The platform team installs Zammad on a new instance using the Docker Compose or Helm packages, with PostgreSQL 15 or newer, Redis 7 or newer and Nginx or Apache as the reverse proxy. Decide on Elasticsearch for search and reporting, which Zammad treats as optional but strongly recommended, and Memcached if the deployment runs several instances. Configure groups, roles, mail channels, the portal and SSO through SAML, OpenID Connect or another supported provider. Confirm internally who supports Kubernetes-specific issues, since Zammad covers only the application there. Done when a staging instance passes functional checks.
Test the import and reconcile the results
Run the import into a fresh staging instance and compare counts by ticket type, status, customer, operator and attachment against the TOPdesk copy. Sample tickets with long histories, large attachments and special characters, and check that timestamps, owners and SLA-relevant states are correct. Because a failed run cannot be patched in place, fix the import logic and repeat the full import on a new instance until the results match. Done when the reconciliation report is signed by the process owners and the import has been repeated successfully.
Run a parallel cut-over and retire TOPdesk
Switch inbound email, the portal and chat channels to Zammad in a controlled window while TOPdesk remains available as a read-only reference. Confirm mail routing, notifications, SSO logins and the knowledge base with a test group of agents before opening the cut-over to all users. Agree with TOPdesk how access and archived data are handled after termination, and confirm that you hold the archive your retention policy requires. Done when the cut-over checklist is complete, operators have been trained and the archive is verified.
Questions buyers ask before switching from TOPdesk to Zammad
What drives the total cost of moving from TOPdesk to Zammad?
Self-hosted Zammad has no license fee, so the cost sits in infrastructure, people and optional support. Recurring costs include servers or cloud capacity, PostgreSQL 15 or newer, Redis 7 or newer, and Elasticsearch, which is optional but strongly recommended for search and reporting. Multi-instance deployments also need Memcached. One-time costs include planning, migration, integrations and configuration. Staff time for patching, backups and upgrades recurs. Optional Zammad support subscriptions are listed at 2,999 EUR per year (Business), 5,999 EUR per year (Enterprise) and 9,999 EUR per year (Corporation) on the Zammad pricing page. Ask any quote to separate one-time from recurring items and to state who operates each tier.
How long does a TOPdesk to Zammad migration take?
The duration depends on the scope, and no fixed timeline applies to every team. The main drivers are the number of tickets and attachments, the number of agents and requesters, the number of mailboxes and channels to connect, the identity integrations, and how many custom mappings the data needs. Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk only, so a TOPdesk import usually needs custom work through the Zammad API or custom development. Each migration is all or nothing and runs on a new instance. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so a quote should state the assumptions behind the schedule and the export formats TOPdesk can provide.
What must our staff provide during a Zammad implementation?
Your staff provides the decisions and access that only your organization holds. Expect to supply:
- Named owners for each mail domain, chat channel and customer portal
- Access to the hosting platform, network, DNS, TLS certificates and backup storage
- Identity provider access for SAML, OpenID Connect or Microsoft and Google sign-in
- An export from TOPdesk, plus a TOPdesk administrator who can answer questions about its data
- Process owners who define categories, priorities, queues, SLA rules and roles
- Testers from each department who check real ticket flows before cutover
Settle these owners early. Missing decisions about roles and queues cause more rework than technical issues do.
Can our internal team implement Zammad without an implementation partner?
A capable internal team can implement Zammad, provided it has skills in Linux administration, PostgreSQL, Redis, a reverse proxy such as Nginx or Apache, and the deployment method you choose. Zammad documents package installation, Docker Compose and a Kubernetes Helm chart. On Kubernetes, Zammad support covers only the application, so your team must own cluster issues. The harder part is often ongoing ownership: backups, restore tests, patching, monitoring and migration planning. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own environment under a written, fixed scope, and it offers retainers for ongoing support. Compare the internal effort with that scope before you decide.
Does Zammad replace TOPdesk asset and change management?
Zammad covers the ticketing desk well, but it does not replace TOPdesk's asset and change management, and that gap is the main reason some teams choose GLPI instead. Zammad is strongest for email, chat and portal channels, a knowledge base and reporting. If your TOPdesk use depends on configuration items, asset lifecycles or change approvals, GLPI covers ITIL incident, problem, change and service level management, asset inventory, configuration management and contract management under GPL-3.0. Some organizations run Zammad for customer and departmental requests beside GLPI for IT operations. Confirm each TOPdesk workflow against the current Zammad and GLPI documentation before you commit to a design.
How are Zammad upgrades and security releases handled?
On a self-hosted installation, your team or your operator applies every upgrade and security release, so the schedule belongs to you. Zammad 7.2 was released on 23 September 2026 as a minor release. Security releases followed on 6 October 2026 (7.2.1) and 8 October 2026 (7.2.2), and security fixes for the 6.5 line shipped as 6.5.5 on 15 October 2026. Plan for a staging environment, a backup before each change and a rollback path. Ask in any scope how upgrades, security patches and test cycles are handled, who approves each change, and what support is included. The Zammad releases page is the place to track new versions.
Does Zammad support single sign-on with our identity provider?
Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. Sign-in configuration affects who can reach the service desk, so it belongs in the security review. Check how your identity provider maps groups to Zammad roles, how new agents are provisioned and removed, and how break-glass administrator access is kept. Confirm the exact provider settings in the Zammad third-party applications documentation and test them in staging before cutover. Access controls on the database, backups and reverse proxy need the same review.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For TOPdesk vs Zammad, we start by separating the ticketing desk workload you want to keep from the asset and change processes you may need to keep elsewhere, so the decision rests on your own requirements.
How we scope
- Written scope agreed before work starts, covering channels, queues, roles and reporting needs
- Inventory of TOPdesk ticket categories, mail flows, portal forms and knowledge base content in scope
- Gap register listing asset, change and CMDB functions that Zammad does not cover and their owners
- Decision on whether Zammad alone, GLPI alone or a split design fits your processes
How we build
- Deployment on your own servers or cloud account using Zammad's documented packaging options
- PostgreSQL, Redis, Elasticsearch and reverse proxy configured and sized to your ticket volume
- Authentication connected to your identity provider through SAML or OpenID Connect
- Mail channels, portal, knowledge base and reporting configured and tested against sample tickets
How we hand over
- Migration plan from TOPdesk exports, including which history is imported and which is archived
- Test migration run on a non-production instance, with results and exceptions documented
- Runbooks for backups, updates, security patches and restoring the service
- Admin training and written documentation delivered to your operations team at handover
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Periodic review of Zammad release notes, including security releases, with patching plans
- Compliance evidence support for your own assessors, without issuing audit reports or certifications
- Reassessment of the asset and change gap if your processes or the Zammad roadmap change
