GLPI 10 to 11 upgrade: planning and testing

Why plan the GLPI 10 to 11 upgrade before touching production

The GLPI 10 to 11 move is a planned major upgrade with prerequisite, plugin and data steps, and the supported path runs through a tested copy of your GLPI 10 database, never through the production instance. If your service desk depends on plugins, custom asset types or self-service forms, those pieces need their own migration work before or during the switch. GLPI 11.0.0 was released on October 1, 2025, and the 11.0 line has continued with later point releases, so the target version is no longer a preview. Plan for the move as a project with a named owner, a rollback position and a sign-off step, not as a routine patch.

A minor update in GLPI mostly replaces files and runs php bin/console db:update. A major move changes what the platform expects around it. The installation docs raise the minimum PHP and database versions for GLPI 11.0, and the GLPI 11.0 changelog removes the XML-RPC API and makes the API URL no longer customizable inside GLPI, so any integration that calls the old endpoint needs a web server alias or rewrite rule. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after a major update, so every plugin your team relies on needs a compatibility decision before cutover. Confirm the exact prerequisite versions against the current GLPI installation prerequisites and your own plugin list.

Your first deliverable is an inventory of what GLPI 10 does for your organization: which plugins are active, which Generic Objects and Formcreator forms carry business data, which integrations call the API and which web server rules serve the instance. Restore a copy of the production database and the files into a separate environment, then run the upgrade there and check each item against that inventory. The copy shows you migration errors, plugin breakage and data gaps while the live service keeps running. Record the results, agree the cutover window and keep the GLPI 10 backup, including the glpi.key and glpicrypt.key files, until the new instance has been verified.

What changes in GLPI 11 and what each change means for your instance

This table compares each GLPI 11 change against your current GLPI 10 instance and states what you must do before cutover. Plan against the version you actually install, because the README on the main branch lists higher minimums than the GLPI 11.0 installation docs. The main takeaway is that the platform prerequisites, the XML-RPC removal and plugin reactivation all need checks before you touch production.

Change in GLPI 11	What it means for your instance	Action needed before cutover
PHP minimum for GLPI 11.0	The installation docs list PHP 8.2 or later for GLPI 11.0. The main-branch README lists PHP 8.3 or later.	Confirm the PHP version for the release you install, then upgrade PHP on a test server first.
Database minimum for GLPI 11.0	The installation docs list MySQL 8.0 or MariaDB 10.6. The main-branch README lists MariaDB 10.11 or MySQL 8.0 or later.	Check your current server version and plan a database upgrade if it falls below the target release.
Supported database engines	Only MySQL and MariaDB are supported, so other engines are not an option for GLPI 11.	Confirm your database engine is MySQL or MariaDB before planning the move.
XML-RPC API removed	The GLPI 11.0.0 changelog removes the XML-RPC API, so any scripts or integrations that call it will stop working.	Inventory every client that calls XML-RPC and move each one to the REST API or another supported interface.
API URL no longer customizable in GLPI	The API URL cannot be changed inside GLPI, so older custom paths no longer work as configured.	Recreate the path with alias or rewrite rules in your web server and test each client against it.
Plugin suspension after a new version	Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after a major update.	List every active plugin, confirm each has a GLPI 11 compatible release, and plan reactivation in the test run.
Forms and generic assets moved into the core	Features once provided by plugins, such as Formcreator forms and Generic Objects, now live in GLPI core.	Map each plugin's data to its core replacement and run the migration steps in the order the sibling guides describe.
Document root and update procedure	The update procedure requires a backup of the database, files and config directory including glpi.key and glpicrypt.key before application files are replaced.	Confirm the document root points to the public directory and keep both key files with the backup.

Which version path to plan against

Start by fixing the target before you touch the database. GLPI 10.0.0 was released on April 20, 2022, GLPI 11.0.0 on October 1, 2025, GLPI 11.0.11 on October 1, 2026, and GLPI 12.0.0 on October 7, 2026, according to the glpi-project/glpi releases page. Those dates tell you the order of the releases, but they do not tell you which version you can jump to from your current 10.x install. Ask the GLPI project which 10.x release is the supported entry point for the 11.0 move and whether an intermediate 10.x or 11.0.x step is expected. Confirm this in writing before scheduling, and record the answer in the change plan with the exact version numbers.

