GLPI or Znuny: when each platform fits the service desk
Choose GLPI when asset inventory and ITIL processes must live in one suite, so that tickets, problems, changes, contracts and hardware records share a single data model. Choose Znuny when ticket handling for a service desk matters most and you want a mature ticketing engine on a long-term support line. Neither choice is wrong on features alone, so the decision turns on four things: how much of your inventory must come from the platform itself, which database and language stack your operations team already runs, which company will sell you support, and how much customization your own team will maintain over the years.
Start with inventory. GLPI includes native inventory through the GLPI Agent, which has been available since GLPI 10, but network discovery and SNMP inventory need the separate GLPI Inventory plugin. If your team already has a discovery tool or a CMDB elsewhere, Znuny may be the simpler fit for a desk that only needs tickets and a knowledge base. Next, check the stack. GLPI 11.0 requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and says only MySQL and MariaDB are supported. Znuny supports MySQL, MariaDB, PostgreSQL and Oracle, and its README lists Perl 5.16.0 or higher, so confirm which database your DBAs can back up and restore in your environment.
Then examine support and upgrade cadence. Teclib' sells GLPI Network subscriptions, and Znuny GmbH in Berlin provides professional services for Znuny. Ask each vendor, in writing, what level of support applies to your deployment, and whether Znuny LTS 6.5.26 or the current feature line (7.3.8 at the time of research) fits your change calendar. Finally, count the customizations. Plugins in GLPI are suspended after a new version is detected and must be reactivated after major updates, so every plugin on your list becomes a recurring test item. Write that work into your plan before you commit.
Which scenarios favor GLPI and which favor Znuny
This table maps common team situations to the platform that usually fits better, along with the condition that makes the call hold. Read each row as a starting point, then check the condition against your own asset scope, ticket volume, existing OTRS skills and support requirements. Neither platform wins every row, and the right choice depends most on whether you need inventory and ITIL processes in one suite or a mature ticketing engine.
| Scenario | Better fit | Condition under which it holds |
|---|---|---|
| Internal IT that must track hardware, software and contracts | GLPI | Asset inventory is a core requirement, and the GLPI Agent covers the endpoints you need. Network discovery and SNMP inventory need the separate GLPI Inventory plugin, so confirm that scope early. |
| Customer-facing support desk handling external requests | Znuny | Ticket queues, customer-facing workflows and mature ticketing matter more than asset records. Confirm the channels and queue rules you need against the current Znuny documentation. |
| Team already running OTRS Community Edition | Znuny | Your admins, custom modules and Perl extensions already fit the OTRS codebase, so migration effort stays lower. Check each custom extension against the Znuny version you plan to run. |
| Team that needs a long-term stability line | Znuny | You want to stay on a slower, LTS-style release cycle. Znuny publishes a separate LTS line alongside its feature line, so pin the line you choose and plan upgrades against it. |
| Team that wants paid subscription tiers with level 3 support | GLPI | Teclib' sells GLPI Network subscriptions with tiers scaled by agents and assets. Confirm what each tier includes in writing before you rely on it for support. |
| Team that wants support from a vendor that runs the code it hosts | Znuny | Znuny GmbH offers professional services for Znuny. Ask for scope, response terms and the named engineers in a written quote before you assume coverage. |
| Team with a PHP and MySQL or MariaDB stack and limited database options | GLPI | GLPI supports MySQL and MariaDB only, which fits an existing MySQL estate. If you need PostgreSQL or Oracle, Znuny's supported database list is the better match. |
How GLPI and Znuny are built and what that means for operations
GLPI and Znuny both run on Linux with a web server in front, but they differ in language, supported databases and how inventory reaches the platform. Those differences shape patching, backup scope and the skills your staff need. Read each card as a checklist item to confirm in your own environment before you commit.
GLPI's PHP application and agent model
GLPI is a PHP application, and its inventory arrives from the GLPI Agent, which collects hardware and software data on Windows, macOS and Linux and sends it to GLPI. Network discovery and SNMP inventory need the separate GLPI Inventory plugin, so that component is a second moving part to patch and test. Ask your team whether they can operate the agent fleet and the plugin alongside the core application.
Znuny's Perl application on Apache
Znuny is a Perl application, and the README recommends Linux, preferably Debian or Red Hat, with Perl 5.16.0 or higher and Apache 2 running mod_perl2. Staff who troubleshoot the platform need Perl and Apache mod_perl2 experience, which is a different skill set from a PHP team. Confirm that your operations group can maintain Perl module dependencies and Apache configuration on the distribution you standardize on.
Database choice narrows the platform
GLPI supports only MySQL and MariaDB according to its installation docs, with MariaDB 10.11 or later or MySQL 8.0 or later in the current README. Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. If your standard is PostgreSQL or Oracle, Znuny fits and GLPI does not, so settle this before scoping.
Backup scope and update steps
The GLPI update procedure requires a backup of the database, the files and the config directory, including glpi.key and glpicrypt.key, before replacing application files and running php bin/console db:update. Losing those keys can leave encrypted data unreadable, so include them in every backup set. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, which adds a post-upgrade check to your runbook.
Docker option in GLPI 12.0.0
GLPI 12.0.0, published on October 7, 2026, lists an official Docker image among its distribution options. A container image can simplify repeatable deployment, but you still own the database, persistent volumes, the key files and the web server behavior inside it. Ask whether your platform team will run it on your orchestrator and how image updates will be tested before rollout.
Document root and web server footprint
GLPI requires the web server document root to point to its public directory, with URL rewriting that routes requests through index.php, on Apache, Nginx, lighttpd or IIS. Znuny expects Apache with mod_perl2. Either way, misconfigured paths are a common source of exposed files, so include web server hardening and a configuration review in your acceptance tests for both platforms.
What GLPI and Znuny license terms and paid editions include
GLPI is distributed under the GNU General Public License version 3 or later, so the software itself carries no license fee for self-hosting. Teclib' maintains the project and sells GLPI Network subscriptions on top of it. Those subscriptions are a service agreement, not a different code base, and they are the usual route to level 3 support and vendor-supplied marketplace plugins.
- Free core: the community release is GPL-3.0-or-later, and you can run it on your own servers without a subscription.
- Self-hosted tiers: per the GLPI Network subscriptions page, Basic starts at 100 euros per month (up to 10 agents and 500 assets) and Enterprise is 4,500 euros per month, with level 3 support and GLPI Network marketplace plugins.
- Cloud pricing: the same page lists GLPI Network public cloud at 19 euros per user per month and private cloud at 21 euros per user per month, with a 25-user minimum on private cloud.
- Managed service: Teclib' also offers GLPI Network Cloud, which the project site describes with a 45-day free trial.
- Recurring cost: subscriptions recur monthly, so the budget question is whether your agent and asset counts sit inside a tier.
Confirm current tier limits, plugin availability and cloud terms directly with Teclib' before you cost the service.
Znuny is a GPL-3.0 licensed continuation of the OTRS Community Edition 6.0.30 line, which reached end of life in December 2020. The project keeps development going under the same open license, so there is no separate paid edition of the code. What you pay for is professional services from Znuny GmbH in Berlin, along with the release line you choose to run.
- Free code: Znuny is distributed under GNU GPL v3 and can be self-hosted without a license fee.
- Feature line: znuny.org lists Znuny 7.3.8 as a current release in October 2026.
- LTS line: Znuny LTS 6.5.26 is listed as the long-term support release in the same period, for teams that prefer a slower upgrade cadence.
- Paid services: professional services come from Znuny GmbH, and the scope of any engagement is set by contract.
- Documentation: doc.znuny.org keeps separate documentation for the feature version and the LTS version, so you can match docs to the line you run.
Confirm the support window for each line, and the scope and price of any services, with Znuny GmbH before you commit.
Both projects are free to run, but the paid support model differs in shape. GLPI's paid layer is a tiered subscription that bundles support levels and plugins, and it has a cloud option. Znuny's paid layer is service work sold by the maintainer company, which you scope per engagement. Treat the two as different purchasing decisions.
- Who is paid: with GLPI, the subscription pays Teclib' for support tiers and Network-only plugins. With Znuny, the fee pays Znuny GmbH for the services you request.
- Recurring versus one-time: GLPI subscriptions recur every month. Znuny services are usually scoped as projects or retainers, so confirm whether any recurring component exists.
- What drives cost up: for GLPI, agent counts, asset counts and user counts move you between tiers. For Znuny, the number of custom modules, migrations and upgrade work drives the scope.
- Independent options: neither listing above shows that an independent partner also supports the code, so ask each vendor what it will and will not cover.
Ask each vendor for a written statement of support scope, response targets and what happens if you leave the subscription or engagement.
Before you request a quote from either vendor, prepare the counts and requirements that decide the price. The list below is the information each vendor will need to scope a fair proposal, and it applies whether you choose GLPI, Znuny or both. Share the same inputs with each vendor so the quotes compare on equal terms.
- Counts: agents, assets, named users and expected growth over the contract term, so the GLPI tier fit and cloud per-user math can be checked.
- Hosting model: whether you run on your own servers, a private cloud or the vendor's cloud, since this changes which GLPI plans and Znuny services apply.
- Plugins and integrations: which Network-only plugins, LDAP connections or custom modules you need, and who maintains them after go-live.
- Support hours and response expectations: the level of support you need in your own timezone and whether it must be contractual.
- Exit terms: the notice period, data export format and what happens to licenses or services if you stop paying.
Confirm every figure in writing with the vendor, because published prices and tiers can change.
Side-by-side capability and support comparison
This table compares GLPI and Znuny on the points that shape a service desk rollout: license, database and runtime needs, inventory, identity options, release lines and who sells support. Read each row as a checklist item to confirm in your own environment, and use the support row to decide whether you need a vendor contract.
| Capability | GLPI | Znuny |
|---|---|---|
| License | GPL-3.0-or-later, maintained by Teclib', which sells GLPI Network subscriptions and cloud hosting | GPL-3.0, a continuation of OTRS Community Edition 6.0.30 after its end of life in December 2020 |
| Database support | MySQL 8.0 or later or MariaDB 10.11 or later per the README; the install docs list MySQL 8.0 or MariaDB 10.6 for GLPI 11.0 and say only MySQL and MariaDB are supported | MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later |
| Minimum runtime | PHP 8.2 or later for GLPI 11.0; the README on the main branch requires PHP 8.3 or later | Perl 5.16.0 or higher, preferably on Debian or Red Hat, with Apache 2 and mod_perl2 recommended |
| Native inventory | Hardware and software inventory from the GLPI Agent since version 10; network discovery and SNMP inventory need the separate GLPI Inventory plugin | No native inventory module in the supplied facts; confirm whether your Znuny setup needs a separate CMDB or asset tool |
| Ticketing depth | ITIL tickets, problems and changes alongside assets, contracts and financial management, per the README | Ticketing system for customer service, help desk and ITSM, per the Znuny README; confirm change and problem management fit your process |
| Identity options | Internal database, then LDAP, then IMAP, then external methods such as REMOTE_USER, tried in that order | Not covered by the supplied facts; confirm LDAP, SSO and SAML support with the Znuny documentation before design |
| Release lines | GLPI 12.0.0 (October 7, 2026), 11.0.11 (October 1, 2026) and 10.0.28 (September 30, 2026) are current in parallel | Znuny 7.3.8 feature line and Znuny LTS 6.5.26 are the latest releases listed in October 2026 |
| Who sells support | Teclib' sells GLPI Network subscriptions, including self-hosted tiers with level 3 support, and cloud hosting | Znuny GmbH in Berlin provides professional services; ask about support tiers and response terms in writing |
How native inventory changes the GLPI decision
The question to settle first is whether your service desk must also answer what hardware and software you run, and whether those answers should come from the same system that holds the tickets. GLPI bundles both in one product: ITIL tickets, problems and changes sit alongside asset management, and the GLPI Agent, the successor of FusionInventory Agent, collects hardware and software inventory from Windows, macOS and Linux endpoints and sends it to GLPI. Znuny is a ticketing engine for customer service, help desk and IT service management. Teams that run Znuny usually keep inventory in a separate CMDB or asset tool and link configuration items to tickets through an integration they build and maintain.
This matters most when a ticket depends on the asset record. A change request that asks which machines run a vulnerable library, or an incident that needs the owner, warranty status and installed software of a laptop, is answered faster when the asset and the ticket share one database and one permission model. If your team already has a mature CMDB, or asset data lives in a procurement or endpoint management system that the desk will not replace, that advantage shrinks, and the decision turns on the integration effort rather than on the ticket engine. Ask each vendor, or your integration partner, how the asset data is refreshed and who owns the mapping between devices and tickets.
Scope the discovery work before you assume inventory is solved. The GLPI Agent covers the endpoints where it is deployed, but network discovery and SNMP inventory for switches, printers and other devices need the separate GLPI Inventory plugin. Confirm which device classes must be discovered, which network segments the discovery host can reach, and whose team deploys and upgrades the agent. Check the agent and plugin release notes against the GLPI version you plan to run, because GLPI 11.0 suspends plugins after a new version is detected and they must be reactivated after major updates. Those upgrade steps are recurring effort that belongs in the cost comparison alongside the licence terms.
Moving from Znuny to GLPI or the reverse, step by step
This sequence moves a service desk between Znuny and GLPI with ticket history, queues and workflows verified in the target before users cut over. The output is a retired source system and a documented record of what moved, what was rebuilt and what was left behind.
Inventory queues, customers, SLAs and custom fields
The service desk owner and a Znuny administrator list every queue, agent group, customer company, SLA, escalation rule, custom dynamic field and notification template in the current system. Record which items are active, which are dormant and which exist only for one team. The step is done when the inventory is signed off by the service owner and each item has a stated target in GLPI, either a mapped object or a rebuild task.
Confirm target platform and database support
Before any data moves, the platform team checks the target's requirements against the current hosting. For Znuny, the supported databases are MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. For GLPI 11.0, the installation docs list MySQL 8.0 or MariaDB 10.6 with PHP 8.2 or later, and state that only MySQL and MariaDB are supported. Confirm the exact target version and PHP or Perl runtime with the vendor. The step closes with a written compatibility check that names the database engine and version on both sides.
Export ticket history and attachments
The migration engineer exports tickets, articles, attachments and audit history from the source database and file store, keeping ticket numbers and timestamps intact where the target allows it. Sample a set of closed and open tickets with attachments and confirm that each one can be read in an export file. Note that export tooling is often custom work, and that attachment storage and character encoding frequently cause the most rework. The output is a dated export set with a checksum manifest and a sample verification log.
Map queues to GLPI entities and ITIL categories
The service owner maps each Znuny queue and customer company to a GLPI entity, ticket category, or group, and decides how priorities and states correspond to GLPI's ITIL ticket model. Znuny queues are organizational containers, while GLPI separates entities, groups and ITIL categories, so one queue may need to become two or more objects. Document each mapping in a table that the reviewers approve. The step is done when every source queue has one written destination and no ticket type is left without a category.
Import data into a staging instance and rebuild workflows
The team loads the export into a staging GLPI instance, or into a staging Znuny instance for the reverse direction, and rebuilds SLAs, escalation rules, notifications and forms by hand or with plugins that the chosen edition supports. Confirm plugin availability and licensing for each required feature before the build, since GLPI 11.0 suspends plugins after a new version is detected and they must be reactivated after major updates. The step closes when a test script of common tickets passes end to end, including notifications and SLA clock behavior.
Run both systems in parallel for a cutover window
Agents and requesters work in the source system while selected teams test the target with a controlled set of new tickets, and the migration team reconciles counts, owners and attachments daily. Decide in advance which system is the system of record for each queue during the window and how changes made in one are reflected in the other. The cutover is complete when reconciliation shows no unexplained differences and both teams sign off on the final delta import.
Retire the source system and keep the evidence
After cutover, the source system goes to read-only mode, a final backup is taken, and the archive is stored under the retention rules the organization requires. The team then removes integrations, mail routing and scheduled jobs that pointed at the old system. The step closes with a retirement record covering what transferred, what was rebuilt, what was dropped, and where the archived data lives.
Confirm license and support terms before committing
Before the target is chosen and the migration is scoped, the buyer asks the vendor in writing which edition provides the required features, how support is delivered, and what the support lifecycle looks like. For GLPI, confirm whether GLPI Network subscription tiers are needed for the level of support or plugins required, since Teclib' sells those subscriptions. For Znuny, confirm which release line (feature or LTS) the organization will run and who provides paid services. Ask both vendors to put these terms in the quote so that the costs and obligations are known before the first export is run.
What implementing each platform involves and where projects run long
Implementing GLPI starts with the web server layout. The GLPI installation docs require the web server's document root to point at the application's public directory rather than the installation root, with URL rewriting so that requests route through index.php. That works on Apache, Nginx, lighttpd or IIS, but it is a configuration step your web team must get right before anyone logs in. Updates are where GLPI demands discipline: back up the database, the files and the config directory, including glpi.key and glpicrypt.key, replace the application files, then run php bin/console db:update. Losing those key files can make stored secrets unreadable, so treat them as part of the backup set, not an afterthought. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so plan a plugin compatibility check into every major upgrade window.
Znuny is a different kind of install. It runs on Linux, preferably Debian or Red Hat, with Perl 5.16.0 or higher, and Apache 2 with mod_perl2 is the recommended setup per the Znuny README. Your Perl and module versions, the Apache configuration and the database driver for MySQL, MariaDB, PostgreSQL or Oracle all need to match the distribution your team supports, and an administrator who has not run Perl-based web applications before should expect a learning curve. Confirm with Znuny GmbH or the Znuny release page which line (feature or LTS) you will track before you build the environment, because that choice sets how often you patch. Both platforms also need a tested backup and restore routine before go-live, not after it.
Projects usually run long in four places. First, data migration: ticket history, asset records and user accounts rarely map one to one, and GLPI's asset model and Znuny's queue and ticket model each need field mapping decided early. Second, plugin or custom field rebuilds: GLPI plugins and Znuny customizations written for one release may need rework after an upgrade, so inventory every extension before scoping. Third, identity integration: GLPI authenticates against the internal database, then LDAP directories, IMAP and other external methods in that order, and Znuny's directory and single sign-on setup must be verified against your own identity provider. Fourth, staff training, because agents who move between two ticket models lose time in the first weeks. Ask any implementation partner to price these four items separately in the written scope.
What drives the running cost of GLPI and Znuny
Running GLPI or Znuny costs less in license fees than in people, hosting and support decisions, because both are GPL software with no license charge for the community code. The cards below separate who gets paid for each component, which costs are one-time and which recur, and what to put in a written scope before comparing quotes.
Infrastructure and database hosting
Both platforms run on your own servers or cloud accounts, so the hosting bill is yours to carry. GLPI 11.0 documents PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and the README raises the bar to PHP 8.3 and MariaDB 10.11 or later. Znuny supports MySQL, MariaDB, PostgreSQL and Oracle, so the database you already license or staff may decide the cost. Ask for the database and PHP versions the quote assumes, and whether backups and a staging copy are priced in.
Staff skills in PHP or Perl
GLPI is written in PHP and Znuny in Perl, so the recurring labor is a skill set your team may or may not hold. Plugin development, template changes and custom reports on either platform need that skill, and the pool of Perl developers is usually smaller than PHP's. Decide who will maintain the code, and request in the quote either a handover plan or a retained support arrangement covering the language you chose.
Paid support tiers
The community code is free, but support is bought separately. Teclib' sells GLPI Network subscriptions, with self-hosted tiers that set the agent and asset caps and the level of support. Znuny GmbH in Berlin sells professional services for Znuny. Both are recurring. Ask each vendor which support level, response window and instance count the price covers, and whether an LTS line or a feature line is included.
Upgrades and plugin maintenance
Upgrade effort recurs with each release line. GLPI 11.0 suspends plugins after a new version is detected and requires reactivation after major updates, and the update procedure calls for database, file and key backups before running the database update. Znuny's LTS line gives a longer-lived base, but custom code still needs retesting. Ask for the plugin inventory, the upgrade rehearsal in a non-production copy, and who signs off each release.
Edition and agent caps
Caps set the price tier more than features do. GLPI self-hosted subscriptions are sized by agents and assets, with Basic covering up to 10 agents and 500 assets. Zammad-style per-agent pricing is not used by either platform, so count your technicians, endpoints and assets before requesting a quote. Ask how growth beyond the cap is priced, and whether a tier change is prorated or requires a new contract.
Rollout and migration labor
The one-time cost that often exceeds the first year of support is the migration: importing tickets, assets, users and approval workflows from an existing desk, then training staff. Both platforms need LDAP or other directory integration, and the authentication order in GLPI determines login behavior. Request a written migration scope with data mapping, cutover and rollback steps, and a fixed deliverable list, since fixed-scope work is how DeployOpen agrees these items before work starts.
Questions buyers ask before choosing GLPI or Znuny
Does GLPI or Znuny cost less to run over time?
Neither product has a license fee, so the difference comes from people, hosting and support. GLPI's community release is GPL-3.0 and Znuny is GPL-3.0 as well, so the license line does not separate them. The recurring costs that differ are the support contract you choose, the staff hours for upgrades, and any paid plugins. Teclib' prices GLPI Network subscriptions by tier, for example a self-hosted Basic tier at 100 euros per month for up to 10 agents and 500 assets, according to the GLPI Network subscriptions page. Znuny services come from Znuny GmbH, so ask for a written quote from each vendor against the same agent count, asset count and support level.
How much effort does migrating from one platform to the other take?
Migration effort depends mainly on how much history, custom workflow and integration you carry over. Moving tickets, users and assets between two different data models is a project in its own right, and neither vendor's documentation supplied here quantifies it. The work usually includes mapping queues to GLPI entities or Znuny queues, rebuilding notification rules, re-pointing mail channels and reconnecting directory sync. Ask each candidate partner for a written inventory of your ticket types, custom fields, SLAs and integrations before agreeing on scope, and run a pilot import on a copy of the production database.
Can an internal IT team run GLPI or Znuny alone?
A small team with Linux and database experience can run either platform, but the workload differs. GLPI's installation docs require PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, and the GLPI 12.0.0 release is a new major line. Znuny requires Perl 5.16.0 or higher and Apache 2 with mod_perl2 recommended, and its README recommends Debian or Red Hat. Plan for upgrades, backups, plugin compatibility and security patching, and decide who owns each one. If that ownership is unclear, a fixed-scope implementation and handover agreed in writing can close the gap.
Which database should we standardize on for GLPI or Znuny?
Standardize on the database your team already backs up, monitors and patches well, provided both products support it. GLPI supports only MySQL and MariaDB according to its installation docs, with MariaDB 10.11 or later or MySQL 8.0 or later in the current README. Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. If your organization runs Oracle or PostgreSQL as a standard, Znuny gives you more choice, while GLPI fits a MySQL or MariaDB shop. Confirm the exact version your chosen release supports before ordering hardware.
Does Znuny LTS suit a regulated team?
Znuny LTS can suit a regulated team that values a stable release line, but the choice depends on your change-control and vulnerability process. znuny.org lists Znuny LTS 6.5.26 alongside the feature release Znuny 7.3.8 as its latest releases in October 2026, so you can choose between a long-term line and a newer feature line. Ask Znuny GmbH how long each LTS line receives fixes, how security advisories are published, and what support covers. This page does not issue compliance attestations, and any control mapping for your framework should be checked with your auditor.
What does the work need from our side before a project starts?
The work needs named owners, a reviewed inventory of your current service desk, and access to the environment where the platform will run. Expect to supply the ticket volumes and categories, asset sources, directory and mail details, and the list of integrations you need. For GLPI, the GLPI Agent collects inventory, while network discovery needs the separate GLPI Inventory plugin, so confirm whether that plugin is in scope. Most engagements are fixed-scope, so agree the deliverables, acceptance tests and cutover plan in writing before work starts.
How do GLPI and Znuny handle authentication and directory login?
Both support directory-based login, but the mechanisms and the setup effort differ. GLPI's user documentation describes authentication against the internal database, then LDAP directories, IMAP mail servers and other external methods such as REMOTE_USER, tried in that order. Znuny is a continuation of OTRS and is typically configured through its admin settings and Perl-based authentication modules, so confirm the exact modules and the group mapping you need with the vendor. Test single sign-on and group-based roles in a staging instance before you rely on them in production.
How DeployOpen helps choose, implement or migrate between GLPI and Znuny
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so the GLPI or Znuny decision is tested against your environment before anything is installed. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Map which processes need native asset inventory and which need a mature ticketing queue, from your current tools.
- Confirm database engine, PHP or Perl runtime, web server and hosting location before choosing a platform.
- Record licensing, support contracts and the Teclib' or Znuny GmbH support route in the written scope.
How we build
- Stand up a test instance in your environment and confirm the chosen release line and database versions.
- Configure authentication, roles, queues or ITIL workflows, and inventory collection to match your agreed design.
- Test ticket flows, integrations and upgrade steps against a copy of your data before production cutover.
How we hand over
- Document installation, configuration, backup and update procedures, including the GLPI key files or Znuny config backups.
- Deliver migration mapping for tickets, assets and users, with a record of what was moved and verified.
- Walk your administrators through daily operation, plugin management and the upgrade path for your chosen line.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build.
- Plan upgrades around the release lines and support windows you confirm with the vendor.
- Keep the retainer scope explicit so your team knows which changes, fixes and reviews are covered.
