Move GLPI to a new server

Moving GLPI to a new server without losing data or encryption keys

A GLPI move to new hardware, a new VM or a new network zone is mostly three copies: a database dump, an archive of the files directory and a copy of the config directory. The config directory holds glpi.key and glpicrypt.key, and without them the encrypted values in the database cannot be read on the new host. The effort depends on the GLPI version, the plugins installed, the PHP and database versions on both hosts, and how the web server is laid out. A clean instance with no plugins and matching PHP and MariaDB or MySQL versions is usually a small job. An instance with years of custom fields, plugins, LDAP settings and custom web server rules takes more planning and more testing before cutover.

The files archive needs care. GLPI's export procedure dumps the database with mysqldump and archives the files directory while excluding _cache, _cron, _dumps, _graphs, _lock, _log, _rss, _sessions, _tmp and _uploads, as described in the GLPI export procedure. Confirm with your own instance whether _uploads holds documents attached to tickets and assets before you exclude it, because the exclusion list is a default for that procedure and your retention needs may differ. Keep the database dump and the files archive from the same moment, and freeze writes during the copy so the two match.

On the new host, confirm that the PHP and database versions meet the prerequisites for your target GLPI version and that the web server document root points to GLPI's public directory. Before you serve users, run the console checks, including php bin/console db:update if the code version changed, and review the plugin list, since plugins are suspended after a new version is detected and must be reactivated. Check the GLPI update documentation for the exact steps for your version, and rehearse the whole move on a copy before the production cutover.

What moves cleanly and what needs a decision

This table compares each part of a self-hosted GLPI instance with what it becomes on the new host and the migration note that applies. Read it as a checklist: components marked as copied as-is need only verification, while rows about keys, web server layout and plugins need a deliberate choice before cutover.

Component	Equivalent on the new host	Migration note
Database	Same engine and version family on the new server, loaded from a mysqldump	Dump with mysqldump and restore before the first console run. Confirm the engine is MySQL or MariaDB supported by your target GLPI version.
Files directory	Same files directory path, restored from an archive	Exclude the _cache, _cron, _dumps, _graphs, _lock, _log, _rss, _sessions, _tmp and _uploads folders from the archive, then recreate them empty with correct permissions. Confirm whether you need _uploads for attachments before excluding it.
Config directory and keys	Config directory copied intact, including glpi.key and glpicrypt.key	The keys must travel with the config. Without them, encrypted values in the database cannot be read. Store copies in your secrets process, not in the general file archive.
Plugins	Plugin directory copied, then each plugin checked against the target version	Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. Confirm each plugin supports the target version before reactivating.
Web server vhost and document root	New vhost pointing the document root to the public directory, with URL rewriting to index.php	Do not point the document root at the installation root. Apache, Nginx, lighttpd and IIS each need their own rewrite rules, so test routing before DNS changes.
PHP extensions and version	PHP version and extensions matched to the target GLPI release	The GLPI README lists PHP 8.3 or later for the current main branch, while the GLPI 11.0 docs list PHP 8.2 or later. Confirm the version for your release on the prerequisites page before building the host.
Cron and scheduled tasks	Cron entry or scheduler recreated on the new host	Scheduled tasks do not follow the database automatically in every setup. Confirm the system cron entry exists and runs the GLPI task command on the new host.
TLS certificates	New certificate issued for the new host name, or the existing one installed	Certificates are tied to host names and private keys, which are not part of the GLPI archive. Plan renewal and the DNS cutover date together.

How the cutover runs from dump to decommission

The sequence moves a self-hosted GLPI instance to a new host with a verified database, files and keys, and leaves the old host intact until the new one has proven itself. Each step closes with a check you can record before the next one starts.