Once the entry version is confirmed, treat the choice between stopping at 11.0.x and continuing to GLPI 12.0.0 as a separate planning question. Stopping at 11.0.x means one major move and a longer period on the 11 line. Continuing to 12.0.0 means a second major move, with its own review of plugins, the API, and the database, and it should not be bundled into the first cutover without a decision. Ask Teclib' or your GLPI partner which 11.0.x release they recommend as the baseline, how long they support 11.0.x, and whether 12.0.0 requires changes beyond those in the 11.0 move. Write down which path you chose and the reason, so that the plugin, API and testing work is scoped against the right target.

Ask one more question before you commit: whether the version path changes which prerequisites apply. The installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, while the README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later. If you plan to land on 12.0.0, check the prerequisites for that release separately and align your PHP and database versions with the highest target you plan to reach. Verify these against the GLPI installation prerequisites for the exact release you select, because the requirements can differ between the 11.0 and main-branch documentation.

What to prepare before the GLPI 10 to 11 move

The move from GLPI 10 to 11 changes the platform, the plugins and the web server contract at once. The items below are the inputs to settle before anyone runs an update, and each one feeds the test copy that proves the plan works.

Full backup of the instance

Take a complete backup of the database, the application files and the config directory. The config directory holds glpi.key and glpicrypt.key, which encrypt stored secrets. Without them, restored credentials and encrypted fields cannot be read. Store the backup where a restore can be tested, and confirm that the keys are included in the copy you keep offline.

Plugin inventory and compatibility

List every installed plugin with its version and its vendor's stated support for GLPI 11. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after a major update. Mark each plugin as compatible, needs an update, replaced by core features, or unsupported, and decide the action for each before the upgrade window.

Generic Objects, Fields and FormCreator inventory

Record each asset type built with Generic Objects, each custom field set, and each FormCreator form that users depend on. These move into GLPI 11 core features in a fixed order, so the list defines the migration scope. Note which forms, asset types and rights are used by ticket routing, reports or integrations, because those dependencies break first when the data moves.

PHP and database version check

Compare the PHP and database versions on the current server against the GLPI 11 prerequisites in the installation docs, which list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. Confirm the PHP extensions and the timezone settings the application needs. If a host runs below these levels, plan the platform upgrade as its own change before the GLPI move.

Copy of the GLPI 10 database

Restore a copy of the production GLPI 10 database into a separate environment that matches production as closely as possible. Run the GLPI 11 upgrade, the plugin reactivation and the migration commands there first. Record the duration and every error, and use those results to set the production change plan rather than estimating it from the documentation alone.

Web server rules and XML-RPC aliases

Record every web server rewrite, alias and virtual host rule that routes traffic to GLPI, including the document root pointing to the public directory. GLPI 11.0 removed the XML-RPC API and no longer lets the API URL be customized inside GLPI, so any XML-RPC endpoint alias must be replaced by a rule in the web server. List the clients that call it so each one can be moved before cutover.

Upgrade sequence with checks and rollback points

This sequence moves a GLPI 10 instance to GLPI 11 by proving the upgrade on a restored copy first, so each stage has a verified state and a known rollback point before production is touched. Each step ends with a check that tells the team whether to continue or restore.

