GLPI vs Zammad: which desk fits internal IT and which fits customers
GLPI suits an internal IT desk tied to assets and ITIL processes, while Zammad suits an external-facing desk with omnichannel ticketing. The decision turns on who files the requests. If the requesters are employees who need laptops, licenses, network changes and change approvals recorded against configuration items, GLPI's ticketing, problems and changes sit next to native asset management. If the requesters are customers arriving by email, web form, chat or phone, and the desk must reply across those channels under one ticket view, Zammad is the closer fit.
Asset and inventory depth is the second test. GLPI's native inventory comes from the GLPI Agent, and the documentation places network discovery and SNMP inventory in the separate GLPI Inventory plugin, so confirm that discovery scope is covered before you commit. Zammad is not built as a CMDB, so if your auditors expect device-to-ticket traceability, plan that data elsewhere. Identity is the third test: check which single sign-on and directory options each edition or plugin provides in the current release notes, and confirm them with the vendor rather than assuming parity.
Finally, decide who runs the platform. Zammad's pricing page states that self-hosted customers handle updates, backups and availability, and it lists self-hosted support plans in euros per year, while GLPI is GPL-3.0-or-later with commercial subscriptions from Teclib'. Zammad also depends on PostgreSQL 15 or newer, Redis 7 or newer, and Elasticsearch for usable search, so budget for those components. Ask each vendor for a written quote covering support tier, upgrade effort and the plugins your scope needs, and have DeployOpen cost those items against your environment.
GLPI vs Zammad by scenario: which desk fits which team
This table maps common desk scenarios to the platform that fits each one better, with the condition under which the other platform would win. Read it by matching your team's primary requester (internal staff or external customers) and whether change and problem management are required. Most decisions turn on those two questions.
| Scenario | Better fit | Why | When the other platform wins |
|---|---|---|---|
| Internal IT service desk that must track hardware and software assets | GLPI | GLPI pairs ITIL tickets, problems and changes with asset management and native inventory from the GLPI Agent, so tickets link directly to the devices and software they concern. | Zammad wins if the asset register lives elsewhere and the desk only needs ticket handling with a light CMDB link. |
| Customer support queue fed by email and chat | Zammad | Zammad is built around omnichannel ticketing for external requesters, with a shared inbox model that suits high message volume from customers. | GLPI wins if the queue is really internal staff requests that happen to arrive by email and need asset context. |
| Mixed desk serving both staff and external customers | Zammad | Zammad handles external requesters and internal agents in one ticket model, while GLPI's strengths sit mostly in internal IT workflows and inventory. | GLPI wins if customer contact is rare and the desk is mainly an internal IT function with a small external intake. |
| Team that must track changes and problems under ITIL practice | GLPI | GLPI handles ITIL tickets, problems and changes as first-class records alongside assets, which supports a structured change and problem process. | Zammad wins if change control is light and the team mainly needs fast ticket resolution with customer communication. |
| Network discovery and SNMP inventory of switches and printers | GLPI | GLPI's network discovery and SNMP inventory depend on the separate GLPI Inventory plugin, so discovery is part of the GLPI design rather than a bolt-on to a ticket tool. | Confirm the plugin's current state and support with Teclib' and your own test environment before choosing GLPI for discovery. |
| Small team that needs a fast customer-facing setup with minimal asset tracking | Zammad | Zammad's focus on ticket handling and channels keeps the setup centred on requesters and response, with fewer CMDB concepts to model. | GLPI wins if the team expects to grow into asset and license tracking within the same year. |
| Compliance evidence that depends on asset ownership and change history | GLPI | Linking tickets, changes and inventory records in one platform makes it easier to show which asset was affected by which change. | Zammad may suit if the evidence is ticket-based and asset records are managed in a separate CMDB or system of record. |
How GLPI and Zammad are built and what that means for operations
GLPI and Zammad solve different problems, and they are built differently. The choices below shape who runs the platform, which services must stay healthy, and how much routine work lands on your team each month. Read them before you commit to either product.
GLPI's data model centers on assets
GLPI links tickets, problems, changes and assets in one database, so a ticket can point to the laptop, server or license it concerns. The GLPI Agent, available since version 10, feeds native inventory into that model. Network discovery and SNMP inventory need the separate GLPI Inventory plugin, so ask your team to confirm which device types you must discover and whether that plugin fits your change control.
Zammad's PostgreSQL and Redis dependencies
Zammad requires PostgreSQL 15 or newer and Redis 7 or newer. Your database team owns backups, replication and version upgrades for PostgreSQL, and your platform team owns Redis availability. Confirm that both services already meet your standards before you size the deployment, because they become part of the helpdesk's uptime path.
Elasticsearch is optional but shapes search
Elasticsearch is optional for Zammad, but without it search is very limited. Adopting it means a second stateful service to provision, patch, back up and monitor. For a service desk where agents search ticket history daily, decide early whether you will run it, and ask the vendor which Elasticsearch versions your Zammad release supports.
Upgrade cadence and release handling
GLPI published 12.0.0 on October 7, 2026, while 11.0.11 and 10.0.28 remain in parallel release lines, so you must choose a major line and plan its support window. Zammad 7.2 shipped on September 23, 2026, followed by the 7.2.2 security release on October 8, 2026. Test each security release in staging, and confirm with each vendor how long a given line receives fixes.
Self-hosting versus vendor hosting
Zammad's pricing page states that self-hosted customers handle updates, backups and availability themselves, while hosted plans start from 7 euros per agent per month. GLPI is self-hosted by default, and Teclib' sells GLPI Network subscriptions and cloud hosting. Compare the staff hours for patching and backups against the hosting fee, and ask any vendor for its data location and recovery commitments in writing.
GLPI vs Zammad side by side on the features that decide the choice
This table compares GLPI and Zammad on the features that usually settle the decision, from licensing and ticket processes to inventory, intake channels and search. Read each row against your desk's main audience: internal IT teams weigh the asset and ITIL rows most, while teams serving external customers should focus on intake and customer-facing rows.
| Capability | GLPI | Zammad |
|---|---|---|
| License | GPL-3.0-or-later, maintained by Teclib', which sells GLPI Network subscriptions and cloud hosting | AGPL-3.0, with paid self-hosted support plans and hosted plans from the vendor |
| ITIL tickets, problems and changes | Handles ITIL tickets, problems and changes alongside asset management | Ticketing-focused; confirm whether problem and change workflows meet your ITIL requirements in a test instance |
| Native asset inventory | Native inventory through the GLPI Agent since version 10, tied to the asset model | No native CMDB-style asset inventory is covered by the facts supplied; confirm with the vendor |
| Network discovery | Needs the separate GLPI Inventory plugin for network discovery and SNMP inventory | Not covered by the supplied facts; confirm with the vendor before relying on it |
| Omnichannel ticket intake | Confirm supported intake channels (email, web, other) for your desk in a test environment | Omnichannel ticketing is its core design; confirm the specific channels you need, such as email, chat or social, in a test instance |
| Database prerequisites | Confirm supported database versions against the GLPI documentation for your target release | Requires PostgreSQL 15 or newer and Redis 7 or newer |
| Search dependency | Confirm search performance at your data volume during testing | Elasticsearch is optional, but without it search is very limited |
| Customer-facing features | Designed mainly around internal IT service management; confirm any external requester portal needs | Built for customer-facing ticket handling; confirm portal and branding needs in a test environment |
What GLPI and Zammad license terms and paid editions include
GLPI is licensed under GPL-3.0-or-later. The license governs the code itself: you can run it, study it and change it, and anyone who receives a copy you distribute keeps those same freedoms. The project is maintained by Teclib', which also sells the paid offerings described on the next tab. Those offerings are separate from the license you accept when you download the software.
- Core product: Running the GPL code inside your own infrastructure carries no license fee, so the license itself sets no price.
- Copyleft: Distributed modifications must stay under GPL-3.0-or-later, with source made available to recipients.
- Version line: The project publishes GLPI 12.0.0 alongside maintained 11.x and 10.x releases, so confirm which branch a support agreement covers.
- Project source: The GLPI project site is the starting point for the project's license and documentation.
- Plugins: Plugins are separate works with their own terms, so check the license of every plugin you plan to deploy.
Confirm which branch, plugins and license terms your planned deployment depends on before you finalize the design.
Teclib' sells GLPI Network subscriptions and cloud hosting. These are the paid routes organizations compare when they want vendor-backed service for upgrades, support or hosting. Buying a subscription does not change the license terms, so the choice is an operating decision about who runs the platform day to day.
- GLPI Network: A subscription from Teclib' that you should evaluate against the services it actually includes. Confirm the support scope, response commitments and update access each tier provides.
- Cloud hosting: Teclib' can host the platform, which moves day-to-day operations and backups to the vendor under contract.
- Inventory plugin: Network discovery and SNMP inventory depend on the separate GLPI Inventory plugin, so include that dependency in your cost comparison.
- Cost drivers: The subscription tier and any hosting fees are the main recurring items, and a quote should show each one separately.
Ask Teclib' for the written subscription schedule and check whether it covers the plugins your inventory design needs.
Zammad is licensed under AGPL-3.0. Like GPL, it lets you use, modify and redistribute the code under copyleft terms. The AGPL adds a network clause, which matters for a helpdesk because users interact with the system through a browser. Confirm with counsel how that clause applies to your modifications and internal deployment.
- Copyleft: Distributed modifications must remain under AGPL-3.0, with corresponding source provided to recipients.
- Network use: If you modify Zammad and let users interact with the modified version over a network, the AGPL may create source-offer duties. Confirm your position with counsel.
- No license fee: The license carries no charge. Your costs come from hosting, staff time and any paid support you buy.
- Required services: Zammad requires PostgreSQL 15 or newer and Redis 7 or newer. Elasticsearch is optional, but without it search is very limited, so plan for it if search matters to your desk.
Document your modifications and the users who access them so the license review has the facts it needs.
Zammad's pricing page lists self-hosted support plans at 2,999, 5,999 and 9,999 euros per year. Per that page, these are annual fees for the support tier you select. The same page states that self-hosted customers handle updates, backups and availability, so those tasks stay with your own team or implementation partner.
- Support tiers: Three annual levels at 2,999, 5,999 and 9,999 euros, as listed on Zammad's pricing page.
- Hosted option: Hosted plans start at 7 euros per agent per month, also per the pricing page, so the recurring cost scales with agent count.
- Operations staffing: Self-hosting moves updates, backups and availability to your side. Budget that staff time separately from the subscription.
- Quote check: Confirm what each support level includes, the response expectations, and whether the euro figures include or exclude tax.
Compare the self-hosted tier against the hosted per-agent cost at your expected agent count, and request the plan terms in writing.
Both platforms use copyleft licenses, but the trigger points differ. GLPI's GPL obligations attach when you distribute modified copies. Zammad's AGPL obligations can reach users who interact with a modified copy over a network. Your license review should start from how users and third parties access the system.
- Internal use: Changes used only inside your organization generally trigger fewer obligations under GPL than under AGPL network terms. Confirm this with counsel.
- Distribution: Shipping a modified build to customers, subsidiaries or partners counts as distribution under both licenses.
- Custom code: Keep custom integrations in separate modules or plugins where possible, and check their licenses separately.
- Implementation partners: If a partner modifies the code for you, agree in writing who holds each copy and who may share it.
Record each modification, its users and its distribution path before go-live.
What drives the running cost of a GLPI or Zammad desk
The running cost of either desk is set less by the license, which is free for both GLPI (GPL-3.0-or-later) and Zammad (AGPL-3.0), than by who you pay to host, patch, back up and support it. For a self-hosted GLPI installation, the recurring items are the server and database infrastructure, the time an administrator spends on upgrades and testing, and any subscription from Teclib' you choose to buy. For a self-hosted Zammad desk, the infrastructure is larger because Zammad requires PostgreSQL 15 or newer and Redis 7 or newer, and Elasticsearch is optional but search is very limited without it. Each of those services needs a backup, a patch window and someone who can restore them. The one-time costs are the initial build, data migration and integration work, which DeployOpen scopes as fixed-scope projects with written deliverables.
Zammad publishes the vendor support tiers that most directly change the bill. Its pricing page lists self-hosted support plans at 2,999, 5,999 and 9,999 euros per year, and states that self-hosted customers handle updates, backups and availability. Those figures are the vendor's list prices as of the page you should check, and they are the only price points in this comparison. GLPI support comes through Teclib' subscriptions, and you should ask Teclib' for current pricing, the scope of included support and whether the subscription covers the GLPI Agent and inventory components you plan to use. For GLPI, add the cost of the separate GLPI Inventory plugin if you need network discovery and SNMP inventory, because that plugin is not part of the base install. Inventory agent rollout, maintaining agent versions across endpoints, and staff time for ticket operations recur every month regardless of the platform.
When you request a quote from DeployOpen or any other partner, ask for each item to be priced separately: the support tier or retainer, the number of agents and named users, the hosting model (your cloud account, your data center or air-gapped), the database and search services, the inventory and discovery scope, and the upgrade and testing cadence. Ask which items are one-time and which recur, and what changes the recurring number, such as adding agents, adding channels like email or chat, or moving to a new major release. Ask how the quote handles a GLPI major upgrade or a Zammad release that changes its prerequisites. Confirm the current license terms and vendor pricing with Teclib' and Zammad directly, because those can change independently of any implementation scope.
Moving tickets and assets between GLPI and Zammad
This sequence turns a move between GLPI and Zammad into a scoped, tested project that agrees what transfers, how fields and states map, and when the old desk is retired. It works in either direction because the two platforms store tickets and assets in fundamentally different models.
Scope what actually moves
Decide which ticket history, requesters, organizations, assets, attachments and knowledge articles transfer, and which are archived read-only or dropped. Internal IT desks usually need GLPI asset records linked to tickets, while customer-facing desks usually need requester and organization history with fewer assets. Owners from service management, security and the business sign the scope in writing before any export runs. The output is a signed inventory of data classes with a keep, archive or drop decision for each.
Map fields, states and categories
Build a mapping workbook that pairs each GLPI ticket field, status, category, urgency and impact value with its Zammad equivalent, and records every value that has no clean match. ITIL-style problems and changes in GLPI have no direct one-to-one object in Zammad, so decide whether they become linked tickets, tags, or stay in the source system. Confirm the mapping with the desk leads and the auditors who rely on the history. The output is an approved mapping document with an exception list.
Model assets and identities
Decide how GLPI asset records, relationships and inventory data are represented once they leave GLPI, since Zammad is a ticketing system and does not hold a CMDB in the same way. Document which identity source will authenticate agents and requesters in the target, and whether LDAP or SAML groups drive roles. Confirm details of Zammad's directory and authentication options against the current documentation before design is final. The output is an asset disposition list and a written identity design.
Rebuild workflows and integrations
Recreate approval paths, escalation rules, notification templates, SLA-style timers and any connections to monitoring, inventory agents, email gateways or chat tools on the target platform. Rules that ran inside GLPI's ITIL process logic seldom copy across as configuration, so treat each one as a requirement to be built and tested. Run each rebuilt workflow with sample tickets from the pilot group. The output is a tested workflow register where each rule has an owner and a pass result.
Migrate and reconcile a pilot set
Export a representative pilot set, import it into a non-production instance, and reconcile counts, timestamps, requester links, attachments and asset relationships against the source. Record every record that fails or is transformed, and fix the mapping before the full load. Keep the import scripts under version control so that repeated runs produce the same result. The output is a reconciliation report signed by the desk owner, with zero unexplained differences in the pilot scope.
Run both desks in parallel
Operate the old and new desks side by side for an agreed period, routing new requests to the target while open tickets finish in the source. Compare response handling, assignment, escalation and reporting for the same type of request, and log every gap for a fix. Confirm that security monitoring, audit logging and backups cover both systems during this period. The output is a parallel-run log with an agreed cutover decision made by the service owner.
Cut over and retire the old desk
Freeze the source desk to new work, run the final delta load, and switch intake channels such as email addresses, portals and integrations to the target. Keep the source in read-only mode under restricted access for the retention period set by your records policy, then decommission it with documented data disposal. Verify that archived copies remain retrievable for audit requests. The output is a decommission record that names the retained archive, its access controls and its owner.
Where GLPI and Zammad implementations usually run long
The longest GLPI and Zammad projects rarely stall on installation. They stall on data and decisions made before go-live. For GLPI, the biggest schedule risk is asset data quality: the inventory rollout depends on deploying the GLPI Agent to every endpoint, and if network devices, printers or appliances must be found by discovery, the separate GLPI Inventory plugin needs its own rollout and testing. Duplicate hardware records, missing owners and inconsistent location or model fields then surface during change and problem work, when they are expensive to fix. Ask the vendor or your partner to confirm which discovery methods your environment needs, how many assets are in scope, and who signs off the data model (asset types, custom fields, and entity hierarchy) before import begins.
For Zammad, the usual drivers are the number of channels and the routing rules attached to them. Each inbound channel (email addresses, web forms, chat, social or phone integrations) needs its own configuration, mailbox handling and testing, and each group, role and trigger added on top multiplies the test matrix. Identity integration is a separate workstream: confirm which sign-in method your directory supports and how agent roles map to groups before go-live. Search is a common surprise. Zammad requires PostgreSQL 15 or newer and Redis 7 or newer, and Elasticsearch is optional, but the prerequisites documentation says search is very limited without it. Decide early whether Elasticsearch is in scope, because adding it later means indexing, sizing and performance testing on a live system. Self-hosted support plans, which the Zammad pricing page describes as covering support while the customer handles updates, backups and availability, should be scoped against the team that will carry those tasks.
Before committing to a timeline, ask for a written list of assumptions covering asset counts and data sources, the channel inventory, the workflow and approval design, the identity provider and role mapping, the search decision, and the training audience. Also confirm who owns each item, since most overruns come from work that nobody was assigned. Training is often the last line item and the first to be cut: plan sessions for agents, approvers and requesters separately, and budget time for a pilot group to find routing mistakes. Any duration in a proposal should trace back to these inputs. If a quote cannot name them, treat the schedule as provisional. Illustratively, a desk with a handful of channels and a clean directory will move far faster than one with many mailboxes, legacy asset data and a new Elasticsearch cluster, so the scope document should say which of those applies.
GLPI vs Zammad questions buyers ask before hiring help
How much does a GLPI or Zammad implementation cost?
The software itself is free to use: GLPI is GPL-3.0-or-later and Zammad is AGPL-3.0, so the implementation bill is mostly labor, infrastructure and support. Zammad's pricing page lists self-hosted support plans at 2,999, 5,999 and 9,999 euros per year and hosted plans from 7 euros per agent per month. Those are vendor subscription figures, not the cost of building your desk. The main drivers are agent and asset counts, integrations, custom workflows, data migration, hosting and availability design. Ask for one-time costs (discovery, configuration, migration, hardening) listed separately from recurring costs (hosting, support plan, upgrades, retainers), with the assumptions behind every count.
How long does a migration to GLPI or Zammad take?
No supplied source gives a migration duration, so treat any number as something to confirm within a written scope. The drivers are the volume and age of tickets and assets, how much history must carry over, the number of source systems, custom fields, and whether the desk is changing its processes as well as its tool. A reasonable plan runs in phases: data mapping, a test import, a cutover date and a tested rollback. Ask the implementer to name the deliverables and acceptance criteria for each phase. DeployOpen plans most engagements as fixed-scope, so the timeline follows from the scope agreed in writing before work starts.
Can an internal team run GLPI or Zammad without outside help?
Many teams run both platforms in-house, but the work is ongoing rather than a one-time project. Zammad's documentation requires PostgreSQL 15 or newer and Redis 7 or newer, and its pricing page states that self-hosted customers handle updates, backups and availability. GLPI brings its own upgrade, database and agent management. Confirm that you have staff for patching on the current release cadence, for example Zammad 7.2 on September 23, 2026 and 7.2.2 on October 8, 2026, or GLPI 12.0.0 on October 7, 2026. Also confirm backup restore testing and on-call coverage. Outside help can cover planning, hardening, upgrades and support inside your own infrastructure, or you can keep that work in-house.
Which service desk fits a mixed internal IT and customer team?
Choose GLPI when the desk mainly serves internal IT, with assets, inventory and ITIL processes at the center of every request. Choose Zammad when external customers submit requests through email, web forms or other channels and need a customer-facing view. A mixed team usually needs both a service desk and a customer queue, so decide by which population generates most tickets, who must see them, and whether asset context is needed on every request. Ask the implementer to show how queues, groups and roles would be configured, and how internal and external requests would be kept separate. Settle this scoping question before the tool is chosen.
Is Elasticsearch required to run Zammad?
No, Elasticsearch is optional, but search is very limited without it. Zammad's software prerequisites require PostgreSQL 15 or newer and Redis 7 or newer, with Elasticsearch listed as optional. Whether you need it depends on how often agents search ticket history and attachments. Adding it means another service to host, size, patch, back up and secure, which adds operating effort and cost. Write your search requirements down, decide on Elasticsearch based on them, and confirm version compatibility against the current vendor documentation before deployment.
Do I need a paid GLPI subscription for inventory and discovery?
Basic inventory does not require a subscription. According to the GLPI documentation, native inventory comes from the GLPI Agent, available since version 10, while network discovery and SNMP inventory need the separate GLPI Inventory plugin. Check which devices must be discovered, such as switches, printers and network hardware, and whether agents can be deployed to every endpoint. Confirm plugin compatibility with the GLPI version you select, since GLPI 12.0.0 was published on October 7, 2026. Ask the quote to list each inventory method, the systems it covers, and who installs and maintains the agent and plugin.
What should a quote for GLPI or Zammad include?
A useful quote states the written scope, deliverables and acceptance criteria before work begins. Ask for the platform version and editions targeted, the number of agents, users, assets and integrations, the migration sources and data volumes, and the hosting prerequisites, including PostgreSQL, Redis and any optional Elasticsearch. Also ask for hardening and backup design, documentation, training, handover, and an explicit list of exclusions. Separate one-time work from recurring items such as support, upgrades and testing retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen also does not issue audit reports, so compliance readiness work is scoped as preparing systems and evidence for an independent assessor.
How DeployOpen helps choose, implement or migrate a GLPI or Zammad desk
DeployOpen starts by confirming whether the desk serves internal IT or external customers, then plans the platform inside your own infrastructure. Every engagement is fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we scope
- Confirm whether the desk serves internal IT staff, external customers or both before choosing a platform path.
- Document the asset sources, identity provider, channels and integrations the written scope must cover.
- Agree in writing what is migrated from any existing ticketing tool and what is retired or kept read-only.
How we build
- Deploy GLPI or Zammad in your cloud account, data center or air-gapped network, with its database and search prerequisites.
- Configure identity integration, roles, queues or ITIL workflows, and inventory collection to match the agreed design.
- Test ticket flows, permissions and backups in a staging environment before any production cutover.
How we hand over
- Deliver runbooks for upgrades, backups, restores and the search index, written for your own operations staff.
- Document configuration, role mappings and integration decisions so they can be audited and reproduced later.
- Walk your administrators through daily operation and record the handover against the written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Ask any provider which upgrade and security-patch responsibilities sit with them and which stay with your team.
- Request a quote built from the written scope, which sets out who pays for licenses, hosting and vendor support.