Inventory the current versions and plugins
Record the GLPI version, the PHP version, the database engine and version, the web server, the installed plugins and their versions, and the cron setup on the current host. Compare these against the prerequisites in the GLPI installation docs for the target version, because the target host must match or exceed them. Plugins need their own compatibility check, since GLPI 11 suspends plugins after a new version is detected. The output is a written inventory that the cutover team signs off before any build work starts.
Build the new host to the prerequisites
Provision the new server or container host with the PHP extensions, database server and web server that the installation docs list for the chosen GLPI version. Set the web server document root to GLPI's public directory rather than the installation root, and configure URL rewriting so requests route through index.php. The check at the end of this step is a clean GLPI install page or a fresh instance that loads over HTTP on the new host, with the database server reachable from the application server only.
Dump the database and archive the files
Put the old instance into a quiet state, then dump the database with mysqldump. Archive the files directory while excluding the documented cache, cron, dumps, graphs, lock, log, RSS, session, temporary and uploads folders, following GLPI's export procedure. Copy the config directory in full, including glpi.key and glpicrypt.key, because encrypted data in the database cannot be read without them. Store the dump, archive and config copy together with checksums, and confirm they can be read back before the old host is touched again.
Restore the data and run the console checks
Restore the database, unpack the files archive and place the config directory on the new host, then point the application at the restored database. Run GLPI's console checks and, where the target version requires it, php bin/console db:update. Reactivate plugins one at a time after the update, and check each plugin's own documentation for required steps. The step is complete when the console reports no blocking errors, login works, and a sample of tickets, assets and attachments opens correctly.
Test on a staging copy and run in parallel
Run the restored instance against a staging copy of real data with a limited group of testers. Test authentication against your directories, scheduled tasks, notification email, and any inventory agents or integrations. Where the business allows, run the old and new hosts side by side for a short period so that differences surface before users depend on the new host. Agents that report to GLPI may need their server address updated, so check agent configuration and confirm that inventory arrives on the new host. The output is a signed test log with any open defects.
Cut over DNS or the load balancer
Schedule the switch in a change window and lower DNS time to live beforehand if your DNS process requires it. Repoint the DNS record or the load balancer target to the new host, then repeat the sign-in and ticket checks against the public name. Confirm that the TLS certificate, the URL in GLPI's configuration, and any SSO redirect URIs match the new address. The step closes when users reach the new instance and the old host no longer receives traffic.
Keep the old host read-only for rollback
Keep the old host running but read-only, with its database and files preserved, for a rollback window agreed in advance. Disable writes at the application or database level, and stop scheduled tasks on the old host so it does not send notifications or change data. Record any defects found in the window and decide whether the new host stands. The output is a rollback decision recorded in writing and an agreed end date for the window.
Decommission the old host
After the rollback window closes and the decision is recorded, retain a final backup of the old host according to your retention policy, then remove its DNS entries, firewall rules, monitoring and agent references. Revoke any credentials that only the old host used and update the asset record in GLPI itself so the old server is shown as retired. The step is complete when the old host has no live services, the final backup is verified, and the change ticket is closed with evidence attached.

Documented export, backup and console paths

GLPI's Help Center describes an export procedure for a local instance that dumps the database with mysqldump and archives the files directory. The archive excludes folders that hold regenerable or transient data, so the copy stays smaller and avoids carrying stale sessions into the new host. Treat the procedure as the starting point for your own runbook, not a complete migration plan, because it does not cover the web server, PHP settings, certificates or scheduled tasks on the destination.

Database dump: Run mysqldump against the GLPI database while the application is quiet, and store the output with a checksum.
Files archive: Archive the files directory and exclude _cache, _cron, _dumps, _graphs, _lock, _log, _rss, _sessions, _tmp and _uploads as the procedure lists. Confirm each excluded folder against your version, because _uploads holds documents attached to tickets and assets.
Excluded folders: Excluded folders are rebuilt by GLPI or are transient, but _uploads is not transient, so it needs its own copy if you use it.
Quiet window: Plan the dump and archive for a period when no one is creating tickets or running inventory.
Source version: Record the exact GLPI version on the source host so the destination can be installed at the same version first.

Check that the dump restores into a test database and that the archive unpacks with the expected folder structure before you decommission the old host.

The GLPI update procedure requires a backup of the database, the files and the config directory, and it names glpi.key and glpicrypt.key as files that must be included. These keys protect data that GLPI stores in encrypted form, so the new host cannot read that data without them. Losing the keys is a different failure from losing the database: the restore may succeed while stored credentials and other encrypted values become unreadable.

Config directory: Copy the whole config directory, not only the database connection file.
glpi.key: Keep this key with the database dump and treat it as a secret with restricted access.
glpicrypt.key: Back up this key alongside glpi.key, and record where each copy is stored.
Separate storage: Keep the key copies in an encrypted store with access logging, not in the same archive as the database dump.
Version match: Confirm in the installation documentation for your version how the keys are referenced on the new host before you start the restore.