Confirm prerequisites and freeze the baseline
Before any change, the team confirms the target PHP and database versions against the GLPI 11 prerequisites, checks that the web server can serve the public directory, and lists every active plugin with its version and its owner. The team also records the current GLPI version and takes a full pre-upgrade backup of the database, the files and the config directory, including glpi.key and glpicrypt.key. The step closes when the backup has been restored successfully to a scratch location and the plugin inventory is signed off. That backup is the rollback point for every later step.
Restore the GLPI 10 database into a test instance
The team restores a copy of the production GLPI 10 database and the matching files into a separate, non-production instance on the same PHP and database stack planned for production. Production remains untouched, and every test run starts from this copy. The check is that the restored instance loads, the login works with a test account, and ticket, asset and plugin counts match the source database. If counts differ, the copy is discarded and recreated before testing continues.
Update PHP and the database engine
If the restored test instance runs an older PHP or database version than the GLPI 11 prerequisites require, the platform team upgrades PHP and MySQL or MariaDB on the test host first. Changes to PHP extensions and database settings are recorded so they can be reproduced in production. The check is that the GLPI requirements check passes on the test instance before any application file is replaced. The rollback point is the host snapshot or package state taken before this step, alongside the backup from the first step.
Replace application files and configure the web server
The team deploys the GLPI 11 application files alongside the existing config directory and keys, without copying over the old files in place. The web server document root is set to GLPI's public directory with URL rewriting routed through index.php. The XML-RPC endpoint is no longer served by GLPI, so any legacy client URL is handled by an alias or rewrite rule at the web server layer, because the API URL cannot be customized inside GLPI. The check is that the login page loads through the new document root and that the legacy XML-RPC path returns the response the team designed, not a server error.
Run the database update and review the output
The team runs the database update from the console with php bin/console db:update on the test instance and captures the full output. The run is reviewed for failed schema changes, warnings about tables that need cleanup, and any messages about plugins. The check is a clean run followed by a login, a ticket view and an asset search as an administrator. If the update fails, the test copy is restored from the backup and the cause is fixed before the next attempt. In production, the same restore path is the rollback point.
Reactivate plugins one at a time
Since GLPI 11 suspends plugins after a new version is detected, each plugin is reactivated individually in the console, starting with those the business depends on most. After each reactivation, the team checks the plugin's pages, its tasks and its notifications before enabling the next one. Plugins whose features moved into the core, or that have no GLPI 11 release, are marked for removal or replacement rather than forced active. The check is a short test script per plugin that the owner signs off. A plugin that breaks is deactivated and logged for the migration plan.
Run the Generic Objects, Fields and FormCreator migrations in order
The data migrations follow the order set by the sibling topics: first the Generic Objects migration to custom asset definitions, then the Fields work that depends on those definitions, then the FormCreator migration to native forms. Each migration runs on the test instance, and its results are checked against the rights, capacities, integrations and form targets recorded in the baseline. The check is a reconciled list of asset types, fields and forms, with every item either migrated, deliberately retired or open. Production repeats this sequence only after the test run is accepted, and the backup from the first step remains the rollback point until the migrated data is accepted.
Accept the upgrade or restore the backup
The business owners test the critical workflows on the test instance, such as ticket intake, approvals, asset lifecycle and integrations, and then decide whether production can move. The production cutover repeats the verified steps against a fresh backup taken just before the change. If any check fails after cutover and cannot be fixed within the agreed window, the team restores the pre-upgrade backup of the database, files and config directory and returns to GLPI 10. The sequence is complete when the signed acceptance record lists each check result and the rollback point retained for the agreed period.

Testing on a copy of the GLPI 10 database and rolling back

Run the first full upgrade rehearsal on a restored copy of the GLPI 10 database, not on the production instance. The copy should carry the same plugins at the same versions, the same GLPI Agent deployment pointing at the test URL, and the same authentication settings, including the order in which GLPI tries the internal database, LDAP and any external methods. A copy that differs in these areas will hide the failures you most need to find, such as a plugin that is suspended after the new version is detected or a directory bind that behaves differently under the new release. Keep a written record of every difference you cannot avoid, such as a changed hostname or a masked mail server, so you can judge later whether a failure is caused by the upgrade or by the test setup.

Test by workflow, not by page load. Sign in as an internal database user, an LDAP user and any other method you rely on, and confirm each one gets the expected profile and entity. Exercise each active plugin's functions, then create, update and close a ticket, an asset and a form submission in the migrated copy. Check that scheduled tasks run and that notifications are sent. Because the XML-RPC API has been removed in GLPI 11.0, test every API client against the rewrite or alias rules you put in place, and confirm that the API URL the client calls is the one your web server now serves. Record each result against the pre-upgrade behavior so the sign-off is evidence, not an impression.

Rollback depends on the pre-upgrade backup taken under the update procedure: the database, the application files and the config directory, including glpi.key and glpicrypt.key. Keep the old application files in a separate, dated location until the upgrade is signed off, because restoring the database alone does not return the code to GLPI 10. If the encryption keys in the config directory are lost or changed, encrypted fields and stored credentials may not decrypt after a restore. Confirm the restore sequence on the test copy first: stop the web server, restore the database and files, restore the config directory, and run a login and a ticket check before you reopen access. Ask your implementation partner or internal team to write this sequence down and time it in your own environment.

What makes a GLPI 10 to 11 upgrade take longer

