Migrating from GLPI 10 to GLPI 11 almost never fails at the database update command - it fails at what comes before and after it. This guide consolidates the playbook we apply supporting client environments: where things really break, how to armor each step and how to roll back if something goes wrong.
First things first: why migration needs method
Migrating from 10 to 11 changes the database schema irreversibly and replaces the entire presentation layer (now on Symfony and Twig). It is not a "swap the files and go". The two things that cause the most unplanned downtime are incompatible plugins left active during the update and the PHP version on the server. Treat the migration as a small project, with a window and a rollback plan, not as a hotfix. Also plan to tell users the 11 interface looks different from 10 - a good share of post-migration tickets are people lost in the new layout, not actual bugs.
Pre-migration checklist
- Full backup of the database (mysqldump) and of the configuration and data directories.
- Be on the latest GLPI 10 minor (most recent 10.0.x) before jumping to 11.
- PHP 8.1+ installed and active in the correct CLI and FPM version.
- A plugin inventory with each one's GLPI 11 compatibility status.
- A staging environment with a real copy of the database to rehearse the migration.
Plugins: what changes in GLPI 11
| Plugin | Status in GLPI 11 | Action before migrating |
|---|---|---|
| FormCreator | Absorbed into the core (native forms) | Disable and remove |
| GenericObject | Absorbed into the core (custom objects) | Disable and remove |
| FusionInventory | Discontinued | Migrate to the GLPI Agent |
| Fields, Escalade, DataInjection, PDF, Tag | Have a version for 11 | Update after the migration |
| NexTool | Compatible with 10 and 11 | Update to the 11 version |
| Plugins with no update since 2023 | Likely incompatible | Assess replacement |
1. Full backup (and tested)
A backup you have never restored is not a backup, it is a hope. Generate it and at least validate the file size:
# Database
mysqldump -u root -p --single-transaction glpi > /backup/glpi_pre_migration.sql
# Files (config, data and plugins)
tar -czf /backup/glpi_files_pre_migration.tar.gz /var/www/glpi /etc/glpi /var/lib/glpi2. Disable incompatible plugins
In GLPI 10, go to Setup > Plugins and disable every one without a version for 11. Remove the directories of the incompatible ones. This step is not optional: it is the number 1 cause of failure at the update command.
3. Update the GLPI files
cd /tmp
wget https://github.com/glpi-project/glpi/releases/download/11.0.0/glpi-11.0.0.tgz
tar -xzf glpi-11.0.0.tgz
# Replace files while preserving config, data and plugins
rsync -av --delete /tmp/glpi/ /var/www/glpi/ --exclude plugins/ --exclude marketplace/
chown -R www-data:www-data /var/www/glpiAlways download the latest stable release of the 11.x line, not necessarily 11.0.0.
4. Run the database migration
php /var/www/glpi/bin/console db:update --no-interactionThis command applies all schema migrations. Watch the entire output - any error must be resolved before moving on, never ignored.
5. Clear cache and sessions
php /var/www/glpi/bin/console cache:clear
rm -rf /var/lib/glpi/_sessions/*6. Post-migration verification
- Login works and the version under Setup > General shows 11.x.
- Tickets, assets and users are present with the expected totals.
- Opening a new ticket works end to end.
- Logs with no recurring errors after a few minutes of use.
- Re-enable and update the compatible plugins one by one, testing between each.
What we learned in production support
In practice, the migration rarely fails at db:update itself. It fails afterwards: an incompatible plugin left active that brings the interface down with a 500 error, the FPM PHP pointing to a version GLPI 11 does not accept (while the CLI is already on 8.1), or the client who skipped a 10 minor and reaches the update command with a schema that does not match. That is why our playbook always updates to the latest 10.0.x first, validates, and only then jumps to 11 - re-enabling plugins one by one, never all at once, because when something breaks you need to know exactly which plugin was responsible.
The most common pitfall
The classic mistake is assuming FormCreator forms migrate on their own to GLPI 11's native forms. They do not: the plugin goes away, but the forms it created must be rebuilt manually in the new core. Inventory the FormCreator forms before removing the plugin, or you will discover the loss in production, with a user complaining that the form vanished. The second most common error is running db:update with an incompatible plugin still active: the console tries to load the plugin, hits an API that no longer exists and aborts mid-migration.
Rollback: when something goes wrong
Because the schema change is irreversible, rollback is not "undo" - it is restoring the previous state. That is why the tested backup from step 1 is non-negotiable:
# Restore files
tar -xzf /backup/glpi_files_pre_migration.tar.gz -C /
# Restore database
mysql -u root -p glpi < /backup/glpi_pre_migration.sqlRehearsing this restore in staging before the real window is what separates a scare from an incident.
Next step
After the migration, explore the native forms and the rest of GLPI 11's new features, and reintroduce the essential plugins. To expand the core without piling up plugins that break at the next major, NexTool concentrates dozens of modules into a single plugin, with versions for 10 and 11. Need support with the migration? Talk to the team.
Reviewed by the NexTool Solutions team.
