Migrate GLPI to a New Server: A Step-by-Step Guide

Hey guys! So, you’re looking to give your GLPI a shiny new home on a different server? Maybe your current one is groaning under the weight of all those IT assets and tickets, or perhaps you’re just upgrading to something faster and more robust. Whatever the reason, migrating GLPI can seem like a daunting task, but trust me, with a solid plan and this guide, you’ll be sailing smoothly in no time. We’re going to break down the entire process, from backing up your current setup to getting everything humming on the new machine. Think of this as your roadmap to a successful GLPI server migration, ensuring minimal downtime and zero data loss. Let’s dive in!

Preparing for the GLPI Migration

Alright, before we jump headfirst into moving anything, proper preparation is absolutely key for a smooth GLPI migration. This isn’t the kind of thing you want to rush into without a plan, or you might end up with a mess that’s harder to fix than the original problem. So, what exactly does preparation involve? First off, you need to assess your current GLPI environment . What version are you running? What are the database details? Are there any custom plugins or themes installed? Knowing these specifics will help you ensure compatibility with the new server and any potential upgrades you might be considering. Document everything – seriously, write it down! This includes your server specs, OS, web server (Apache or Nginx), PHP version, and database server (MySQL/MariaDB or PostgreSQL). This documentation will be your bible during the migration process.

Next up, choose your new server wisely . Think about performance needs, scalability, and security. Whether you’re going for a dedicated server, a VPS, or even a cloud instance, make sure it meets or exceeds the requirements of your current and future GLPI usage. Install the necessary prerequisites on the new server: a compatible web server, the correct PHP version (check the GLPI documentation for version compatibility!), and the database server. It’s often a good idea to set up a staging or testing environment that mirrors your production setup as closely as possible before the actual migration. This allows you to test the process without risking your live data. Don’t forget about network configuration and firewall rules . Ensure that the new server can be accessed by your users and that the necessary ports are open for the web server and database. Perform a full backup of your current GLPI installation . This is non-negotiable, guys! Back up both the GLPI files (the directory where GLPI is installed) and the database. Test your backups to make sure they are valid and restorable. This safety net is crucial; if anything goes sideways, you can always roll back to your current working state. Lastly, plan your downtime . Communicate with your users about when the migration will occur and how long the service might be unavailable. Even with the best planning, some downtime is usually unavoidable, so managing expectations is super important. By taking these preparatory steps, you’re setting yourself up for a much less stressful and much more successful GLPI migration.

Backing Up Your Current GLPI Installation

Okay, you’ve prepped, you’ve planned, and now it’s time for the most critical step before you even think about moving a single file: backing up your current GLPI installation . Seriously, guys, I can’t stress this enough – a solid backup is your ultimate safety net . If anything, and I mean anything , goes wrong during the migration, this backup is what will save your bacon and get you back up and running. So, let’s get this done right. You need to back up two main components: the GLPI application files and the GLPI database.

First, let’s tackle the GLPI application files . These are all the files and folders that make up your GLPI installation. You’ll typically find them in a directory like /var/www/html/glpi or a similar path depending on your server configuration. The easiest way to back these up is to create a compressed archive. On a Linux system, you can use the tar command. Navigate to the parent directory of your GLPI installation (e.g., cd /var/www/html/ ) and then run a command like this: tar -czvf glpi_files_backup_$(date +%Y%m%d).tar.gz glpi/ . This command creates a gzipped tarball ( .tar.gz ) of your glpi directory, naming it with the current date for easy identification. Make sure you copy this backup file to a safe, external location – not on the server you’re about to decommission!

Now, for the GLPI database . This is where all your precious IT asset data, user information, tickets, and configurations are stored. The method for backing up your database depends on which database system you’re using (most commonly MySQL/MariaDB or PostgreSQL). For MySQL/MariaDB , you’ll use the mysqldump utility. Assuming your GLPI database is named glpidb and you have the database username glpi_user , the command would look something like this: mysqldump -u glpi_user -p glpidb > glpidb_backup_$(date +%Y%m%d).sql . You’ll be prompted for the database user’s password. For PostgreSQL , the command is slightly different, using pg_dump : pg_dump -U glpi_user glpidb > glpidb_backup_$(date +%Y%m%d).sql . Again, make sure you store this SQL dump file securely off-server. Crucially, after creating both backups, test them ! Try restoring a small part of the files or importing the SQL dump into a test database environment to ensure the data is intact and the files are not corrupted. This validation step is often overlooked but is absolutely vital. By successfully backing up and verifying both your GLPI files and database, you’ve significantly reduced the risk associated with your server migration.

