GLPI 11 is the biggest shift in the platform since the 9.5 release in 2020. The GenericObjects and FormCreator plugins move into core as native custom assets and native forms, webhooks and two-factor authentication are built in, and the underlying stack moves forward by several PHP versions. With 11.0.7 shipped on 29 April 2026, the 11.0.x line is mature enough to plan a real migration. The question is no longer "should I wait" but "when does it fit our calendar."
What's actually new in GLPI 11
Native custom assets (replaces GenericObjects)
For years, any non-standard asset type — HVAC equipment, vehicles, IoT devices, software licenses tracked by line of business — required the GenericObjects plugin. In GLPI 11, custom asset types are a core feature: define new asset types directly in setup, configure their fields, and they integrate with display preferences, saved searches, and reporting like any built-in asset. GenericObjects becomes redundant; existing definitions migrate manually.
Native forms (replaces FormCreator)
FormCreator has been the de facto self-service forms plugin for the GLPI helpdesk for over a decade. GLPI 11 ships a native form builder in core — visual editor, conditional logic, mapping form fields to ticket attributes, and access control by profile. Existing FormCreator forms migrate one by one, and the migration has known edge cases: any organization with dozens of forms should validate each one in staging before cutting over.
Webhooks in core
Native webhooks let GLPI notify external systems when events happen — ticket created, asset added, contract expiring — without writing a plugin or operating external middleware. Outbound HTTPS calls with configurable payloads and signed delivery (CRA/HMAC). For teams running GLPI alongside Jira, Slack, Teams, or a SIEM, this removes a category of integration work that previously meant custom code or third-party connectors.
Two-factor authentication built in
2FA via TOTP and WebAuthn/FIDO2 hardware keys is now a first-class feature, configurable per profile. Combined with improved API access logging and granular session-timeout control, this is the package internal audit teams have been asking for. For organizations under NIS2 or ISO 27001, these are concrete control points an auditor will tick off without a workaround conversation.
PHP 8.2+ and a refreshed interface
GLPI 11 requires PHP 8.2 or higher and ships a refreshed interface built on a more modern frontend stack. Forms, navigation, and dashboards all change visually. For users it means a real retraining moment — not just "where did the button move," but a different mental model in places. The PHP requirement is an infrastructure change as much as an application one: if your server runs PHP 7.4 or 8.0, the OS-level upgrade has to happen first, and any other application sharing the same PHP runtime needs compatibility checked.
What got better, but isn't strictly new in 11
A few things commonly attributed to GLPI 11 actually landed earlier — they got real improvements, but it's worth knowing what's iteration versus what's news:
- Marketplace — the in-app plugin installer has shipped since GLPI 9.5 in 2020. GLPI 11 refines it (better dependency handling, clearer compatibility signals), but the feature itself is five years old.
- GLPI Agent — native inventory landed in GLPI 10. The GLPI Agent (a fork of the FusionInventory Agent maintained by Teclib and the GLPI Network team) replaced the FusionInventory plugin a major version ago. GLPI 11 improves agent management directly inside the web interface — deployment, configuration, monitoring without external tools — but the architectural move was in version 10.
- Dashboards — the dashboard builder was introduced in GLPI 10. GLPI 11 adds widget types, better entity-based filtering, PDF export, and per-profile sharing. Meaningful upgrades, but iterations on a feature that already existed.
What upgrading from GLPI 10 actually involves
The upgrade is a project, not a click. Three areas need explicit planning, and the procedural details live in our dedicated guide on upgrading to GLPI 11.
- Plugins move into core — the GenericObjects and FormCreator plugins are replaced by native features. All plugins are deactivated by the upgrade and need manual re-verification, and several integrations rely on plugin URL paths that changed from
/marketplace/to/plugin/— bookmarks, scripts, and external integrations pointing at old paths break silently. - Database migration — the schema changes substantially. The migration script runs automatically, but on large instances (100k+ tickets, 50k+ assets) it can take hours. Plan a real maintenance window, and budget for re-indexing afterwards.
- Infrastructure — PHP 8.2+ on the application server, plus aligned versions of Composer and the web server config. If the server is shared with other PHP applications, this often forces a server split before the upgrade can start.
When to move (in May 2026)
The earlier "wait for the first patch releases" advice is now obsolete: 11.0.7 has shipped, the patch cadence is healthy, and the early plugin compatibility issues have largely been worked through by the major plugin maintainers. The decision rule shifts from "is the platform ready" to "is your operation ready":
- Plugin inventory — list every plugin you use today, check its GLPI 11 compatibility status, and decide what gets dropped (because its functionality moved into core), upgraded, or kept on GLPI 10 a while longer.
- Form and asset audit — if you use FormCreator and GenericObjects heavily, the migration to native forms and assets is the most labor-intensive part of the upgrade. Time it deliberately rather than fitting it into a maintenance window.
- Compliance window — for organizations subject to NIS2 or ISO 27001, the built-in 2FA and audit-logging improvements can be an upgrade trigger in their own right: closing audit findings is often easier than buying time on a third-party MFA workaround.
GLPI 11 is a good platform. The transition isn't a routine update, but by May 2026 the platform side is no longer the risk — the planning is.