Verify that the destination reads the restored keys before users sign in, by testing a stored credential or an encrypted field on the new instance.

After the files and database are in place, GLPI's command line tool, bin/console, runs the checks and the database update that bring the instance into a working state. The update procedure uses php bin/console db:update after the application files are replaced. Command names, options and their behavior can change between major versions, so confirm each command with php bin/console list and --help on the exact version you installed.

Command discovery: Run php bin/console list to see which commands your installed version provides.
Database update: Run php bin/console db:update only after the application files match the target version, and read its output before continuing.
Plugins: Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so schedule time for this review.
Status checks: Use the status and maintenance commands listed for your version to confirm the database connection, the key files and the scheduled tasks.
Web checks: Confirm the document root points to the public directory and that URL rewriting routes requests to index.php before you test logins.

Record the output of each console command in your change record, since auditors and the next upgrade both rely on that evidence.

Why the keys and the database must move as a pair

The database and the key files must move together, because GLPI stores some sensitive values in encrypted form and the key files are what decrypt them. The config directory holds glpi.key and glpicrypt.key, and the GLPI update procedure treats both as part of the backup set alongside the database and files. A database restored onto the new host without the matching keys can start cleanly and still leave stored credentials, such as external authentication or mail settings, unreadable. Copy the keys from the same moment as the dump, and keep the old host's copies until the new instance has been verified.

Order matters. Stop or quiet user activity, take the mysqldump of the database, archive the files directory with the cache and session folders excluded, and copy the config directory in the same window. A dump taken while technicians are creating tickets, updating assets or running automatic actions can capture rows that reference records written after the files archive was made, so the database and files disagree. Restore the database, place the files and config directory, point the web server at the public directory, then run the console checks before any user signs in. Confirm the exact database and web server versions against the GLPI installation prerequisites for your target release.

Plan a short verification pass before cutover. Log in as an administrator, open a sample of recent tickets and assets, test one configured credential or integration, and confirm that the scheduled tasks and notification queue behave on the new host. If a stored secret fails while everything else looks healthy, the keys are the first thing to compare against the source. Ask your DeployOpen contact or your own platform team to record the file checksums of the keys before and after the move, so the check is a comparison, not a guess.

What drives the effort of a GLPI server move

This table lists the factors that change how much work a GLPI server move takes and which ones recur after go-live. Use it to see which answers you need before asking for a fixed-scope quote, since a move with a large database, many plugins and a version change is a different job from a plain copy to a matching host. The main takeaway is that the version and plugin answers matter more than raw file size.

Driver	Why it changes effort	What to confirm or request in writing
Database size and engine	Dump, transfer and restore time grow with data volume. The docs require MySQL 8.0 or MariaDB 10.6 or later for GLPI 11.0, so an older engine adds a prerequisite step.	Current engine and version, database size, and whether the target engine matches or differs from the source
Files directory volume	The archive excludes cache, session and temporary folders, but uploaded documents and generated files can still be large and slow to transfer.	Size of the files directory after exclusions, and the transfer method and window
Plugin count and complexity	Each plugin must be checked on the new host. Since GLPI 11.0, plugins are suspended when a new version is detected and need reactivation after major updates.	Full plugin list with versions, custom or third-party plugins, and who tests each one
Web server and reverse proxy layout	Custom vhosts, rewrite rules, load balancers and proxy headers must be rebuilt so the document root points to the public directory.	Current web server, proxy chain, vhost files and any custom rewrite rules
PHP version change	The target PHP version must meet the GLPI release requirements, and extensions must be installed and tested before the database is loaded.	Current and target PHP versions and enabled extensions
Docker image on the target	A containerized target changes where the files, config and keys live, and how volumes and the database connection are configured.	Whether the target is Docker or Linux, volume mapping and secret handling
TLS and DNS changes	New certificates, hostname changes and cutover records affect login, agent connections and any SSO redirect URLs.	Hostname plan, certificate source, DNS TTL plan and SSO or CAS redirect URIs to update
Inventory agent endpoints	Agents and any scripts pointing at the old server must be repointed. Large fleets need a staged change, and some endpoints may be missed.	Agent count, how agents are configured and deployed, and the list of systems that call GLPI
Downtime window	A short window needs a tested dump and restore and a rehearsed rollback. A longer window allows a staged or parallel check.	Acceptable outage window, cutover approach, and the rollback point defined in advance
Combined GLPI 11 or 12 upgrade	Moving and upgrading in one step adds database update work, plugin reactivation and new prerequisites on top of the move.	Target GLPI version, whether the upgrade is separate or combined, and the plugin compatibility review
Ongoing key and backup handling (recurring)	The config directory must carry glpi.key and glpicrypt.key so encrypted data stays readable. Backups must be repeated after each later move or update.	Key custody, backup schedule and who restores and verifies backups after go-live