Setting Up the New Server Environment

Alright, you’ve got your backups safely tucked away, and now it’s time to get the new server ready to receive your GLPI. This stage is all about setting up a pristine and compatible environment that mirrors your old setup, or ideally, improves upon it. Think of this as building the perfect new home for your GLPI data. We need to make sure all the necessary software and configurations are in place before we even think about importing anything.

First things first, let’s talk Operating System (OS) . If your old server was running Linux (like Ubuntu, CentOS, or Debian), it’s generally best to stick with a similar Linux distribution on the new server. This minimizes compatibility surprises. Install your chosen OS and ensure it’s up-to-date with the latest security patches. Then, you’ll need to install your web server . Apache and Nginx are the most common choices for GLPI. Make sure to install the appropriate modules your GLPI version requires. For instance, Apache might need mod_rewrite , mod_php , and mod_ssl . Next up is PHP . This is a big one, guys! GLPI has specific PHP version requirements, and these change with new GLPI releases. Check the official GLPI documentation for the exact PHP version and extensions needed for the version of GLPI you’re migrating. You’ll need to install PHP and all the required extensions. Common ones include php-mysql , php-gd , php-xml , php-mbstring , php-json , php-curl , and php-zip . Get these extensions right , or GLPI won’t function correctly, and you’ll be pulling your hair out trying to figure out why.

Now, for the database server . GLPI typically uses MySQL/MariaDB or PostgreSQL. Install your preferred database system. For MySQL/MariaDB, make sure you install mysql-server or mariadb-server . For PostgreSQL, install postgresql . After installation, it’s crucial to secure your database . This involves setting a strong root password, creating a dedicated user for GLPI with specific privileges, and configuring access controls. You’ll create a new database for GLPI (e.g., glpidb_new ) and grant the new GLPI user all necessary permissions on this database. Don’t skip database security! It’s vital for protecting your data. Finally, let’s consider firewall and network settings . Ensure your new server’s firewall (like ufw on Ubuntu or firewalld on CentOS) allows traffic on the ports your web server uses (typically port 80 for HTTP and 443 for HTTPS). If your database server is on a separate machine, ensure the necessary ports are open between the web server and the database server. Test connectivity between the web server and the database server from the web server itself. By meticulously setting up this new environment, you’re creating a stable foundation for your migrated GLPI instance. This careful planning ensures that when you import your data, everything will integrate seamlessly.

Migrating GLPI Files and Database

Alright, the new server is prepped and gleaming, and your backups are sitting tight. Now comes the moment of truth: transferring your GLPI files and database to the new environment . This is where all your preparation pays off. We’ll break this down into two main parts: restoring the application files and importing the database.

First, let’s restore the GLPI application files . You need to transfer the backup archive of your GLPI files (the .tar.gz file we created earlier) to your new server. You can use tools like scp (Secure Copy) or sftp for this. Once the backup file is on the new server, you need to extract it into the correct web server directory. For example, if your web server’s document root is /var/www/html/ , you would navigate to that directory and extract the archive: sudo tar -xzvf /path/to/your/glpi_files_backup.tar.gz -C /var/www/html/ . Make sure the extracted glpi directory has the correct ownership and permissions. Often, the web server user (like www-data on Debian/Ubuntu or apache on CentOS) needs to own these files. You can set ownership using sudo chown -R www-data:www-data /var/www/html/glpi (adjust www-data:www-data and the path as needed). Verify that all files are in place and accessible by the web server.

Next, we’ll import the GLPI database . You’ll need to create a new database on your new database server if you haven’t already done so during the setup phase. Let’s say you created a database named glpidb_new and a user glpi_user_new with appropriate privileges. Now, you need to import the SQL dump file ( .sql ) into this new database. Connect to your database server using the command-line client. For MySQL/MariaDB: mysql -u glpi_user_new -p glpidb_new < /path/to/your/glpidb_backup.sql . For PostgreSQL: psql -U glpi_user_new -d glpidb_new -f /path/to/your/glpidb_backup.sql . You’ll be prompted for the password for glpi_user_new . Ensure the import process completes without errors. Check the output for any warnings or failures. If you encounter issues, you might need to adjust database settings or troubleshoot specific SQL errors.

Once both the files and database are transferred and imported, you’ll need to update the GLPI configuration . Navigate to the config directory within your GLPI installation ( /var/www/html/glpi/config/ ). You’ll find a file named config.php.sample . You need to copy this to config.php and edit it to reflect your new database connection details (database name, user, password, and host). If you’re migrating to a new database server, this is especially crucial. Double-check all connection parameters in this file. After these steps, your GLPI data should be successfully moved to the new server. We’re almost there, guys!