Most of the time in a GLPI 10 to 11 move goes to what sits around the core upgrade: plugins, migrated data, integrations, sign-in paths and the platform underneath. Each driver below is something you can measure in your own instance before you agree on a scope and timeline.

Plugins that need replacement or reactivation

GLPI suspends plugins once it detects a new version, and major updates require you to reactivate them. Some plugins have no GLPI 11 release, and others have had their features moved into the core, so they need to be retired rather than reactivated. Inventory every active plugin, its version, its owner and whether it still has a maintained release for GLPI 11 before you size the work.

Volume of Generic Objects and FormCreator data

Asset types built with the Generic Objects plugin and self-service forms built with FormCreator are migrated into core structures, and the migration effort scales with how many types, fields, dropdowns, forms and questions you have. Count the definitions, the records behind them and the rules, dependencies and integrations that reference them. Migrate Generic Objects first, because forms may depend on those asset types.

Custom integrations that call the XML-RPC API

The GLPI 11.0.0 changelog removes the XML-RPC API and no longer lets you customize the API URL inside GLPI. Any script, monitoring hook or middleware that sends XML-RPC requests must move to a supported interface, and any alias or rewrite rules must be set in the web server. Identify each caller, its credentials and its failure behavior, then retest every one against a copy of the instance.

Authentication sources that need retesting

GLPI checks authentication against the internal database, LDAP directories, IMAP servers and external methods such as REMOTE_USER, in that order. A change in web server configuration, certificates or directory settings can alter which source answers a login. Test each source with a real account from every group and profile, including accounts that should be denied, and confirm that single sign-on still maps users to the right entity and profile.

PHP and database upgrades on shared servers

GLPI 11.0 requires PHP 8.2 or later and MySQL 8.0 or MariaDB 10.6, and the README for the main branch lists PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later. On a server shared with other applications, a PHP or database upgrade can break those applications, so the runtime change may need its own plan. Confirm the exact versions for the release you target and whether the database engine can move to the required version without affecting neighbors.

Size of the database and file store

The migration and the test copy both depend on how large the database and file store are. Large ticket histories, document attachments and log tables take longer to back up, restore, migrate and verify, and a full copy of the GLPI 10 database and files must exist before testing can start. Measure the database size, the files directory and the free disk space needed for the copy, and plan the backup window and the restore test around those numbers.

Questions teams ask before a GLPI 10 to 11 upgrade

How much does a GLPI 10 to 11 upgrade cost?

The cost depends on the scope agreed in writing before work starts, and no fixed figure applies to every instance. The main components are planning, the PHP and database prerequisite work, plugin compatibility checks and reactivation, migration of Generic Objects, Fields and FormCreator data, and testing on a copy of the GLPI 10 database. Plugin count, the volume of custom asset types and forms, the number of integrations, and how many environments need validation push the cost up. Ask any provider for a quote that lists each phase, who performs it, what is one-time and what recurs, and which items are excluded. DeployOpen does not publish a price list, and a quote follows from the written scope. If you use GLPI Network subscriptions, confirm their separate fees with Teclib' rather than treating them as part of the upgrade.

How long does a GLPI 11 upgrade take?

Duration is set by the number of plugins that need checking, the amount of data to migrate, and how long your sign-off cycle takes. No supplied benchmark gives a general duration, so confirm the timeline against your own environment. The longest phases are usually plugin compatibility review and testing on a copy of the GLPI 10 database, because each migrated record type needs checking by the people who use it. Schedule a production cutover window separately from the build, and allow time for owners to review results. A fixed-scope plan should show a start condition, each milestone and the acceptance step for each one.

What must our team provide before the upgrade starts?

Your team needs to provide access and a clear list of inputs before any work begins. Typically this includes:

Administrative access to the GLPI 10 server, web server, database and the config directory, plus a test environment where the copy can run
A current backup of the database, the files and the config directory, including glpi.key and glpicrypt.key
A full plugin inventory with versions, owners and the features each plugin supports
Named business owners who can approve forms, asset types, rights and reports during testing

Agree on who signs off each stage and what evidence counts as acceptance. Without named owners, testing tends to stall at the end of the project.

Can our internal team perform the GLPI 11 upgrade alone?