What usually goes wrong during a GLPI server move

Most GLPI moves fail in small, predictable places: a missing key file, a copied cache folder, or a web server still pointing at the old path. Each risk below is easy to prevent with a check run before cutover, and each one shows up later as a symptom that is harder to trace back to the move.

Missing key files

Without glpi.key and glpicrypt.key in the config directory, the new host cannot decrypt the encrypted data in the restored database, such as stored credentials and secrets. The database restores cleanly, so the failure appears later as unreadable fields or broken integrations. Copy the entire config directory with the database and files, and confirm both key files exist with the same content on the new host before the first login.

Copying cache and session folders

The _cache and _sessions folders hold generated data and login state tied to the old host. Carrying them over can serve stale translations or dashboards, and it can keep users logged in against a host that no longer exists. Exclude _cache, _sessions, _tmp, _lock and the other excluded folders from the archive, then let GLPI rebuild them on first use.

Document root left at the installation root

GLPI must be served from its public directory, with URL rewriting routing requests through index.php. If the new web server points at the installation root, configuration and source files become reachable over HTTP, and the application routes break. Set the document root to the public directory on the new host and test a deep link, not only the home page, before users are redirected.

Dumps taken during writes

A database dump taken while GLPI is processing tickets, inventory or notifications can capture an inconsistent state, with a ticket saved but its history missing. Stop the web server or put users in a maintenance window, pause cron and agent check-ins, then dump. Compare the file and database snapshots taken at the same time, so the two halves of the instance match.

Plugins suspended after version change

Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. A move that also changes the GLPI version can leave plugin-driven forms, workflows and integrations switched off on day one. Record the plugin list and versions before the move, and plan to reactivate and test each plugin on the new host.

Old endpoints still pointing to the host

Cron jobs, GLPI Agent configurations, LDAP or SSO callback URLs, and email connectors often store the old hostname or run from the old server. Inventory keeps arriving at the retired host, notifications stop, and SSO logins fail with redirect errors. Make a list of every endpoint and scheduled task that references the old host, update each one, and keep the old server read-only until the list is clear.

Questions teams ask before moving GLPI

How much does it cost to move GLPI to a new server?

The cost depends on the size of the database and files directory, how many systems connect to GLPI, whether the new host is built from scratch, and how much testing the change window requires. Most of the effort sits in planning, a rehearsal on a staging host, the cutover itself and checks afterward. No public price applies to this work. Ask for a fixed-scope quote based on a written list of hosts, data volumes, integrations to repoint (such as LDAP, mail and inventory agents) and the number of rehearsals you want. Ask which items are one-time and whether any ongoing support is included or optional.

How long does a GLPI server move take?

The duration is set less by the copy itself than by the change window you can use, the time needed to rehearse on staging, and the number of systems that must be repointed. The database dump and file archive scale with data volume, so measure both on your current host before planning. Agree the window and the rollback point in writing before work starts, and confirm which services must stay available during cutover. Your scope document should state the timeline once those inputs are known.

What does my team need to provide for a GLPI move?

Plan to provide the following before work starts:

Administrative access to the current GLPI host, database and web server, with the ability to stop services
Access to the new host, including its operating system, PHP and database versions, and network paths
A change window approved by the owners of tickets, inventory and integrations
A staging host that mirrors production closely enough to rehearse the move
A copy of the config directory with glpi.key and glpicrypt.key, stored securely
Contacts for LDAP, mail, DNS and any agent or monitoring systems that point to GLPI

Can our own team move GLPI without a partner?

Yes, if you have people who can manage a Linux web server, PHP, a MySQL or MariaDB database and file permissions. The GLPI documentation describes the export and update steps, but the work still requires judgment about cache and session folders, key files, web server document root and post-move console checks. A partner is useful when the team lacks that experience, when the window is tight, or when many integrations must be verified. Compare the internal effort against a fixed-scope quote, and confirm who owns the rollback decision.

