How GLPI upgrades and support work when you run it yourself
Most organizations running GLPI on their own servers handle upgrades in-house, with a partner brought in only for a major move or a problem they cannot resolve. GLPI is distributed under the GNU General Public License version 3, and a self-hosted installation carries no vendor obligation to patch, migrate or troubleshoot it for you. That means the upgrade, its timing and its risk sit with the operator, whether that is your own platform team or a partner you engage under a written scope. Several triggers push an installation to act. The first is the end of support for the line you are on. GLPI 10.0.0 was released on April 20, 2022, GLPI 11.0.0 on October 1, 2025, and GLPI 12.0.0 on October 7, 2026, according to the glpi-project/glpi releases page. Confirm the current support window for your branch with the project before you plan around it. Other triggers are a PHP or database version that no longer meets the prerequisites of the target release, plugins that stop working after a core change, security patches that need to reach production quickly, and new features you want, such as the rewritten knowledge base or session controls in GLPI 12.0.0. Before you touch the files, the update procedure in the GLPI installation docs asks you to back up the database, the application files and the config directory. That directory includes glpi.key and glpicrypt.key. If you lose those keys, encrypted values stored in the database may become unreadable, so store copies somewhere separate from the server. Next, replace the application files and run php bin/console db:update from the installation root. Since GLPI 11.0, plugins are suspended when a new version is detected, so each plugin must be checked for compatibility and reactivated after a major update. Support after go-live is a separate decision. Teclib' offers GLPI Network subscriptions with levels of support, and the subscriptions page lists self-hosted plans from 100 euros per month for the Basic tier up to 4,500 euros per month for Enterprise, which includes level 3 support. Ask Teclib' directly whether a subscription covers your deployment model, your plugins and the response times you need. A retainer with a partner covers different work, such as scheduled upgrades on a staging copy, patch windows, plugin testing and restore checks. Ask any partner to define in writing what is included, who holds the backups and keys, and how emergency changes are handled. Before you commit to either path, inventory your current version, PHP and database versions, every installed plugin, and where your keys and backups are stored. Those four facts determine most of the effort. A partner or internal team that cannot answer them quickly will struggle to give you a firm quote or a reliable upgrade date.
What an upgrade and support engagement includes
Each GLPI upgrade engagement moves through the same sequence: review the running system, plan each version hop, rehearse on a copy, cut over with a verified backup, then support the platform after go-live. The cards below describe what each package covers and what you should check at each stage. Scope, hop count and timing are confirmed in writing before work starts.
Current-state review
We record the running GLPI version, PHP version and extensions, database engine and version, web server, installed plugins with their versions and sources, and any custom code or templates changed outside the marketplace. Each item is compared against the prerequisites of the target release, because a PHP or MariaDB gap found at this stage is far cheaper to fix than one found during cutover. Ask for this inventory to be delivered as a written document you can keep.
Upgrade plan per version hop
Moving from GLPI 10 to 11 and from 11 to 12 are separate hops, and each has its own prerequisites, plugin compatibility checks and database update step. The plan lists the target version, the PHP and database versions required, the order of hops, and the go or no-go checks for each. Confirm with us whether your environment needs an intermediate version and whether your plugins have published support for each target.
Staging rehearsal
We restore a copy of your production database and files into a staging environment that matches production's PHP, database and web server settings, then run the full update there. The rehearsal records how long the database update takes, which plugins are suspended, and which custom code breaks. Ask whether the rehearsal runs at least once more before cutover if the first attempt surfaces significant findings.
Production cutover
Cutover starts with a full backup of the database, the GLPI files and the config directory, including the glpi.key and glpicrypt.key files that GLPI needs to read stored secrets. Application files are then replaced, and the database update is run with the console tool. Each step has a recorded check, and the rollback point is written down before the first change. Confirm the agreed maintenance window and who on your side approves the go decision.
Post-upgrade verification and plugin reactivation
Since GLPI 11, plugins are suspended when a new version is detected, so each plugin is reactivated only after its compatibility is confirmed. Verification covers login through your chosen authentication method, ticket and asset workflows, scheduled tasks, mail collectors, notifications and agent inventory uploads. Ask for a written list of what was tested and what was left for your own users to confirm.
Ongoing support after go-live
After go-live, support covers incident triage, applying minor releases, checking plugin updates before they are enabled, and planning the next hop when a major release is due. Support is delivered under a retainer or a separate written agreement, and the response expectations, covered hours and escalation path are defined in that agreement. Ask for these terms to be stated in writing before you sign.
What makes a GLPI upgrade larger or smaller
This table lists the factors that most change how much work a GLPI upgrade takes, why each one matters, and what you can do early to reduce it. Read each row against your own installation to see which factors apply and where your effort will concentrate. The main takeaway is that plugins, custom code and the absence of a staging copy usually shape the schedule more than the core upgrade steps do.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Installed plugins | Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so each plugin needs a compatibility check and a test pass. | Remove plugins nobody uses, and confirm with each plugin's maintainer that a version exists for your target GLPI release before you start. |
| Custom code and templates | Custom PHP, modified templates and altered core files can break on upgrade and often need rework by someone who understands them. | Inventory every change outside the stock installation, document why it exists, and move customizations into plugins where practical. |
| Database size and history | Larger databases take longer to back up, copy to staging and migrate through db:update, and long histories raise the risk of data issues surfacing late. | Archive or purge old logs and closed tickets according to your retention policy, then time a full db:update on a copy. |
| Entities and users affected | More entities, profiles and active users mean more permission rules and more people who must test their workflows after the change. | Pick a representative test group per entity and profile, and agree the sign-off list before the upgrade window. |
| Single server or several | Splitting web, database and file roles across machines adds coordination steps, and each node must be updated and verified in the right order. | Write the node order into the runbook and confirm that shared files and sessions behave the same on every node after upgrade. |
| Staging environment | Without a staging copy, the first real run of db:update happens on production, which removes the chance to find blockers safely. | Clone production early, including the database and the config directory with glpi.key and glpicrypt.key, and run the full update there first. |
| Version gap being crossed | Moving from GLPI 10 to 11 or from 11 to 12 changes PHP and database prerequisites, so a larger gap means more platform work before GLPI itself is updated. | Check the PHP and MariaDB or MySQL versions against the current prerequisites page early, and confirm the supported path with Teclib' release notes. |
| Dependent agents and integrations | LDAP, SSO, mail collectors and GLPI Agent connections can stop working after an upgrade if their settings or endpoints change, and failures may only appear in daily use. | List each integration with its owner, test authentication and mail collection on staging, and confirm agent check-in after the cutover. |
The phases of a fixed-scope GLPI upgrade
A fixed-scope GLPI upgrade moves a live service desk to a newer release in controlled stages, so that each phase produces evidence the next one depends on. The sequence protects data, confirms compatibility before any production change, and ends with a documented handover.
Inventory the current version and plugins
The team records the running GLPI version, PHP and database versions, web server type, installed plugins and their versions, custom configuration, cron jobs and mail collectors. Your administrators confirm which plugins the business relies on and which features are used. The output is a written inventory that becomes the baseline for every later check, and the scope is confirmed against it before work continues.
Check prerequisites against published requirements
The current PHP, MariaDB or MySQL, and web server versions are compared with the requirements published for the target release. The team also confirms that the document root points to the public directory and that URL rewriting is in place. Gaps are logged with an owner and a remediation step. The output is a prerequisite report signed off by your technical lead, and any platform upgrade needed before GLPI can move is scheduled first.
Build the staging copy
A copy of the production database, application files and config directory is restored into a separate environment inside your infrastructure. Keys and configuration are carried over exactly, and access to the copy is restricted because it contains production data. The output is a staging instance that matches production closely enough to rehearse the change, with the differences between the two documented.
Rehearse the update on staging
The team replaces application files on staging, runs php bin/console db:update, and reactivates plugins one at a time. Each plugin is checked for compatibility with the new release, and the error log is reviewed after every step. Any plugin that fails is either updated, replaced or retired by a decision your team approves. The output is a rehearsal log with the exact commands, timings observed, and a list of issues with their fixes, which becomes the runbook for production.
Back up and run the production change
During the agreed change window, the database, the application files and the config directory are backed up, including glpi.key and glpicrypt.key. The team confirms the backups can be read before any change. The application files are replaced, db:update is run, and plugins are reactivated following the rehearsed runbook. The output is a production instance on the target version and a backup set that has been verified to restore, kept until your team accepts the upgrade.
Verify functions and integrations
The team tests the workflows your service desk depends on: ticket creation and assignment, notifications, mail collectors, agent inventory uploads, LDAP or SSO sign-in, scheduled tasks, and API access. Results are compared with the baseline inventory, and each failed check is either fixed or accepted by your owner in writing. The output is a signed verification record that shows what passed, what was fixed, and what remains open.
Hand over documentation and runbooks
The team delivers the as-built configuration, the upgrade record, the rollback procedure, the key and backup locations, and the plugin list with versions. Administrators from your side are trained on the new release's changes to the interface and administrative controls. The output is a handover pack and a recorded walkthrough, and ownership of the platform formally returns to your team.
Provide post-go-live support
After go-live, the team supports your administrators for the period agreed in the written scope, covering issues found in use, plugin problems, and questions about the new release. Support terms, response expectations and any ongoing retainer are confirmed before work starts, and you should ask for them explicitly in any quote. The output is a closed support log and a recommendation for the next upgrade window.
Which parts of a GLPI upgrade your team can keep and which to hand over
Most GLPI upgrades split cleanly into work that your service desk owns and work that needs systems skills your team may not have on hand. The service desk side covers day-to-day ticket administration, decisions about business rules, approval of the change window and testing of its own workflows. These tasks depend on GLPI administration and on knowing how the desk actually works. Nobody outside your organization can decide whether an escalation rule still matches your SLA commitments, so these decisions should stay in-house. Your administrators should also own the final go or no-go, because they carry the operational risk of an outage during business hours.
The technical preparation is where outside help is most often useful. Version gap analysis means reading the release notes between your current version and the target, then listing every behavior change that touches your entities, profiles, forms and notifications. It needs GLPI administration plus enough familiarity with the code to judge whether a change matters for your setup. Plugin compatibility checks are similar. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so each marketplace or custom plugin needs a named owner who confirms it works on the target version before cutover. Plan for a plugin that has no maintained release for the target as a blocking item, not a footnote.
Staging rehearsal, backup verification and server tuning need Linux administration, PHP and database operations skills. A rehearsal means restoring a recent copy of the database and files onto a server that matches production, then running php bin/console db:update there and timing the result. Your team should confirm that the encryption keys, glpi.key and glpicrypt.key, are backed up separately from the database and restored correctly, because a database restore without its keys leaves encrypted data unreadable. Web server and PHP tuning covers the document root, URL rewriting, PHP version and extensions, and the database version. The prerequisites for GLPI 11.0 and GLPI 12.0.0 differ, so confirm the exact versions with the installation documentation before you order hardware or images.
Rollback planning is the item most teams underestimate. A rollback is only real if you have tested restoring the pre-upgrade database, the application files and the config directory together, and if someone has written down the order of steps. Ask whoever runs the upgrade to show that the restore works on the staging copy, and ask them how long a restore took. An internal team with a Linux administrator, a database administrator and a GLPI administrator can run the entire upgrade alone, provided those people have done it before and have time for a full rehearsal. If any of those three roles is a single person who is already stretched, handing the rehearsal and rollback work to a partner usually reduces the risk more than the cost.
When you request a quote, ask the provider to split the scope into the parts above and to name who performs each one. Confirm whether plugin compatibility checks include code changes or only testing, and whether post-upgrade support is included or billed separately. Ask for the rehearsal to be run on a copy of your current data, not on sample data, and for the written rollback procedure to be tested before the change window is approved. Those answers show which parts your team keeps, which parts go to a partner and where the handover points sit.
What usually goes wrong during a GLPI version upgrade
Most GLPI upgrade problems are not caused by the new release itself. They come from missing prerequisites, incomplete backups and steps that were skipped during the window. Each card below names one failure mode and the check that prevents it.
Losing the encryption keys
GLPI stores its encryption key in glpi.key and the crypt key in glpicrypt.key within the config directory. If either file is lost or regenerated, encrypted fields in the restored database cannot be read, including stored credentials for some integrations. Before any upgrade, copy both files to a secure location separate from the server, confirm they match the database backup taken on the same day, and verify the restore on a staging copy.
Running db:update without a tested backup
The update procedure runs php bin/console db:update, which changes the database schema in place. There is no reliable rollback once the migration has started on production data. Take a database dump, a copy of the application files and a copy of the config directory, then restore that set on a separate host and run the upgrade there first. Only proceed to production when the restored instance logs in and shows expected tickets and assets.
PHP or MariaDB below the target requirement
Each GLPI release publishes minimum PHP and database versions, and the requirements change between releases. Upgrading the application files onto an older PHP or database server can fail during startup or the migration. Check the prerequisites page for the exact target release before scheduling the window, confirm the installed PHP extensions and database version on the staging host, and upgrade the runtime first when it falls short.
Plugins left suspended after a major update
Since GLPI 11.0, plugins are suspended when GLPI detects a new version, so a plugin can appear to disappear after the upgrade. Users may then see missing forms, menus or automation. After a major update, list every installed plugin, confirm a version compatible with the target release, and reactivate each one deliberately. Record which plugins were active before the window so nothing is missed.
Plugins without a version matching the target
Even when a plugin installs, it may be built for an earlier GLPI API or database layout. Mismatched plugins can break ticket workflows or asset forms in ways that are hard to trace back to the upgrade. Before the window, confirm each plugin publishes a release for the target GLPI version, test it on staging, and decide in advance whether a plugin will be replaced, upgraded or retired.
Document root left on the installation root
GLPI expects the web server document root to point to its public directory, with URL rewriting routing requests through index.php. Files copied over during an update can reset the web server configuration or leave the old root in place. The result can expose configuration or source files over HTTP. After the upgrade, confirm the document root in the Apache, Nginx, lighttpd or IIS configuration and test that files outside the public directory are not served.
Cron and mail collectors stopped and not restarted
GLPI relies on scheduled tasks for notifications, inventory processing and mail collection. Teams often stop the cron job or collector service for the window and forget to restart it, so tickets stop arriving by email and alerts go silent without an obvious error. Write the stop and restart steps into the change plan, and check the scheduled task list and the last run time for each collector once the upgrade completes.
Recurring costs after go-live for a self-hosted GLPI
This table lists the recurring cost components of running a self-hosted GLPI after go-live, who typically carries each one, and what to ask for in a quote. Use it to separate one-time project work from costs that continue every year, and to decide which items your own team will absorb. The main takeaway is that a free GPL-3.0 platform still carries hosting, upgrade, plugin testing and admin time, and that a Teclib' subscription is an optional addition on top of those costs.
| Cost component | One-time or recurring | What drives it and what to ask for |
|---|---|---|
| Hosting and server patching | Recurring | Server or cloud instances, storage, operating system patching and monitoring on your infrastructure. Ask whether the quote covers patch windows, rollback and who responds to alerts. |
| PHP and database lifecycle work | Recurring | GLPI 11 requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and the README lists PHP 8.3 or later with MariaDB 10.11 or MySQL 8.0 for the current branch. Ask how runtime and database upgrades are scheduled and tested. |
| Periodic GLPI upgrades | Recurring | Each minor release and each major move (10 to 11, 11 to 12) needs a staging copy, backups, file replacement and db:update. Ask how many upgrade cycles per year the retainer or quote includes. |
| Plugin updates and testing | Recurring | Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. Ask who checks compatibility, who reactivates plugins and what test evidence you receive. |
| Backup and restore tests | Recurring | Database, files and the config directory, including glpi.key and glpicrypt.key, must be backed up and restorable. Ask how often restore tests run and whether they cover the encryption keys. |
| Internal admin time | Recurring | Your staff time for approvals, ticket category maintenance, user and group changes and reviewing upgrade notes. Estimate it with your own team, because no supplied figure exists for it. |
| Optional GLPI Network subscription | Recurring (optional) | Public cloud is 19 euros and private cloud 21 euros per user per month (25-user minimum), per the GLPI Network subscriptions page. Self-hosted tiers run from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), with level 3 support. |
How the upgrade differs by starting version and hosting model
Moving from GLPI 10.x to 11.x changes the most prerequisites at once. The installation docs list PHP 8.2 or later and MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, so a 10.x server running older PHP or an older database must be brought up to those levels before the application files are replaced. The update procedure requires a full backup first, then file replacement, then a database update run from the command line. GLPI 11 suspends plugins once it detects a new version, so plugin review belongs in the same change window.
- PHP version: confirm PHP 8.2 or later runs under the same service that serves GLPI, with the extensions the application needs.
- Database version: confirm MySQL 8.0 or MariaDB 10.6 or later, and take a dump before any other change.
- Encryption keys: copy glpi.key and glpicrypt.key from the config directory to a separate, access-controlled location.
- Document root: confirm the web server points to the public directory, not the installation root, and that URL rewriting routes requests through index.php.
- Plugins and db:update: run php bin/console db:update, then reactivate only the plugins with confirmed 11.x compatibility.
Run every check on a staging copy of production data before scheduling the cutover.
GLPI 12.0.0 was released on October 7, 2026, according to the GLPI release page. The README on the main branch lists PHP 8.3 or later and MariaDB 10.11 or later, or MySQL 8.0 or later, so the first check is whether the current 11.x host already meets the 12 baseline. The larger effort usually sits in the 12.0.0 feature changes, which affect how administrators and integrations behave after the upgrade. Confirm the exact requirements for the release you will install, because the main branch README can change before a release is cut.
- PHP 8.3: plan the runtime upgrade first, since a PHP 8.2 host will not meet the 12 baseline.
- Database 10.11 or MySQL 8.0: confirm the database tier, and schedule any MariaDB upgrade with a tested backup.
- Plugin compatibility: list every plugin and confirm a 12-compatible version exists before any production change.
- Knowledge base and sessions: the rewritten knowledge base and the session view with revocation may change content, templates and admin routines, so test both.
- Step-up authentication: confirm that scripts or automation performing certain administrative actions still work once step-up prompts apply.
Review the 12.0.0 release notes against your plugin list and your integrations, then run the full upgrade on a staging copy.
The GLPI 12.0.0 release notes list an official Docker image among the distribution options. A container changes the upgrade from an in-place file replacement to a change of image tag, and the persistent data becomes the main risk. The application files, config directory and encryption keys must live on storage that survives container replacement, or the first recreated container will start without the keys it needs. Confirm the image tag, the base image and the update procedure with the image maintainers before you adopt it as a standard.
- Persistent volumes: map the files directory and the config directory, including glpi.key and glpicrypt.key, to storage outside the container.
- Database placement: confirm whether the database runs in a separate container, on a managed host or on a dedicated server, and that it meets the MariaDB or MySQL version floor.
- Upgrade step: run db:update inside the container after the new image starts, and confirm the command path matches the image layout.
- Plugins: decide whether plugins are baked into a custom image or added to the volume, then recheck their status after each major update.
- Cron and mail: decide whether the scheduled tasks run in a separate container or on the host, and confirm which container runs them.
Test a restore of the volumes into a new container before the first production upgrade.
In a multi-server layout, the web nodes and the database node are upgraded as one system, even though they run on separate hosts. The web tier needs the PHP level for the target release, the database tier needs the database version floor, and both must agree on the database connection and the encryption keys. Because the web nodes read the same database, a mismatch between nodes can leave some users on an older code path. Agree the change order with the team that owns the database and confirm it against the release notes for your target version.
- Web node PHP: confirm every web node runs the required PHP version and the same extensions.
- Document root: confirm each web node serves the public directory, not the installation root, with URL rewriting in place.
- Shared files and keys: keep glpi.key and glpicrypt.key identical on every web node, and confirm the shared files directory is mounted before the update.
- Plugin set: install the same plugin versions on every web node and reactivate them only after db:update completes.
- Cron placement: run scheduled tasks on one designated node so that jobs do not run twice during or after the change.
Verify that every web node reaches the upgraded application before you direct user traffic back to the cluster.
An air-gapped or offline GLPI environment cannot pull packages from public repositories during the upgrade, so every dependency must be staged inside the network before the change window. That includes the GLPI release archive, the PHP and database packages from your operating system mirror, plugin archives and any agent packages you deploy. The version checks are the same as in a connected environment, but the team must confirm the source and integrity of each package by hand. Plan the staging process as part of the upgrade, not as a one-time task before it.
- Release archive: obtain the GLPI release file through your approved transfer process and verify its checksum against the value published with the release.
- PHP and database packages: confirm the internal mirror offers PHP 8.2 or 8.3 and MySQL 8.0 or MariaDB 10.6 or 10.11, as the target version requires.
- Plugins: stage every plugin archive and confirm its compatibility with the target GLPI version before transfer.
- Update notices: confirm how the team learns about new releases and security fixes, since connected update checks will not run.
- Document root and plugin status: confirm the public directory is served correctly and reactivate plugins only after db:update completes.
Run the full staged upgrade in an isolated test enclave that mirrors the production network before the change is approved.
What your team must provide before an upgrade starts
Before a GLPI upgrade is scheduled, your team must hand over a defined set of access, data and decisions. Most delays on a GLPI upgrade come from missing inputs rather than from the upgrade itself, so the first task is to confirm who owns each item and that the owner has agreed to supply it in time. The items below are the ones the upgrade plan depends on. Administrative access is the first input. The upgrade team needs root or sudo rights on the application server, administrative credentials for the database server (with rights to dump, restore and alter the GLPI schema) and access to the web server configuration, including the virtual host that serves GLPI. Infrastructure or platform engineering owns these credentials. Ask for them to be issued to named engineers for the upgrade window, with the access logged, and revoked afterwards. Because the upgrade replaces application files and changes the document root handling, the team also needs to know which web server runs GLPI (Apache, Nginx, lighttpd or IIS) and where its configuration lives. A recent, verified backup is the second input. The GLPI update procedure requires a backup of the database, the files and the config directory. Your database administrator owns the database dump and should confirm it can be restored on a separate host. The application owner should confirm that the file backup includes the config directory, which holds glpi.key and glpicrypt.key. Those two keys are not optional. glpi.key protects values stored with GLPI's encryption, and glpicrypt.key is used for stored credentials. Record where the keys are kept, who can read them and how a copy is retrieved if the server is lost. A backup that does not include these keys is not a usable rollback point. The third input is an inventory of installed plugins and any custom code. Plugins are suspended after GLPI detects a new version and must be reactivated after a major update, so the upgrade team needs the plugin list, the version of each plugin, and the name of the person who owns each one. Custom code, such as templates, scripts or changes made directly to GLPI files, must be listed separately because it will not be replaced by a vendor update. Your service desk lead or the plugin owner should confirm which plugins are still needed and which can be retired before the upgrade. A staging host with a recent copy of production data is the fourth input, and it is the place where the team proves the upgrade before production is touched. Your infrastructure team owns the staging environment, and the data owner should approve the copy and any masking of personal data in it. The staging host should match production in PHP version, database engine and version, web server and installed plugins. Where it does not match, the test results will not predict production behaviour. Finally, the business side must provide three named people: a business owner who approves the change window, a person who can describe the critical workflows and supply a test script (for example, opening and closing a ticket, creating an asset, running an approval and a scheduled notification), and a post-upgrade sign-off approver who confirms that the workflows passed. Without the sign-off owner named in advance, a production upgrade can finish technically and still stall for days while nobody accepts it.
Questions buyers ask about GLPI upgrades and support
How much does a GLPI upgrade cost and what drives the price?
The cost depends on scope. The main drivers are the size of the version gap, the number of plugins and custom code, the hosting environment, the data volume and how deeply the upgrade is tested. DeployOpen does not publish a price list, so a quote follows from a written scope. Ask for the quote to separate one-time work (assessment, prerequisite upgrades, staging rehearsals, plugin review, cutover and documentation) from any recurring support. Plugins and custom code usually take the most review, because each one may need a compatibility check and reactivation after a major update. Your own costs also belong in the budget: staff time for testing and sign-off, any new PHP or database servers and backup storage. If you are weighing a Teclib' subscription, its published prices are separate from implementation work. For example, the GLPI Network subscriptions page lists self-hosted plans from 100 euros per month (Basic) to 4,500 euros per month (Enterprise).
How long does a GLPI 11 to 12 upgrade take?
No single duration applies, because the answer depends on scope. The number of versions to cross, the plugin count, custom code, data volume and the number of test cycles your business needs all change the timeline. Start with an assessment against the prerequisites. The GLPI 12 README lists PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later, while the GLPI 11.0 installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6. Work that often adds time includes upgrading PHP or the database first, resolving plugin compatibility and running db:update on a staging copy until results are clean. Ask for a written timeline with milestones tied to these steps, plus the assumptions behind it, including who signs off testing and how many change windows are available for cutover.
Can our own team upgrade GLPI without an outside partner?
Yes, if your team has the skills and the environment to support it. You need working knowledge of PHP and web server configuration, administration of MariaDB or MySQL, and GLPI itself, including how its plugins behave. You also need a staging copy of production with the same files, database and config directory, so you can rehearse the upgrade and check results before touching live data. Your team should be able to take a full backup, restore it and roll back if testing fails. Teams often underestimate two things: the time needed to review plugins and custom code, and the sign-off effort from service desk owners who must confirm that tickets, assets and workflows behave as expected. If any of these skills or steps are missing, a fixed-scope engagement can cover the gaps. Make the decision from a written skills inventory and a staging plan.
What does a GLPI upgrade need from our team?
Your team provides access, information and decisions. Expect to supply access to production and staging servers, recent backups of the database, files and config directory, and the current GLPI, PHP, database and web server versions. You also need a complete list of plugins and customizations with named owners, plus the LDAP, SSO or reverse proxy details that GLPI depends on for sign-in. Service desk and asset teams should provide test cases based on daily work, such as opening and routing tickets, running inventory imports and checking notifications. Finally, name the people who approve each stage, including the go or no-go decision and the rollback decision, and reserve a change window with agreed communication to users.
What happens to GLPI plugins after a major update?
Plugins are suspended until someone reviews and reactivates them. The GLPI update procedure states that since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. Plan for this by checking each plugin against the target version with its maintainer before the upgrade. Update or replace plugins that are not compatible, and treat custom plugins as code that needs review and testing. On staging, reactivate each plugin one at a time, then test the workflows it touches, such as ticket forms, notifications, asset types or API calls. Only after those tests pass should you reactivate plugins in production. Keep a written record of each plugin's version and status, because auditors and support teams will ask for it.
Which GLPI encryption keys must we back up before upgrading?
Back up glpi.key and glpicrypt.key from the config directory. The GLPI update procedure requires backing up the database, the files and the config directory, and that directory holds these two keys. Data that GLPI encrypts with these keys may not be recoverable if the keys are lost, so the keys matter as much as the database dump. Store copies in a secure location separate from the GLPI server, restrict who can read them and record where each copy is kept. Before the production upgrade, restore a backup, including the keys, to the staging copy and confirm that the restored instance can read encrypted data and sign in. Confirm the exact handling steps against the current GLPI installation docs for your version.
What does post-go-live GLPI support cover, and can it be retained?
Post-go-live support covers what your written scope says it covers, and it can be retained. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Ask the proposal to list the included activities, such as incident response, reviewing new GLPI releases, checking plugin compatibility before updates, running db:update after upgrades, restoring backups as a test and handling user questions. Also ask how requests are logged, who responds and what happens when a request falls outside the retainer. Because GLPI releases continue to ship, including GLPI 12.0.0 and later point releases, a retainer can carry the planning and testing work that keeps your instance on a supported path. Get the scope, hours and terms in writing before go-live.
Does DeployOpen issue compliance certificates for GLPI upgrades?
No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies issue those outcomes. DeployOpen prepares systems, controls and evidence for compliance assessments, so the upgrade is documented in a form an assessor can review. That evidence can include the pre-upgrade assessment, change records, backup and restore results, plugin review logs, staging test results and the post-upgrade configuration. Ask your assessor which evidence they expect before the work starts so that records are captured during the upgrade rather than reconstructed afterward. Confirm the framework and control requirements with your assessor, since they decide what is sufficient.
How DeployOpen scopes, upgrades and supports GLPI
DeployOpen plans GLPI upgrades and support as written, fixed-scope work inside your own infrastructure, starting from your current version, plugins and data. Each engagement covers the prerequisites, backups, staging tests and documentation needed to move between GLPI releases safely.
How we scope
- Record your current GLPI version, PHP and database versions, web server, and the plugins you run.
- Confirm the target release, such as GLPI 11 or GLPI 12, and check PHP and MariaDB or MySQL prerequisites against it.
- Agree the written scope, deliverables and timeline before work starts, with support available afterwards as a retainer.
How we build
- Back up the database, application files and the config directory, including glpi.key and glpicrypt.key, before any change.
- Rebuild a staging copy, replace the application files and run php bin/console db:update there first.
- Test ticket workflows, agent inventory, email collectors and LDAP or SSO logins, then reactivate plugins one by one and confirm compatibility.
How we hand over
- Document the upgrade runbook, rollback steps and the exact order of backups, file replacement and database updates.
- Record the plugin list with versions, status after reactivation and any items you still need to confirm with plugin authors.
- Walk your administrators through the production cutover, post-upgrade checks and the reactivation steps they will repeat next time.
How we support
- Define which support after go-live is covered by the fixed scope and which items move to a retainer.
- Plan the next upgrade window, reviewing release notes and plugin compatibility before each target version is chosen.
- Review backups, restore tests and web server settings, such as the public document root, on a schedule agreed in writing.