Finalizing and Testing the Migration

We’re in the home stretch, folks! You’ve successfully transferred your GLPI files and database to the new server. Now, it’s time for the finalizing and rigorous testing phase to ensure everything is working just as it should. This is where we confirm that your GLPI instance is fully functional and ready for your users. Don’t skip this step; it’s absolutely critical for a successful migration!

First things first, access your GLPI instance via a web browser . Try navigating to your GLPI URL (e.g., http://your-new-server-ip/glpi or http://your-domain.com/glpi ). You should see the GLPI login page. Log in using your administrator credentials . Once logged in, take a deep breath and start exploring. Check if your assets are all there, if your tickets are visible, and if user accounts are intact. Perform a thorough sanity check . Browse through different sections: Assets, Tickets, Helpdesk, Administration, Reports. Look for any missing data, broken links, or error messages displayed anywhere on the interface. Test key functionalities . Create a new test ticket, assign it to a test user, and try to resolve it. Add a new test asset. Test notifications to see if emails are being sent out correctly. If you have any integrations with other systems (like LDAP, FusionInventory, etc.), test those integrations thoroughly . Ensure they are connecting and functioning as expected on the new server environment.

Review GLPI logs and web server logs . Check GLPI’s own logs (usually found in the files/logs/ directory) and your web server’s error logs (e.g., /var/log/apache2/error.log or /var/log/nginx/error.log ). Look for any errors or warnings that might indicate underlying issues. Check PHP error logs as well. If you encounter any problems, refer back to your documentation and the steps you took. You might need to adjust file permissions, update configuration files, or troubleshoot specific extension issues. Once you’re confident that everything is working correctly, update your DNS records to point your GLPI domain name (if applicable) to the new server’s IP address. Allow some time for DNS propagation, which can take anywhere from a few minutes to 48 hours, depending on your DNS provider and TTL settings. Inform your users that the migration is complete and that GLPI is back online. Provide them with the correct URL if it has changed. Monitor the system closely in the days following the migration for any unexpected issues. By performing these final checks and tests, you ensure a smooth transition and a fully operational GLPI instance on its new home. Congratulations, you’ve successfully migrated your GLPI!

Troubleshooting Common Migration Issues

Even with the best planning, sometimes things don’t go exactly as planned during a GLPI migration. Guys, it happens to the best of us! The key is to know how to troubleshoot common issues that might pop up. Being prepared for these little bumps in the road will save you a lot of headaches. Let’s look at some frequent culprits and how to fix them.

One of the most common problems is access denied or permission errors . This often happens after transferring files or setting up the database. If you can’t access GLPI or certain features are not working, it’s likely a file permission or ownership issue. Solution: Double-check that the web server user (e.g., www-data , apache ) has the correct read/write permissions for the GLPI files and directories, especially the files directory and its subdirectories. Use sudo chown -R www-data:www-data /var/www/html/glpi and sudo chmod -R 755 /var/www/html/glpi (adjust paths and user/group as necessary). For the files directory, you might need 775 or even 777 temporarily for specific operations, but be mindful of security. Database connection errors are another frequent showstopper. If GLPI can’t connect to the database, you won’t get far. Solution: Verify the database credentials (username, password, database name, host) in your GLPI config/config.php file. Ensure the database server is running and accessible from the web server. Check firewall rules if they are on different machines. Missing or broken features (like images not loading, buttons not working) often point to PHP extension issues. Solution: Consult the GLPI documentation for the required PHP extensions for your version. Use your package manager ( apt , yum , dnf ) to install any missing extensions (e.g., sudo apt install php-gd php-xml ). After installing or enabling extensions, restart your web server and PHP-FPM service (if applicable). Error messages related to specific GLPI modules can be tricky. Solution: Check the GLPI logs ( files/logs/ ) and your web server’s error logs for more detailed information. Sometimes, reinstalling a plugin or updating GLPI core files can resolve module-specific bugs. Slow performance after migration can be frustrating. Solution: Ensure your new server has adequate resources (CPU, RAM). Optimize your database by running OPTIMIZE TABLE on frequently used tables and checking database server settings. Ensure your web server is configured efficiently. Data integrity issues (missing tickets, corrupted assets) are the most severe. Solution: This is where your backup becomes invaluable. If data is corrupted, you might need to restore from an earlier backup and re-enter recent changes. Always ensure database imports complete without errors and test thoroughly before going live. Don’t panic! Take a deep breath, consult the logs, refer back to your documentation and this guide, and systematically work through the problem. Most issues are solvable with a bit of patience and logical deduction.