GLPI vs Zammad: which one fits your service desk
If your desk serves your own employees and manages your own estate, GLPI suits internal IT: it covers ITIL tickets, problems and changes alongside asset management, with native inventory from the GLPI Agent. If your desk serves external customers across several channels, Zammad suits customer-facing omnichannel ticketing better. The decision turns on who the desk serves, and only secondarily on feature lists. Start by writing down whether your requesters are staff who expect asset records behind every ticket, or customers who expect fast, multichannel conversations with a service team.
Three secondary factors then decide the rest. First, asset depth: if you need hardware, software, licenses and contracts linked to incidents and changes, GLPI's asset-centric model is the more natural fit, and network discovery and SNMP inventory require the separate GLPI Inventory plugin. Second, identity integration: confirm which directory and login methods you need, since GLPI tries internal database, LDAP, IMAP and REMOTE_USER authentication in a fixed order, while Zammad supports SAML, OpenID Connect and several provider logins. Third, operations: Zammad requires PostgreSQL 15 or newer and Redis 7 or newer, and Elasticsearch is optional but strongly recommended for search. GLPI runs on MySQL or MariaDB with PHP 8.2 or newer for version 11.0, so your database team may already have a standard for one stack.
Before you commit, ask your team to confirm the database standard, the identity provider, the agent count and the channels customers actually use. Then pick a pilot queue and run a real migration sample. Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, so check whether your current system is covered or needs API-based import. Also plan for updates: GLPI suspends plugins after a new version is detected and needs them reactivated after major updates, and self-hosted Zammad leaves updates, backups and availability to you, according to its pricing page. Confirm these tasks in the written scope before comparing quotes.
Which platform fits which scenario
This table maps common desk types to the platform that fits better and the condition that makes that call hold. Read each row against your own users: whether requests come from staff managing an asset estate or from external customers arriving by email and chat. The main takeaway is that the audience of the desk, more than feature count, decides between the two.
| Scenario | Better fit | Condition under which the call holds |
|---|---|---|
| Internal IT running a CMDB-style asset estate | GLPI | Hardware and software inventory, contracts and ITIL problem and change records must live in one tool, and you want native inventory from the GLPI Agent. Network discovery and SNMP need the separate GLPI Inventory plugin. |
| External customers contacting support by email and chat | Zammad | Requesters are outside your organization and channel coverage matters more than asset records. Zammad is built around omnichannel ticketing, and the desk does not need to track devices. |
| Mixed desk: internal staff and external customers | Split or confirm | If one desk must serve both groups, decide which workflow owns the queue. Confirm in each product whether the requester experience and asset linkage meet both groups' needs before choosing one tool. |
| Team already running Znuny or OTRS ticketing | Znuny, unless assets matter | Existing workflows, templates and staff skills favor staying on Znuny. Choose GLPI only if the move is justified by a need for native asset and ITIL process coverage, and plan the migration effort explicitly. |
| Small team that needs only ticket handling for a single queue | Confirm with a pilot | Both platforms can run ticket queues, so the decision depends on the surrounding stack. Test your required channels and reporting in a pilot before committing. |
| Desk that needs Elasticsearch-backed search and reporting | Zammad | Zammad documents Elasticsearch as optional but strongly recommended for faster search, reporting and attachment content search. Plan to run the extra service and its operating effort. |
| Environment that already runs PostgreSQL and Redis | Zammad | Zammad requires PostgreSQL 15 or newer and Redis 7 or newer. Teams with that stack and no MySQL or MariaDB commitment find Zammad's prerequisites easier to absorb. |
| Environment standardized on MySQL or MariaDB | GLPI | GLPI supports MySQL 8.0 or MariaDB, and its documentation says only these two databases are supported. Confirm your PHP and web server versions against the current GLPI prerequisites. |
How GLPI and Zammad are built and deployed
GLPI and Zammad solve different desks with different plumbing. GLPI runs as a PHP application on MySQL or MariaDB, with inventory handled by agents, while Zammad depends on PostgreSQL, Redis and optional search and cache layers. The cards below cover the components you would run and the operational questions each one raises.
GLPI on PHP and MySQL or MariaDB
GLPI is a PHP application whose tickets, assets and configuration live in MySQL 8.0 or MariaDB. The README lists PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs for GLPI 11.0 list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6. Confirm which version of the requirements applies to the release you plan to deploy, and note that the docs say only MySQL and MariaDB are supported, so a PostgreSQL standard in your estate does not carry over.
Zammad on PostgreSQL 15 and Redis 7
Zammad stores its content in PostgreSQL 15 or newer and needs Redis 7 or newer for realtime websocket communication. Your database team will manage the PostgreSQL side, so confirm that your standard PostgreSQL service meets the minimum version and the backup and failover model before you commit. Redis is an additional stateful service to patch and monitor.
Search layer: Elasticsearch in Zammad
Zammad uses Elasticsearch for faster search, reporting and searching the content of email attachments. It is optional but strongly recommended, and without it search is very limited. Treat it as a second stateful cluster with its own sizing, index lifecycle and upgrade path. GLPI has no equivalent search cluster in the supplied facts, so the operational comparison is different: Zammad adds a component, GLPI adds an agent fleet.
GLPI Agent and GLPI Inventory plugin
The GLPI Agent collects hardware and software inventory on Windows, macOS and Linux and sends it to GLPI. Network discovery and SNMP inventory need the separate GLPI Inventory plugin. Plan the agent rollout, deployment method and plugin lifecycle as part of the project, because inventory accuracy depends on it. Zammad has no inventory role, so this effort only applies if you choose GLPI.
Memcached for multi-instance Zammad
Memcached is needed for multi-instance Zammad deployments such as containers or cluster nodes, while a single installation can use the file system cache. If you plan Docker Compose or Kubernetes with more than one application node, add Memcached to the design from the start. Ask your team whether they already operate it, since it becomes another service in your on-call scope.
Docker Compose, Helm and the Kubernetes boundary
Zammad documents package installation, Docker Compose and a Kubernetes Helm chart. On Kubernetes, Zammad support covers only the Zammad application, not Kubernetes-specific issues, so the cluster, ingress and storage layers remain your responsibility or your integrator's. GLPI also ships an official Docker image with GLPI 12.0.0. Ask each vendor which deployment method its support terms cover before choosing a container platform.
Capabilities compared
This table sets GLPI and Zammad side by side on licensing, data stores, search, inventory, ITIL coverage, migration and login options. Read each row as a question to answer in your own environment, because several capabilities depend on configuration, plugins or the edition you choose.
| Capability | GLPI | Zammad |
|---|---|---|
| License | GPL-3.0-or-later, free to self-host; Teclib' sells GLPI Network subscriptions and cloud hosting | AGPL-3.0; self-hosting has no license fee, with paid self-hosted support plans |
| Database and cache | MySQL 8.0 or MariaDB 10.6 or later for GLPI 11.0; only MySQL and MariaDB are documented as supported | PostgreSQL 15 or newer and Redis 7 or newer; confirm Memcached needs for multi-instance or container deployments |
| Search | Confirm search performance at your ticket and asset volume in your own test instance | Elasticsearch is optional but strongly recommended; without it search is very limited, so plan for it |
| Asset inventory | Native inventory through the GLPI Agent; network discovery and SNMP need the separate GLPI Inventory plugin | Not a CMDB or asset inventory product; confirm whether a separate asset tool is needed for your estate |
| ITIL process coverage | Tickets, problems and changes plus asset, contract and financial management in one suite | Omnichannel ticketing focus; confirm which change, problem and asset workflows your team needs before choosing |
| Migration tooling | Confirm import paths from your current ITSM or helpdesk with the vendor or community before scoping | Migrators for Freshdesk, Kayako, OTRS and Zendesk; other systems need the API or custom development |
| Third-party login | Internal database, LDAP, IMAP and external methods such as REMOTE_USER, tried in that order | SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab among other providers; confirm your IdP setup |
What the license and paid editions cover
GLPI is distributed under the GNU General Public License version 3, so the core ITSM, ticketing, asset and CMDB features can be downloaded, installed and run without a license fee. Teclib' maintains the project and sells GLPI Network subscriptions and cloud hosting on top of it. The free release is the platform itself, not a trial, so a team can build a service desk on it and decide later whether a paid tier is worth buying.
- Community use: The GPL-3.0 release covers the full self-hosted application, with no per-agent or per-asset license charge.
- Self-hosted GLPI Network tiers: Subscriptions start at 100 euros per month for Basic, which covers up to 10 agents and 500 assets, and reach 4,500 euros per month for Enterprise, per the GLPI Network subscriptions page.
- Level 3 support and marketplace plugins: Higher tiers add level 3 support and access to GLPI Network marketplace plugins, which are not part of the free release.
- Public cloud: GLPI Network public cloud costs 19 euros per user per month, according to the same subscriptions page.
- Private cloud: GLPI Network private cloud costs 21 euros per user per month with a 25-user minimum.
Before committing to a tier, ask Teclib' which plugins are Network-only, whether the agent and asset caps are counted the way your environment counts them, and what level 3 support response terms apply. The GPL code is free, but your own staff or DeployOpen time to install, upgrade and secure it is not, and that effort is the main cost of the community route.
GLPI's paid value sits in support depth, Network-only plugins and managed hosting rather than in the core ITIL workflows, which the free release already provides. Each step up is priced by the size of the estate it supports, so the tier question is mostly a question of agent count, asset count and how much vendor backing the service desk needs.
- Basic: Priced at 100 euros per month for up to 10 agents and 500 assets, suited to a small internal IT team.
- Standard and Advanced: Intermediate tiers that raise agent and asset caps and add support coverage, with exact limits to be confirmed on the subscriptions page.
- Enterprise: Priced at 4,500 euros per month, with level 3 support and the full GLPI Network marketplace.
- Recurring cost: Subscriptions renew monthly, so the cost recurs for as long as the tier is held.
- Cloud alternative: Teclib's hosted options move server operation to the vendor, at per-user rates instead of tier rates.
Ask whether a tier change takes effect immediately, whether caps are enforced or only reported, and how a downgrade is handled. Also confirm whether support hours and escalation paths match the internal support model you plan to run.
Zammad is licensed under the GNU Affero General Public License version 3, and self-hosted Zammad has no license fee. The application, including the omnichannel ticketing features, can be installed in your own infrastructure at no software cost. Zammad's company sells support plans for self-hosted installations and a hosted service, so the paid relationship is for operations assistance and availability rather than for unlocking the product.
- No self-hosted license fee: The AGPL-3.0 code is free to run, and the self-hosted route carries no per-agent software charge.
- Self-hosted support plans: Business at 2,999 euros per year, Enterprise at 5,999 euros per year and Corporation at 9,999 euros per year, per the Zammad pricing page.
- Hosted plans: Hosted options start from 7 euros per agent per month, according to the same pricing page.
- Operations responsibility: The pricing page states that self-hosted customers handle updates, backups and availability, so support plans do not transfer that work.
- AGPL obligations: Teams that modify Zammad and offer it to users over a network should review the AGPL-3.0 source-sharing terms with counsel.
Confirm with Zammad exactly what each support plan covers, including response times, the number of named contacts and whether upgrades to new minor releases are included. The recurring cost of the free route is staff time for patching, Elasticsearch, Redis and PostgreSQL operations, which the support plan does not remove.
Zammad's paid tiers add vendor support around a product that is already complete at the license level. The three self-hosted plans scale by annual price, and the hosted option scales by agent count. Because the paid plans do not change core features, the decision turns on how much operational risk the team wants to hand to a vendor and how many agents the desk runs.
- Business: 2,999 euros per year, a fit for a smaller helpdesk that wants a support contract without a large budget line.
- Enterprise: 5,999 euros per year, aimed at larger desks that need more support depth.
- Corporation: 9,999 euros per year, the highest self-hosted support tier listed.
- Hosted seats: From 7 euros per agent per month, so cost grows with the number of agents rather than with a fixed annual fee.
- Shared responsibility: Self-hosted plans leave backups, updates and availability with the customer, so the support tier is not a managed service.
Ask which tier includes help with migrations from other ticketing systems, whether Elasticsearch and Redis troubleshooting is covered, and what the escalation path is when a security release such as 7.2.2 needs to be applied quickly. Those answers decide whether the tier is worth its annual cost for your desk.
Moving between GLPI and Zammad
This sequence moves ticket history, people and asset or channel context from one desk to the other without cutting over before the data and access checks pass. Each step ends with a check the team can verify before the next one starts.
Confirm the mapping with both vendors
Before any export, the team lists every object that must survive the move: open and closed tickets, articles and attachments, customers, agents, groups, roles, SLAs, custom fields, and, on the GLPI side, assets, software, contracts and linked changes. For each object, the team records where it lives in the source and where it should land in the target, then asks GLPI's maintainer (Teclib') and Zammad to confirm the mapping, especially for fields that have no direct equivalent. The output is a signed-off mapping sheet. Zammad's migrators cover Freshdesk, Kayako, OTRS and Zendesk but not GLPI as a source, so the team should ask Zammad whether it will support a custom API import and what that work would involve in writing.
Export and clean source data
The team exports tickets, articles, users and groups from the source system in a format it can script against, and runs a test export on a copy of the production database. Attachments, time entries and status history are checked for completeness because they often need separate queries. Personal data is reviewed against the organization's retention rules before it leaves the source. The output is a test export with row counts that the team reconciles against the source reports for the same period.
Map users, groups and roles
Identities move first because tickets depend on them. The team maps GLPI users and groups to Zammad agents, customers, groups and roles, or the reverse, and decides which accounts are service accounts that should not be migrated. The team also confirms how GLPI's authentication order (internal database, then LDAP, then IMAP, then external methods such as REMOTE_USER) maps to the sign-in path in the target. The output is a user table where every agent has an assigned role and every customer has a single identity, checked against the directory.
Rebuild assets, inventory and channels
Assets do not move as tickets do. In a move to GLPI, the team deploys the GLPI Agent to collect hardware and software inventory and, where needed, sets up the GLPI Inventory plugin for network discovery and SNMP. In a move to Zammad, customer channels such as email addresses, inbound mailboxes and any integrations are rebuilt, because Zammad's focus is customer-facing ticketing rather than asset records. The output is a populated asset register or a configured set of channels, with links from historical tickets to the new asset or customer records where the mapping allows.
Import data and verify the copy
The team runs the custom import into a non-production instance of the target. For Zammad, that import uses the API, and the team confirms that Elasticsearch indexing and Redis-backed realtime features work against the imported data. For GLPI, the team confirms the database and file configuration, including the configuration directory keys, before loading data. Spot checks compare sample tickets, attachments, ownership and timestamps against the source. The output is a verification log with a pass or fail result for each mapped object type.
Reconfigure identity and integrations
Single sign-on, mail routing, notifications and any connected monitoring or change tools are repointed to the target system. The team tests each sign-in path with a real agent account and a real customer account, and confirms that notification emails and webhooks reach the intended recipients. Zammad's third-party login options include SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, and GLPI's authentication order should be checked against the directory the organization uses. The output is a test record for each login path and each integration.
Run both systems in parallel
For a period agreed in advance, new work goes into the target while the source stays readable. The team reconciles new tickets or assets in both systems each day, records any gap, and resolves it before expanding the scope. Parallel running exposes missing mail routes, duplicate customer records and assets that were not picked up by the agent. The output is a daily reconciliation log that shows no open discrepancies for the agreed period.
Cut over and archive the source
When the reconciliation log is clean and the team has signed off, it switches mail routing and sign-in to the target, sets the source to read-only, and takes a full backup of the source database and files. Retained backups are stored under the organization's retention policy. The output is a cutover record with the backup location, the sign-off names and the date, plus a list of known differences that users need to know about.
What drives the running cost of each desk
The running cost of either desk is set less by the licence line than by who carries the operations. Zammad's self-hosted software has no licence fee, and Zammad's pricing page lists self-hosted support plans at 2,999, 5,999 and 9,999 euros per year, with the page stating that self-hosted customers handle updates, backups and availability. GLPI is GPL-3.0-or-later, so the application is free to run, but Teclib' sells GLPI Network subscriptions that add level 3 support and marketplace plugins, priced per the GLPI Network subscriptions page. Your recurring bill is therefore the staff hours spent on upgrades and backups, the database, cache and search infrastructure, and whichever vendor support tier you choose. Ask each vendor, in writing, which of these your quote covers.
Recurring work differs by platform. On GLPI, every update follows the procedure in the installation docs: back up the database, files and the config directory including glpi.key and glpicrypt.key, replace the application files, and run php bin/console db:update. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so each upgrade cycle carries a plugin check. On Zammad, the recurring cost is the security cadence: Zammad 7.2.2 and the 6.5.5 release of October 15, 2026 show fixes shipping on parallel lines, so you must track two version streams and budget patch windows for both. Elasticsearch is optional but strongly recommended, and Memcached is needed for multi-instance deployments, so each added node or search index adds infrastructure to patch and monitor.
One-time costs are concentrated at the start. Migration into Zammad is cheapest where a supported migrator exists (Freshdesk, Kayako, OTRS or Zendesk), and otherwise needs API import or custom development from Zammad. On GLPI, the expensive one-time item is usually the inventory rollout: deploying the GLPI Agent across endpoints and adding the GLPI Inventory plugin if you need network discovery. Request a quote that separates these items, names the data sources to migrate, and states the plugin list you need on GLPI. A quote built from a written, scope-based plan lets you compare the two desks on equal terms, and DeployOpen does not publish a price list, so the scope itself is what you should negotiate.
Questions buyers ask before choosing GLPI or Zammad
Can a helpdesk for internal IT run on Zammad alone?
Yes, Zammad can run an internal IT help desk on its own, but it is a ticketing system rather than an asset register. Its strength is omnichannel ticket handling, customer-style workflows and a clear ticket history. If your IT team also needs hardware and software inventory, licenses, contracts and an ITIL-style change process tied to assets, you will need a second tool or a different primary platform. Confirm with Zammad which asset or CMDB features your edition includes before you assume gaps are closed.
Can GLPI serve external customers as well as internal staff?
GLPI can accept tickets from users and is built around ITIL processes, but it is designed first for an internal IT service desk with assets, contracts and inventory at its center. Serving external customers usually means you must check how requesters are onboarded, how external identities are managed, how the public-facing interface and notifications behave, and whether your customer-support workflow fits GLPI's model. Test a representative customer journey in a pilot before committing, and confirm the details with Teclib' or your implementation partner.
What does Elasticsearch add to Zammad, and what happens without it?
Elasticsearch adds faster search, reporting features and search of email attachment content. Zammad documents it as optional but strongly recommended. Without it, Zammad still runs, but search is very limited, so agents may struggle to find older tickets and reporting becomes harder to rely on. Adding Elasticsearch means an additional service to size, secure, patch and back up, and it becomes part of your operating scope. Ask the team whether search volume and reporting needs justify that work from the start.
How much effort does identity integration take with GLPI and Zammad?
Both platforms support directory-based sign-in, but the effort depends on your identity provider and the number of sources. GLPI's user documentation describes authentication against its internal database, LDAP directories and IMAP mail servers, tried in that order, plus other external methods such as REMOTE_USER. Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. Plan for attribute mapping, group-to-role rules and testing of fallback accounts. Confirm the exact configuration steps for your identity stack in each vendor's documentation.
What does running either platform require from the internal team?
Both are self-hosted, so your team owns the operating work. GLPI requires PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later according to its README, while its installation docs list PHP 8.2 for GLPI 11.0 and say only MySQL and MariaDB are supported, so check the version that matches your release. Its update procedure requires backing up the database, files and config directory including glpi.key and glpicrypt.key, and plugins are suspended after a new version is detected. Zammad requires PostgreSQL 15 or newer and Redis 7 or newer, and self-hosted customers handle updates, backups and availability according to Zammad's pricing page. Staff need skills in web server, database, cache and backup operations, plus a patch rhythm that tracks security releases.
Can our own team implement GLPI or Zammad without outside help?
A capable team can install either platform from the documentation, and Zammad documents package installation, Docker Compose and a Kubernetes Helm chart. The harder work is production readiness: integrating identity, migrating historical tickets or assets, defining workflows and approvals, setting up backups and monitoring, and documenting controls. Zammad notes that on Kubernetes its support covers only the application itself. Assess your team's experience with the database, cache and search components and whether you have capacity to run a pilot before go-live.
How long does migrating to GLPI or Zammad usually take?
The duration depends on the number of tickets, assets, users and custom workflows, the quality of the source data and how many source systems you consolidate. Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, and other systems can be imported through its API or custom development. For GLPI, the work centers on asset and inventory data, which the GLPI Agent can collect from endpoints. Neither vendor publishes a duration in the sources reviewed for this page, so ask each vendor and any implementation partner for a timeline based on your own data volumes and a written scope.
When should we bring in outside help for GLPI or Zammad?
Bring in outside help when the project touches several of these areas at once: identity integration, asset data migration, compliance evidence, high availability or a go-live with a fixed deadline. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside the client's infrastructure, usually under a fixed-scope agreement with written deliverables. Most engagements begin with a scope discussion, and a quote follows from that written scope rather than from a published price list.
Where GLPI and Zammad projects usually run long
Most GLPI and Zammad projects lose time in three places: process design, identity mapping and data cleanup. Both platforms install quickly enough. The slow part is deciding how tickets, approvals and SLAs should behave before anyone configures them, and then moving years of records into a model that matches those decisions. For GLPI, plan the ITIL workflows for incidents, problems and changes, and the OLA rules that apply to each group, before you build them. For Zammad, settle the ticket states, priorities, groups and SLA calendars first, because migrated tickets from Freshdesk, Kayako, OTRS or Zendesk will carry old values that must be mapped or retired.
On the GLPI side, the technical steps are mostly mechanical but unforgiving. Point the web server document root at GLPI's public directory, not the installation root, and enable URL rewriting as the installation docs describe. Before any update, back up the database, the files and the config directory, including glpi.key and glpicrypt.key. Losing those keys can make stored encrypted values unreadable, so confirm the backup can be restored in a test environment. After a new version is detected, plugins are suspended since GLPI 11.0, so budget a reactivation and compatibility check after each major update. Agent rollout is a separate workstream: the GLPI Agent collects hardware and software inventory, and network discovery needs the GLPI Inventory plugin, so pilot both on a sample of endpoints before a full deployment.
On the Zammad side, the setup risk sits in the supporting services. Zammad needs PostgreSQL 15 or newer and Redis 7 or newer, and Elasticsearch is optional but strongly recommended for search, reporting and attachment content, so decide early whether you will run it. Multi-instance deployments also need Memcached. Channel configuration, covering email inboxes, web forms and any chat or social sources, should be tested with real mail flow and not only with test messages. Identity mapping is a common delay point here: confirm how SAML or OpenID Connect attributes map to Zammad roles and groups, and who owns that mapping. Ask any partner quoting the migration to show how it handles agents, customers and organizations that appear under different identifiers in the source system.
Decision risks to check before you commit
The risks below cluster around one question: is the desk serving internal IT or external customers, and what does each platform need around it to run safely. Each card names the condition under which the risk applies and what to confirm before signing.
Customer desk for an asset need
Zammad is built around omnichannel ticketing for customer conversations, while GLPI links tickets to an asset inventory, contracts and ITIL processes. If the main pain is knowing what hardware and software exists, who holds it, and which change affects which service, a customer-first desk will leave that work in spreadsheets. Ask each vendor to demonstrate the asset-to-ticket workflow on your own device types before choosing.
Elasticsearch dependency
Zammad documents Elasticsearch as optional but strongly recommended, and says search, reporting and attachment content search depend on it. Treating it as an add-on often means discovering late that a large ticket archive is slow to search. Size the Elasticsearch cluster, its backups and its upkeep as part of the platform, and confirm the supported versions with Zammad before design.
Kubernetes support scope
Zammad's documentation states that on Kubernetes, support covers only the Zammad application, not Kubernetes-specific issues. If you plan to run the Helm chart on a cluster you operate, the cluster, storage classes, ingress and node patching remain your responsibility. Confirm with Zammad who handles which layer in writing, and whether a DeployOpen scope would cover the cluster itself.
Plugins suspended after upgrades
GLPI's update procedure requires a backup of the database, files and the config directory, including glpi.key and glpicrypt.key, followed by running the database update command. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. If your desk depends on plugins for inventory or workflows, schedule a post-upgrade check and confirm each plugin's compatibility with the target version.
Agent and asset tier caps
GLPI self-hosted subscriptions are tiered by agents and assets, with the Basic tier listed up to 10 agents and 500 assets. Zammad's self-hosted support plans are priced by tier, and its free software has no license fee but no bundled vendor support. Count named agents, managed assets and concurrent helpdesk users for the next three years, then ask both vendors which tier and support level that count triggers.
Migration and integration effort
Zammad ships migrators for Freshdesk, Kayako, OTRS and Zendesk, and other systems require the API or custom development. GLPI has no equivalent migration path listed in the sources reviewed here, so moving from an existing desk or spreadsheet inventory is typically a scripted import. Ask each vendor which source systems they import today, how attachments and history carry over, and who writes and tests the mapping.
How DeployOpen helps you choose and run your service desk
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 cloud accounts, data centers or air-gapped networks. We help you decide whether an asset-centric ITSM suite or an omnichannel helpdesk fits your desk, then build and hand over the one you choose.
How we scope
- Confirm whether the desk serves internal IT staff, external customers or both before any platform is chosen.
- Map existing asset data, approval paths and customer channels to the features each platform must support.
- Agree a fixed scope, deliverables and timeline in writing before work starts, with the quote following from that scope.
How we build
- Size the PostgreSQL, Redis and optional Elasticsearch footprint for Zammad, or the PHP, MariaDB or MySQL stack for GLPI.
- Configure LDAP, SAML or OpenID Connect sign-in and test it against your directory before go-live.
- Set up GLPI Agent inventory or Zammad channel and integration settings, then test them in a non-production environment.
How we hand over
- Document the architecture, configuration, backup and update procedures in a form your own team can run.
- Run migration rehearsals for ticket, user and asset data, with reconciliation reports for each batch.
- Walk your administrators through role design, plugin or add-on governance and the upgrade path for your chosen version.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
- Review each new platform release and security update against your environment before you apply it.
- Confirm with the vendor which support plan, subscription or edition covers the level of help your desk needs.