An internal team can perform the upgrade if it has PHP and database administration skills, web server experience, and time to test migrated data with the business. The work requires familiarity with GLPI's console commands, plugin behavior and the update procedure in the installation documentation. Teams often underestimate the testing effort, the plugin reactivation review and the rework needed for custom forms or asset definitions. Assess your team against the prerequisites and the list of plugins before deciding. A partner can take on part of the work, such as the migration rehearsal, while your staff keep ownership of production and sign-off.

What happens to our plugins after the GLPI 11 update?

After a new version is detected, GLPI 11 suspends plugins, and they must be reactivated after a major update. Before you reactivate anything, check whether each plugin supports GLPI 11 and whether its features now exist in the core. Plugins for Generic Objects and FormCreator have migration paths that must run in order, so their data should not be treated as ordinary plugin data. Some older plugins may need replacement rather than reactivation. Confirm each plugin's status with its publisher and test it on the copy before production. The dedicated plugin guidance covers the decision for each one.

Does the removal of the XML-RPC API affect our integrations?

Yes, if any integration calls the XML-RPC API, that call will stop working on GLPI 11. The GLPI 11.0.0 changelog lists the removal of the XML-RPC API and states that the API URL can no longer be customized inside GLPI. If you need the old URL to keep working, you must use alias or rewrite rules in your web server. Start by inventorying every system that talks to GLPI, including scripts, monitoring tools, agents and middleware. Then decide whether each one should move to the supported API or keep a web server rule. Test each integration on the copy of the GLPI 10 database.

What should we check on the PHP and database side before upgrading?

Confirm that your PHP and database versions meet the GLPI 11.0 requirements in the installation documentation, which lists PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and that only MySQL and MariaDB are supported. Note that the GLPI README on the main branch lists newer requirements, so check which release you are targeting before you upgrade the platform. Also confirm that the web server document root points to the public directory with URL rewriting enabled. Review each PHP extension and database setting on the copy, not only on paper.

Where to confirm version requirements and the changelog

Before you size hosts or schedule a window, confirm the PHP and database requirements for your target GLPI version in the official installation docs, not in an older blog post or a forum thread. The prerequisites page lists the PHP and MySQL or MariaDB versions for GLPI 11.0, and the GLPI README on the main branch lists different minimums for the current development line. Those two sources do not describe the same release, so record which version each figure applies to and build your plan against the one you intend to install. Also confirm that your web server layout matches the documented requirement that the document root points to the public directory.

The GLPI 11.0 changelog is the primary record of what changed between 10 and 11, including the removal of the XML-RPC API and the loss of the ability to customize the API URL inside GLPI. Read it in full against your current configuration, then list every integration that calls the old API so the owners can plan web server alias or rewrite rules. Use the GLPI 11.0 changelog as the starting point, and confirm any later 11.0.x fixes on the releases page before you freeze the target version.

Finally, check the GLPI releases page for the exact version you plan to target and read its release notes, since point releases can carry fixes that affect the upgrade path. Keep a dated copy of the requirements, changelog excerpt and release notes with your change record. Auditors and your own change board will ask which version you validated, and that answer should come from the documents you saved, not from memory.

How DeployOpen scopes and delivers a GLPI upgrade

DeployOpen plans and carries out GLPI 10 to 11 upgrades inside infrastructure you control, starting with a written scope that covers prerequisites, plugins and data. The work is rehearsed on a copy of your GLPI 10 database before any change reaches production, and each step is documented for your team.

How we scope

Inventory the current GLPI version, PHP and database versions, web server layout and every installed plugin.
Check each plugin for 11.x compatibility and record which ones need reactivation, replacement or retirement.
Confirm which Generic Objects, Fields and FormCreator data must migrate, and in what order, before fixing the scope.

How we build

Prepare PHP and MySQL or MariaDB to the versions the GLPI 11 installation docs require, in your environment.
Rehearse the upgrade on a copy of the GLPI 10 database, including the migration commands and plugin reactivation.
Move the XML-RPC API consumers to alias or rewrite rules in the web server, since GLPI 11 removed the built-in XML-RPC API.

How we hand over

Deliver a runbook covering backups of the database, files and the config directory with glpi.key and glpicrypt.key.
Document the test results, plugin decisions and any data mapping changes so your team can repeat the process.
Walk your administrators through post-upgrade checks, including integrations and API clients that depended on the old endpoint.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing for GLPI are available as a retainer after the upgrade.
Ask us to confirm the GLPI 12 path and any later update steps against the release notes before your next change window.

GLPI 10 to 11 upgrade