GLPI 12 upgrade

The GLPI 12.0.0 release notes list three changes that affect people in daily use: a rewritten knowledge base, a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. Each one touches a different group. Helpdesk staff will notice the knowledge base first when they search for answers while working tickets. Knowledge authors will feel the change in how they create and maintain articles. Administrators will see new session and authentication behaviour, and end users may meet a new prompt when an action requires extra verification. The release notes describe what changed at a feature level, so your team needs to confirm the detail in its own environment before assuming how any screen behaves.

For helpdesk staff and knowledge authors, the first task is to list every workflow that depends on the knowledge base today. That includes article categories, visibility settings, links from ticket forms or templates, and any reporting or search habits that rely on the current layout. Because the knowledge base has been rewritten, existing articles should be opened, searched and linked on a staging copy with a representative set of profiles. Confirm which article fields survive migration, whether attachments and internal-only content behave as before, and whether any custom links or bookmarks still resolve. Ask the GLPI 12 release notes and the project documentation which parts of the editing experience changed, and record any gap before go-live.

For administrators, the session view and revocation feature changes how you respond to a lost laptop, a departing employee or a suspicious login. Test it with real accounts on staging: sign in from two browsers, confirm that both sessions appear in the view, revoke one, and check that the revoked session is actually forced out. Also check how the view behaves for users in different entities, since your profiles and entity structure determine who can see or act on other people's sessions. Step-up authentication for certain administrative actions may affect scripted or delegated work, including service accounts, API clients, plugin screens and any runbook that expects a single login to cover a sequence of changes. Identify which actions trigger the extra check, who needs to complete it, and whether automation is affected.

Customizations and documentation need the same scrutiny. Review custom templates, CSS or JavaScript changes, plugin screens that add administrative actions, and internal guides that describe how to revoke access or perform privileged tasks. Any of these may describe steps that no longer match the interface. End users should also be tested, because a step-up prompt or changed session behaviour can appear in a self-service portal where people have less context than administrators. Plan a short test script for each profile and entity, record results, and update the internal guide before cutover. Confirm each behaviour with the release notes, the GLPI documentation and your own staging results rather than relying on this summary.

The purpose of staging acceptance is to decide, before production is touched, whether the GLPI 12 upgrade is good enough to keep and whether the pre-upgrade system can be brought back if it is not. Both answers need evidence, so the test plan should be written and agreed before the staging copy is upgraded. Run it on a copy restored from a production backup taken on the same day, with the same PHP 8.3 and MariaDB 10.11 or later versions you intend to use in production, so that results carry over. Start with access. Log in with a test account for each authentication source in use, in the order GLPI tries them: internal database, LDAP directory, IMAP mail server and any external method such as REMOTE_USER through a reverse proxy. Confirm that each account lands in the expected entity and profile. Next, run a restored key check. Open a record that holds an encrypted stored value, such as a mail collector or LDAP bind password, and confirm it still decrypts. A failure here usually means glpi.key or glpicrypt.key was not restored with the database and files, which is the most common reason an upgrade appears to succeed and then breaks integrations. Then sample the data. Open a set of tickets across several statuses and categories, a set of assets from each inventory type, and a set of knowledge base articles, including articles migrated or edited under the rewritten knowledge base. Check attachments, linked items and visibility rules, not just whether the page loads. Check plugin status in the administration area, confirm that each plugin you depend on has been reactivated after the update, and test its main function with a real workflow rather than only its settings page. Confirm that scheduled tasks run, that the agent check-in times show new inventory, and that a test ticket generates the expected notification. The rollback rehearsal is the part most often skipped, and it should be run on staging after the acceptance tests pass. Restore the pre-upgrade database, the files and the key files from the same backup set, point the web server back at the old application directory, and confirm the old version serves login, ticket lists and asset pages. Record the time each step takes. A rehearsal that cannot be completed within the change window is a finding in its own right. For change control, keep a short evidence pack: the test plan with named testers, the GLPI and PHP versions before and after, the backup identifiers and checksums, a table of each acceptance test with pass or fail and the tester's initials, screenshots or log extracts for the key check and notifications, the plugin list with versions, and the rollback rehearsal log. Ask the auditor or change board which items they require and agree the go or no-go criteria in writing before the production window.

The upgrade is not finished when the login page loads on 12.x. The first weeks on the new version decide whether the team trusts the platform, so the operating routine should be written down before cutover. Keep the pre-upgrade backup, including the database, the application files and the config directory with glpi.key and glpicrypt.key, until the new version has run through a full business cycle. For most service desks that means a complete month-end or quarter-end pass, covering ticket closure, contract renewals and reporting. Restoring from that backup is the only clean rollback path if a defect appears late, so the retention date should be set as a decision, not left to whoever reclaims disk space first.

Watch the logs for the first several weeks. Review the PHP error log for the web server and PHP-FPM, and the GLPI application logs, for deprecation notices, fatal errors and plugin warnings that did not appear on 11.x. On the database side, check the MariaDB or MySQL error log and slow query log for new warnings after the db:update run. Set a short recurring review rather than relying on users to report failures. Agree who owns each log, how often it is read, and what severity opens an incident.

Confirm that the background work still runs. Check the scheduled tasks (crontab-driven GLPI cron) for failures or tasks that stopped running, because a silent cron failure leaves notifications, SLA escalations and inventory cleanup undone without any visible error on the front end. Test each mail collector by sending a test ticket to the collector address and confirming it arrives. Track GLPI Agent check-ins against the expected device count, since a drop in reporting agents often signals a network, certificate or endpoint-configuration problem introduced during the move. Plugin updates need the same discipline: list every installed plugin, its version, and whether the vendor or author has confirmed compatibility with 12.x. Plugins were suspended during the major update and must already have been reactivated, so verify their state again after each plugin update.

Record the operating facts in the runbook while they are fresh. The record should include the installed GLPI 12.x version and PHP and database versions, the document root path, the location of the config directory and both key files, the backup locations and restore procedure, the cron and mail collector settings, the plugin inventory with versions, and the step-by-step rollback. Keep the key files out of ordinary file-share backups and document who may access them. On patching, the GLPI release history shows a steady cadence of point releases on the 11.x line, for example 11.0.11 on October 1, 2026. Ask your vendor or support provider to confirm the patch policy for 12.x, including how security fixes are delivered, how long older lines receive support, and what testing they expect before a patch goes to production. Put the answer into the runbook.