What a GLPI implementation involves
A GLPI implementation turns an open-source IT service management platform into the system of record for tickets, assets and service ownership, installed on servers and in cloud accounts you control. The work is not the installation alone. It is the sequence of design decisions that determines whether the service desk and inventory are usable after go-live: how entities and profiles separate departments and sites, which ticket categories and service levels reflect what your teams actually support, and how the first asset inventory is loaded and checked against reality.
Most engagements cover the same core components. Installation includes the web server, PHP, the database and a document root pointing at GLPI's public directory. Entity and profile design defines who sees which tickets and assets. Ticket categories, priorities and service level agreements, along with the business calendars they depend on, are configured next. The initial asset inventory is seeded through GLPI Agent or import, and email collectors are set up so that mail to a support address becomes a ticket. Plugins are selected and tested, and go-live support covers the first weeks of real traffic. Ask the partner to show which of these items are in the written scope and which are excluded.
What the work includes and what you receive
A fixed-scope GLPI engagement is agreed as a set of work packages with written deliverables. The list below shows what sits inside that scope, so you can compare it with the work your own team would carry.
Platform build on your servers
The build runs on servers or virtual machines you own, with a web server pointed at GLPI's public directory rather than the installation root. PHP and MariaDB or MySQL versions are matched to the GLPI release being installed, so check the prerequisite table for that version before hardware or VM sizing is fixed.
Entity and profile model
Entities, child entities and profiles define who can see and act on which tickets and assets. This design decision shapes every later step, so it is recorded in the design record and reviewed with your owners before profiles are assigned to users.
Ticket categories, request types and SLAs
Categories, request types, service level agreements (SLAs) and operational level agreements (OLAs) are defined against the support model you actually run. Ask for the escalation rules and calendars to be written down, since they drive how response and resolution times are measured.
Asset types and initial inventory
Asset types, locations, statuses and an initial inventory load are configured, and GLPI Agent rollout is scoped separately where needed. Confirm which data sources feed the first load, such as spreadsheets or directory exports, and who signs off the data quality before go-live.
Email collectors and notifications
Email collectors create tickets from inbound mail, and notification templates tell requesters and technicians what changed. Mail server details, mailbox ownership and test messages should be agreed before the build, because collector reliability depends on the mailbox and the cron schedule behind it.
Plugins, backup and cron basics
Selected plugins are installed, tested and documented, and the baseline backup and cron jobs are configured. Ask for the backup scope to cover the database, files and the config directory with its encryption key files, and for a restore test to be recorded before handover.
Administrator training
Administrators and service desk leads are trained on the configured model, with the runbooks used as the reference. Training covers the tasks your owners will repeat, such as profile changes, collector troubleshooting and running the update procedure, so ask which roles and sessions are included in the written scope.
Deliverables and handover
The deliverables are a configured instance, a written design record, configuration exports, test results, runbooks and a handover to your named owners. Scope and deliverables are agreed in writing before work starts, so ask for the acceptance criteria to be listed alongside each item.
What drives cost and duration
This table lists the scope choices that change GLPI implementation effort, explains why each one matters, and suggests how to keep it under control before the build starts.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Entities and profiles | Each entity adds visibility rules, and each profile adds role mapping and access tests that must be verified for every user type. | Start with the entities you need at go-live and a short profile list, then add more through a written change request. |
| Ticket categories and SLA variants | Each category, SLA and escalation path needs its own business rules, notification templates and test cases. | Agree a short category tree and a small set of SLA levels with named owners before design begins. |
| Assets and asset types | More asset types, dropdowns and imported records increase mapping work, field design and validation effort. | Limit inventory to the asset types and fields you will actually report on or act on. |
| GLPI Agent endpoints to configure | Each endpoint type needs an agent configuration, inventory validation and a check that data reaches the right entity. Rollout itself is a separate topic. | Configure a standard template and a pilot group first, then scale using the same configuration. |
| Plugins: marketplace or custom | Each plugin must be checked against your GLPI version. Custom plugins add build, testing and upkeep, and plugins are suspended after updates until reactivated. | Prefer marketplace plugins with documented compatibility, keep the count low, and budget reactivation testing into every update. |
| Email collectors and mail server type | Each collector needs its own mailbox, credentials, parsing rules and failure handling. The mail server type changes the setup steps. | Agree the mail server type and one collector per intake address early, and confirm mailbox access with the mail team. |
| Authentication sources | GLPI tries the internal database, LDAP, IMAP and other methods such as REMOTE_USER in that order. Each source adds mapping and login tests. | Confirm which sources are needed, their order and the group-to-profile mapping before configuring any of them. |
| Hosting layout and environments | A single server is simpler to build than separated web and database tiers. Production, staging and test each need the full stack, and GLPI 12.0.0 requires PHP 8.3 and MariaDB 10.11 or later per the README, while GLPI 11.0 requires PHP 8.2 with MySQL 8.0 or MariaDB 10.6 per the installation docs. | Choose the target GLPI version first, then build each environment from one repeatable configuration with the same PHP and database versions. |
| Data quality and reviewer availability | Messy spreadsheets or records from an older tool add cleansing rounds, and reviewers who are unavailable slow every sign-off step. | Agree sample-based data checks and named internal reviewers with protected time before the build schedule is fixed. |
Project phases and what each produces
The sequence moves a GLPI rollout from agreed scope to a supported production instance, with a named output at every phase.
Run the discovery and scoping workshop
DeployOpen and your service desk, asset, identity and security owners agree the processes GLPI must support, the systems it must integrate with, and the hosting boundary inside your infrastructure. The workshop closes with a written scope listing in-scope and excluded items. Timelines are set in that written scope and depend on the drivers listed earlier, including headcount, integrations and data migration.
Produce the solution design record
The design covers entities and profiles, ticket categories and SLAs, the asset model, a shortlist of marketplace plugins checked against the chosen GLPI version, and the mail collector and authentication design, including the order of LDAP, IMAP and external methods. Your team approves the design record before any build starts, so later changes are tracked as scope changes.
Build the environment on the confirmed stack
DeployOpen builds a staging instance on your servers or cloud accounts. The PHP and MySQL or MariaDB versions are confirmed against the GLPI release you chose, including the document root set to the public directory and URL rewriting. The output is a configured staging instance with documented versions, service accounts and key storage locations.
Configure and test against the design
The design record is applied to staging: entities, profiles, categories, SLAs, asset types, notifications, GLPI Agent inventory targets and authentication. Each item is tested with scripted scenarios such as ticket routing, SLA escalation, mail collector intake and profile access. The output is test evidence that maps each design decision to a result, with defects logged and retested.
Run a pilot with a limited user group
A defined group of technicians and requesters uses the staging or pilot instance for a set period agreed in the scope. Feedback, defects and process gaps are recorded against the design record. The pilot closes when the agreed exit criteria are met, and the findings either adjust configuration or are logged as later scope.
Go live and hand over
Production cutover follows a go-live checklist covering backups of the database, files and encryption keys, cron and mail collector checks, agent rollout waves and rollback steps. After cutover, DeployOpen hands over a runbook covering administration, backup and restore, upgrade steps and support contacts. Handover is complete when your team has run the restore and upgrade procedures with DeployOpen observing.
What stays in-house and what to outsource
This table separates the GLPI decisions your service desk should own from the build work a partner can take on, and lists the skills each part needs.
| Work item | Who usually owns it | Skills required |
|---|---|---|
| Ticket policy decisions | In-house: service desk lead owns the decisions, even when a partner builds the configuration | Service management process knowledge, agreed escalation and closure rules from your own policies |
| SLA targets and OLA commitments | In-house: service owners and business leads set targets, partner encodes them in GLPI | Service management process knowledge, understanding of your contracts and reporting needs |
| Asset ownership rules | In-house: asset and finance owners decide who is accountable for each asset class and location | Service management process knowledge, asset management practice, GLPI entity and profile configuration experience |
| Approval chains | In-house: managers and change or purchase approvers define who signs off requests | Service management process knowledge, familiarity with your delegation and authority model |
| Day-to-day administration | In-house: your admins run users, dropdowns, backups checks and routine tickets after go-live | Linux and PHP web server administration, database administration, GLPI configuration experience |
| Platform build and hosting | Partner can build: install on your servers and configure PHP, web server, and database | Linux and PHP web server administration, database administration, GLPI configuration experience |
| Data model design | Partner can design: entities, profiles, categories and custom fields, validated with your process owners | GLPI configuration experience, service management process knowledge, data modeling of assets and tickets |
| Plugin evaluation | Partner can evaluate: compatibility, maintenance status and fit against your GLPI version, with your sign-off | GLPI configuration experience, PHP knowledge, plugin lifecycle and upgrade awareness |
| Mail collector configuration and runbooks | Partner can configure collectors and write runbooks, with your mail team confirming routing and mailbox rules | Mail server administration, GLPI configuration experience, Linux administration for cron and mail jobs |
What usually goes wrong and how to prevent it
Most GLPI rollouts that struggle do so for reasons that were visible during planning. The risks below are the ones to settle before data is loaded and before go-live.
Entity and profile model built after loading data
Entities control which tickets, assets and users each group can see, and profiles control what each user can do. When these are designed after imports, records land in the wrong entity and permissions must be reworked across many objects. Prevention: sign off the entity tree, profile matrix and assignment rules in the plan, then test them with a few sample users on a staging copy before any bulk load.
Too many ticket categories and SLA variants
Teams often copy every request type they have ever handled into ticket categories and create a separate SLA for each variant. Agents then pick from long lists, reporting splits into small groups, and changes take weeks to propagate. Prevention: start from a short category set tied to real queues, define SLAs per priority rather than per category, and review usage after the first quarter of operation.
Plugins chosen before requirements are settled
Selecting plugins before the process is agreed locks the design to add-ons that may not fit the final workflow. After a GLPI major update, plugins are suspended until someone checks compatibility and reactivates them, which can stop a process mid-rollout. Prevention: write requirements first, rank each plugin against them, and keep a tested compatibility list for every planned GLPI version.
Encryption keys not backed up
GLPI relies on glpi.key and glpicrypt.key in the config directory to protect stored secrets and encrypted fields. A restore from database and file backups without these keys can leave credentials unusable, and the failure may appear only after recovery. Prevention: include the config directory in every backup, store a copy of both keys in a separate access-controlled location, and confirm a restore decrypts a test credential.
Web server document root set to the installation root
The GLPI installation documentation requires the document root to point to the public directory, with URL rewriting routing requests through index.php, on Apache, Nginx, lighttpd or IIS. Pointing it at the installation root exposes configuration and source files to browsers. Prevention: set the document root during build, include a check for config and source paths returning errors in acceptance testing, and repeat the check after every server change.
Mail collectors that fail silently
Mail collectors create tickets from inbound email, and a broken mailbox login, expired password or blocked port can stop intake without any visible alert. Users then report that their emails were lost. Prevention: test each collector with a known message during acceptance, confirm the cron jobs run on schedule, and add monitoring that alerts a named mailbox owner when collection stops.
Asset data duplicated or stale
Inventory from GLPI Agent, manual entries and imports can create two records for one device, and assets retired from service remain active. Reports then overstate capacity and licensing. Prevention: agree on the identifier used for matching, set an agent inventory schedule, define who retires assets, and run a duplicate review before each reporting cycle.
No named owners after go-live
Without named owners for configuration, plugins, backups, mail collection and asset data, problems are reported to a shared mailbox and fixed slowly or not at all. Upgrades then slip because nobody holds the change. Prevention: assign an owner and a backup owner for each area in the handover document, and review those names at each planned GLPI update.
How the work changes by starting point
A fresh deployment has no existing ticket history to carry over, so the work centers on design decisions and a clean build. Effort concentrates in the service model rather than data movement.
- Scope: entities, profiles, ticket categories, SLAs and the first set of asset types are designed and built from scratch.
- Effort drivers: the number of teams that will use the tool, the approval paths you need, and how many asset classes you want to inventory on day one.
- Risk: the most common risk is building too much before users have tested the workflow, so a small pilot group is worth planning.
- Inventory: GLPI Agent rollout is usually scheduled as its own phase after the core configuration is stable.
- Sibling topics: if you later move data in, see the GLPI migration topic. Customization and upgrade planning are covered in their own topics.
Teams that run service requests through a shared mailbox or track assets in spreadsheets need data cleanup as much as configuration. The first phase often involves deciding what history is worth keeping.
- Scope: asset lists, requester records and open requests are mapped to GLPI objects, and duplicates are resolved before import.
- Effort drivers: the quality of the spreadsheets, the number of unique owners and locations, and whether mailbox threads are converted into tickets or archived.
- Risk: inconsistent naming and missing owners cause the most rework, so ask for a sample extract to review early.
- Email: replacing a mailbox usually requires configuring email collectors and notifications, and this should be tested with real sender patterns.
- Sibling topics: the GLPI migration topic covers import tooling, validation and cutover for spreadsheets and mailboxes.
When another service desk tool is being retired, data movement becomes a separate project with its own plan, validation and cutover. Configuration work continues in parallel but depends on what the source data looks like.
- Scope: tickets, assets, users, knowledge base articles and attachments must be exported, mapped and checked, which the migration topic describes in detail.
- Effort drivers: the size of ticket history you keep, the complexity of the source workflow states, and how much of the source configuration you reproduce.
- Risk: status and category mismatches can break reporting and SLA logic, so mapping decisions should be signed off by service owners.
- Inventory: existing FusionInventory agents may need to move to GLPI Agent, which should be sequenced with the cutover.
- Parallel running: ask the partner how long both tools will run side by side and who owns reconciliation during that period.
An existing GLPI instance being reconfigured to a new service model is primarily a change project. The platform is already running, so the work focuses on redesigning entities, profiles and workflows without disrupting current users.
- Scope: entity structure, profile rights, ticket templates, forms and SLAs are reviewed against the new service model, then changed in a controlled way.
- Effort drivers: the number of existing custom fields and plugins, the volume of live tickets affected by the change, and how many reports depend on current categories.
- Risk: changing profiles or categories can silently alter access and reporting, so a staging copy and a change log are essential.
- Version currency: confirm the current GLPI version and whether a 10 to 11 or 11 to 12 upgrade is needed first, which the upgrades topic covers.
- Sibling topics: customization and security hardening topics cover the detailed configuration and controls.
In a segmented or air-gapped network, the build itself changes because the server cannot reach public package sources or mail relays directly. These dependencies must be planned before installation begins.
- Package sources: PHP dependencies, operating system packages and the GLPI release files must be staged through an approved internal repository or transfer process.
- Mail relays: notifications and email collectors need an internal relay that the GLPI server is permitted to use, and firewall rules should be tested early.
- Agents: GLPI Agent inventory and any deployment tasks need a reachable server endpoint from every segment in scope.
- Effort drivers: the number of network zones, the approval process for transferring software, and the number of plugins that must be staged manually.
- Confirm with your team: the exact prerequisites and database versions for your target release, which the installation docs and the upgrades topic describe.
What you need to provide
Before a fixed-scope quote can be final, your team must supply decisions and access that only your organization can make. The most important are named business owners for each service desk queue, a decision on how entities and locations are structured, and whether you have existing ticket category and SLA policies or will let us define them during design. A partner can draft the entity and profile model, but your service desk leads and IT management must approve who owns each queue, who can approve changes and what response targets mean for your business. We cannot set those commitments on your behalf.
Asset and hosting inputs come next. Provide the list of asset classes you want tracked (computers, network devices, phones, licenses, contracts) and name the source of truth for each, such as your directory, procurement system or endpoint tooling. For hosting, confirm the approved servers or virtual machines, the database platform (MariaDB 10.11 or later, or MySQL 8.0 or later, is the current GLPI 11 expectation to confirm against your target version), the TLS certificate process and the PHP version your standards allow. Your infrastructure team must approve these; we can only recommend them.
Identity and mail details determine the authentication and notification design. Share your directory or identity source details (LDAP or Active Directory server, bind account policy, group structure) and the mail server settings for email collectors and outbound notifications, including the mailbox that receives tickets. Your security team must approve any service account and its privileges. Also confirm whether a staging environment exists, which change windows your operations team accepts, and which named reviewers will sign off the design and have time to do so before build starts.
Frequently asked questions
How is a GLPI implementation priced, and what does a fixed-scope quote include?
A fixed-scope quote is built from a written scope that lists entities and profiles, ticket categories and SLAs, asset types, the GLPI Agent rollout, plugins, email collectors, hosting, data migration and the phases with their deliverables. Cost follows the work in each phase, so the main drivers are the number of processes to configure, the volume and condition of legacy data, the number of integrations and the number of environments. Ask the quote to separate one-time implementation fees from recurring items such as hosting, GLPI Network subscriptions or support retainers, and to state the assumptions behind each phase.
How long does a GLPI implementation take, and what changes the timeline?
Duration is driven mainly by scope, since the software install is usually the shortest step. The biggest factors are how many entities, profiles and approval paths must be modeled, how much legacy data needs mapping and cleaning, how many endpoints the agent rollout covers, how many plugins and integrations such as LDAP or mail are involved, and how quickly your team decides on ticket categories and SLAs. The written scope should show phases with dependencies. Confirm which reviews, approvals and test cycles it assumes on your side.
Can our internal team implement GLPI without an outside partner?
Yes, a team with Linux administration, web server, PHP and database skills can install GLPI, but the hardest parts are usually process design and data work. Check whether someone can own the service desk model, including entities, profiles, SLAs and notification rules, and whether anyone has carried a PHP application through major version upgrades. A partner adds a tested build sequence, a staging environment and a documented handover. Weigh that against staff time, since internal rollouts often take longer when the same people also run daily operations.
How much does GLPI Network cost compared with self-hosting GLPI?
GLPI is free to self-host under GPL version 3, and a GLPI Network subscription is a separate, optional product from Teclib'. According to the GLPI Network subscriptions page, public cloud costs 19 euros per user per month and private cloud 21 euros per user per month with a 25-user minimum. Self-hosted subscriptions range from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise, with level 3 support and marketplace plugins). Those prices are set by the vendor. Self-hosting moves cost to your servers, administration time, backups and upgrades, so compare the subscription against those internal costs.
Which PHP and database versions does GLPI 11 and GLPI 12 require?
According to the GLPI installation prerequisites, GLPI 11.0 requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and only MySQL and MariaDB are supported. The GLPI README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, which applies to the newer line. Confirm the exact requirements in the release notes and prerequisites for the version you deploy, because main branch documentation can change before a release. Build these versions into your base image and hosting plan before the build starts.
Are plugins required for a GLPI implementation, and what should we provide?
No, the core platform covers tickets, assets and contracts without plugins, but many organizations need marketplace plugins for SAML, OAuth, extra reports or specific workflows. Each plugin adds upgrade risk, because GLPI 11 suspends plugins when a new version is detected and they must be reactivated after major updates. From you, expect to provide a list of required integrations and existing plugins, administrator accounts, DNS names, TLS certificates, server or VM access, LDAP and mail details, a named owner for each approval, and exports of any existing data.
How DeployOpen delivers GLPI implementations
DeployOpen plans, builds, documents and supports GLPI inside infrastructure you control, so the cost of a rollout follows from a written scope agreed before work starts. Engagements are fixed-scope, and the plan below shows how that scope is agreed, built and handed over.
How we scope
- The written scope lists entities, profiles, ticket categories, SLA rules and the asset types that GLPI will hold.
- We confirm which GLPI version is targeted, such as the 11.0 line or 12.0.0, and which PHP and MariaDB or MySQL versions your servers will run.
- The scope names every plugin, email collector and GLPI Agent deployment included, so the quote reflects the actual work.
How we build
- We install GLPI on servers you provide, with the web document root set to the public directory and URL rewriting configured.
- We configure entities, profiles, ticket workflows and the GLPI Agent inventory pilot, then test each flow against the agreed acceptance criteria.
- We set up email collectors and authentication sources, and we test them with representative users and mailboxes before rollout.
How we hand over
- You receive documentation of the configuration, the server layout, backup jobs and the plugin list with versions.
- We walk your administrators through daily tasks, including ticket rules, agent deployment and the update procedure with db:update.
- The handover includes a backup and restore test, and the encryption key files are stored under your own key management practice.
How we support
- Ongoing support, upgrades and testing are available as a retainer, scoped separately from the implementation.
- Upgrade work for GLPI 11 and 12 is planned on a staging copy, with plugin reactivation checked after each major version.
- Support requests, security patching and changes to the scope are priced through written change requests agreed with your team.
