Everything you need to know about upgrading to Pimcore X
In May 2021, Pimcore announced that version 10 of the platform (known as Pimcore X) is now available. Meanwhile, you are using an earlier version of the system. Does the upgrade mean that you must migrate to the new platform, too? How do you prepare for the upgrade to maintain business stability?
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 no longer maintained by the developers. 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 security risk.
If your system version uses outdated libraries and extensions, 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.
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 in the long run, it actually requires you to spend more money. Removing the accumulated tech debt that permeates the entire application will be more expensive 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 organisations 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.
The sooner you perform an 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.
3. If you decide to stay with the old version of the software, 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 extensions. 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) feature set.
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, customised code and tech debt, the more work and risk involved.
- If the project does not have documentation and automated testing, it’s possible for features to regress unnoticed.
- When migrating, there can be a loss of database integrity. 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 minimised.
- 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 old version from database backup.
Upgrading to Pimcore X can be done in three ways. Below we describe the advantages and disadvantages of each of them.
Upgrade on a production server
This means upgrading on the 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 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 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 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 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.
Read up on it