Should we combine a GLPI version upgrade with the server move?

Usually not, because combining the two changes makes failures harder to isolate. Moving the server first on the same version gives you a known-good baseline to verify. A version upgrade later means running the update procedure, which requires its own backups and may suspend plugins until they are reactivated. If the upgrade is required on the new host, plan it as a separate step with its own rehearsal. Ask your provider to explain how the plan sequences the move and any upgrade, and what each stage must prove before the next begins.

How does rollback work if the new GLPI server fails?

Rollback depends on keeping the original host intact until the new one is verified. Before cutover, take a database dump and an archive of the files directory, and keep the config directory with its keys. If checks fail, stop writes on the new host, restore the original DNS or load balancer target, and confirm that users can sign in and that the database has no unexpected changes. Agree the point after which rollback is no longer simple, such as when users have created tickets on the new host, and document how that data would be reconciled.

What checks should run on the new GLPI host after the move?

Run the GLPI console checks on the new host to confirm that the database connection, file permissions and configuration load correctly. Then verify sign-in through each authentication method in use, check that scheduled tasks run, confirm that the web server serves only the public directory, and test email notifications and inventory agent connections. Confirm that the glpi.key and glpicrypt.key values match the originals, since encrypted data depends on them. Ask for a written verification checklist as part of the scope.

Official GLPI sources for the move

Before you dump a database or copy a single file, read the official procedures for the move and the version you are running. The GLPI Help Center page on exporting the local database and files describes the dump and archive steps this topic summarizes, and it is the first read for the export itself. Use it to confirm the exact exclusions for the files directory and the current mysqldump options before you script anything, because a procedure written for one release can drift from the next.

The GLPI installation docs update page covers what happens after the files are in place on the new host. It lists the backups that must exist first, including the config directory with glpi.key and glpicrypt.key, and it explains the php bin/console db:update step. Read the section on plugins as well: since GLPI 11.0, plugins are suspended when a new version is detected, so plan to reactivate them deliberately rather than assuming they will carry over unchanged.

The GLPI installation docs prerequisites page sets the target host baseline. Compare the PHP version, the MySQL or MariaDB version and the web server requirements against the new server before you copy anything, and confirm the document root must point to GLPI's public directory with URL rewriting in place. Check these against the release you will run on the new host, since the supported versions differ between GLPI 10 and GLPI 11 and the requirements can change in later releases.

How DeployOpen scopes and delivers a GLPI server move

DeployOpen plans and carries out GLPI server moves inside infrastructure you control, from the written scope through to a documented handover. We treat the database, files directory and config directory with keys as one set that must arrive together and be checked on the new host.

How we scope

Inventory the source host, PHP and database versions, web server layout and plugins currently installed
Confirm the target host, network path, storage and the GLPI version that will run after the move
Agree in writing which directories, keys and plugin reactivation steps are in and out of scope
Record a rollback point and the cutover window with your team before any work starts

How we build

Dump the database and archive the files directory, excluding cache, session, temporary and log folders
Carry the config directory with glpi.key and glpicrypt.key so encrypted data stays readable on the new host
Point the web server document root at the public directory and confirm URL rewriting routes through index.php
Run the console checks on the new host and test logins, plugins and scheduled tasks on a staging copy first

How we hand over

Deliver a runbook listing each archive, checksum, configuration change and console check performed
Document the cutover order, rollback steps and the people who approve each stage of the move
Walk your administrators through post-move checks, including plugin status and notification queue health
Hand over the final scope record so future upgrades start from a known, documented state

How we support

Fixed-scope engagements are agreed in writing, with deliverables and timelines set before work starts
Ongoing support, upgrades and continuous testing are available as a retainer after the move
Ask any partner to confirm how they will handle keys, session data and backup retention for your environment
Ask for a quote built from the written scope, since DeployOpen does not publish a price list

Move GLPI to a new server

Moving GLPI to a new server without losing data or encryption keys

What moves cleanly and what needs a decision

How the cutover runs from dump to decommission

Inventory the current versions and plugins

Build the new host to the prerequisites

Dump the database and archive the files

Restore the data and run the console checks

Test on a staging copy and run in parallel

Cut over DNS or the load balancer

Keep the old host read-only for rollback

Decommission the old host