Everything you need to know about upgrading to Pimcore X

In this article, you will learn:

• Why is it even worth upgrading an application to Pimcore X?
• What are the risks associated with such a change?
• What stages does the migration process consist of?
• How can you, as a customer, prepare for such a process?

Three reasons to upgrade your Pimcore system to version X

If you're running Pimcore version 5, upgrading is a must. This edition is not supported anymore. Security updates to fix newly discovered vulnerabilities are no longer being prepared for Pimcore editions 5 and 6. If you’re using this version of the software, you can upgrade to a paid LTS (Long-Term Support) version. Note, however, that this requires a paid subscription.

Below are the most important arguments in favour of upgrading to Pimcore X.

1. Outdated software is a huge security risk.

If your system version uses outdated libraries and extensions, a simple error is just a tiny issue. It could mean security vulnerabilities. This is the case, for example, in the aforementioned version 5, for which updates were discontinued on 9.12.2019, and version 6, for which they were discontinued on 23.06.2021.
If you are using an older release of the system, you also have to consider that it may be running a version of PHP without security updates. The latest version of the software is usually the safest.

2. By holding off on upgrading, you are increasing your technical debt.

This can mean a situation where you take the seemingly cheaper option of not investing in upgrading your system, but eventually, it actually requires you to spend much more money. Removing the accumulated tech debt that permeates the entire application will be pricier than countering it on an ongoing basis. You may find that the time spent on updating to the latest version could have been spent on an upgrade.

From the perspective of the team employed in a company, programmers are usually more willing to apply to organizations implementing projects that they find attractively challenging. They look more favourably on technological novelties than on legacy code. Lack of technical documentation for outdated software versions or upgrade paths is also an additional reason to upgrade. Working with not supported software is nothing but a pain for them. If you somehow manage to convince them to work with old Pimcore, it won't be cheap.

The sooner you perform a Pimcore upgrade, the lower the costs and the less work required to perform it. Otherwise, you have to deal with a decrease in software performance and an increased risk of errors. And developers quitting.

3. If you decide to stay with the old version of the Pimcore, you are blocking new possibilities.

You won't be able to take advantage of feature updates or brand-new developments from Pimcore, for instance because you’ll be unable to install new features. This means that even though you originally opted for a flexible and powerful solution, by sticking with an older version, you are locking yourself into a limited (and, as we've already mentioned, increasingly insecure) default feature set. It's possible to manage it manually until some point... but what for? Again, of course, it will cost you more than an update.
You already know why it's worth upgrading your Pimcore system. There are, of course, challenges involved. But you can prepare for them, manage them in advance and, as a result, avoid potential risks.

 

What risks should I anticipate when upgrading?

• You should be aware that a migration that involves going through several versions is more difficult than through just a single version. For example, moving from Pimcore 5 to 6, then from Pimcore 6 to Pimcore X. Here, a lot also depends on the migration variant (3 possible variants are described below).
• The difficulty of the upgrade will be proportional to the complexity of the project. The more extensions, customized code, special system settings, and - what's most important - the tech debt, the more work, and risk are involved.
• If the project does not have documentation and automated testing, it’s possible for features to regress unnoticed. You may need to start with default values.
• When migrating, there can be a loss of database integrity. Data objects may not be merged anymore. This is a huge business risk, especially considering the purpose of Pimcore implementation in your business. However, if backups are maintained and robust testing is carried out, this risk is minimized.

There may also be issues arising from changes to Pimcore itself.

Firstly, the Pimcore extensions you have may no longer be updated. In this case, we have 3 choices: we try to update these extensions yourself, give up on them, or postpone the upgrade until the authors of the extensions release an update.

Secondly, the code written for the previous versions of Pimcore may become obsolete due to the upgrade. In such a situation, refactoring (i.e. restructuring the existing code) is needed.

It’s also worth considering that the upgrade path provided by Pimcore is not perfect, and you’ll have to fine-tune the upgrade yourself. Here again, our specialists can help you.
 

How does the migration process work?

The details depend on which upgrade option you opt for (the three possible ones are described further on). However, as a rule, the basic steps are:

1. Downtime, which means shutting down the production server. This is done so that no data from new user activities is lost.
2. Coordination of the upgrade with infrastructure administrators, e.g.: switching PHP versions, monitoring server resources and creating a database backup.
3. Creating backup copies of data and files (called assets).
4. Optionally: running a parallel infrastructure with different software versions, e.g. different versions of PHP and Elasticsearch (a dual infrastructure gives you the possibility to revert to the previous version if the upgrade fails).
5. Process verification, testing, and patches.
6. In case of failure: restore the old version from the database backup.
    

Pimcore X upgrade options

Upgrading to Pimcore X can be done in three ways. Below, we describe the advantages and disadvantages of each of them.

Upgrade to a production server

This means upgrading on the web server where your platform is hosted. It is like working on a ‘living organism’.
The advantage, in this case, is the in-place upgrade (the existing code and data structure are directly updated). For you, it means lower costs for additional infrastructure needed in the case of an upgrade – you simply don't need it here.

However, this method carries the risk of losing data integrity. You also have to be ready for a longer downtime (the time when the application is switched off and users are unable to access it).
Good practices here will be to make backups and to test carefully and repeatedly, preferably on the most production-like environment possible (staging).

This option requires synchronous work with administrators.

Local database upgrade and import of the effect to production

This means that the upgrade is performed outside the production environment and then transferred to the target (production) server.

This option gives better security of the update: the risk of an error or damage to the database is minimal because the process can be repeated.

In this case, however, the downtime of the application is longer (‘production’ must be shut down for the duration of the update work). If there are differences between the production and local environments, the tests will be slightly less reliable.
This option does not require much involvement on the part of site administrators.

Exporting data from the old version of Pimcore to the new version

In this case, the update is done by transferring data from one system to another using files.
The application can be updated directly from the current version to the latest supported version (e.g. from version 5 to 10), rather than incrementally.

This is a good option for small and simple projects but is not suitable for larger projects (where exporting and importing objects would be too laborious).
 

Instead of a conclusion: how can you prepare for an update?

• Plan a budget commensurate with how complex your application is and from which version the upgrade will be performed. You may be wondering where to get such knowledge in the first place. Remember, we're here to help you make estimates during the preparation stage for the upgrade.
• Be ready with acceptance testing on your side. Secure time with the relevant people in your team (e.g. content managers) so that the testing doesn't interfere with their daily duties.
• Prepare the testing environments. Preferably, one for ongoing work and another for upgrades. Remember that upgrading is a long-term process and that the work is usually conducted in parallel on the old and new versions of the system.