Old Dolibarr version: how to upgrade it in stages

The current stable version of Dolibarr is 24.0.2 and the project ships a major release every six months, so an install from 2021 is now about ten versions behind. To upgrade an old Dolibarr version, go in stages, one major version at a time and with a backup first; if the system is heavily modified, migrating to another system or a custom one is sometimes the better call.

At DCisGlobal we see this often in SMBs: someone installed the ERP years ago, it works and nobody dares to touch it. The problem is the server. Dolibarr 14, from July 2021, was tested up to PHP 7.4, and PHP 7.4 stopped receiving patches on November 28, 2022.

This guide explains the risk your company faces, how to upgrade without losing data and when it makes sense to switch systems.

Why an old Dolibarr version is a risk

Dolibarr is an open-source ERP/CRM backed by an active project, and that is good news. But its release model leaves little room for falling behind:

• There is no official long-term support (LTS) version. The project itself says so.
• Security fixes mostly go to recent branches.
• Its security policy only accepts reports for the last two stable major versions: today, 23 and 24.

In business terms: a version from three years ago is already outside what the project commits to reviewing.

The concrete risks for your company

Old PHP

PHP is the language Dolibarr is written in. Each version is tested against a PHP range, so an old version forces the server to stay on an unpatched PHP version.

On October 21, 2026, PHP fixed two critical flaws known as PHP2Shell, and versions 8.1 and earlier do not get that fix. In plain terms: through Dolibarr 18, the system has not been tested on any patched PHP version.

On top of that, the 8.2 branch only has security support until December 31, 2026. That is why the sensible target today is Dolibarr 22 or later. We cover this in more depth in PHP 8.1 end of life and PHP 7.4 end of life.

Modules and customizations

External modules (the ones that do not ship with Dolibarr) and custom changes are the most fragile part. The official documentation asks you to check that external modules are compatible with the new version before upgrading.

It is even worse if someone modified Dolibarr's own files: the upgrade overwrites old files with new ones, and those changes are lost without warning.

Integrations

E-invoicing, online stores, banks, external accounting. Each integration was written against a specific version of Dolibarr and its API.

When you jump several versions, what used to work can stop working without a visible error. And since invoicing requirements change often in both Spain and Argentina, a frozen system forces you to patch around it.

Dependence on whoever installed it

This is the least technical risk and the most common one. The vendor or employee who set up the system is gone, there is no documentation and nobody knows what was changed, where the backups are or which modules were purchased.

As long as nobody touches the system, this goes unnoticed. When it is time to upgrade, it becomes the first obstacle.

How to upgrade Dolibarr in stages

The official documentation is clear on three points worth following:

• Backup first. Database, documents folder, /custom folder and the conf.php configuration file.
• One major version at a time. The wizard repeats the upgrade version by version until it reaches the installed one, and on the command line the process is meant to run once per major version, in order.
• Skipping stages is a trap. According to the documentation, a direct jump from 22 to 24 applies the database structure changes but skips the intermediate version's data migrations, without showing any error.

That last point is the one that worries us most. A problem that gives no warning shows up weeks later, in a balance that does not add up or a report that does not match.

For example, going from Dolibarr 14 to 24 takes ten jumps. The work is done on a copy. PHP 7.4 falls within the range supported by every version from 12 to 24, so the chain can run on 7.4 in the staging environment, never in production, with PHP upgraded at the end.

This is the order we follow:

1. Full backup of the database, documents, /custom and conf.php, and a test that it can be restored.
2. Clone of the system in a staging environment.
3. Inventory of external modules and core changes, with their compatibility.
4. Jumps from one major version to the next, validating each one.
5. PHP moved to a supported version: 8.4 or 8.5 for Dolibarr 23 or 24.
6. Testing real processes: invoicing, collecting payments, moving inventory, running reports.
7. Repeating the process in production, with a rollback plan.

When to migrate to another system or a custom one

Upgrading is the default option when usage is reasonably standard: the project is still active and ships two major versions a year.

The honest comparison is not old versus new but what each path costs over three years. We ran the same analysis for another system common in SMBs: an old Vtiger version.

What to do now

1. Confirm the exact Dolibarr version and the server's PHP version.
2. Recover access to the server, the database and the admin panel, and find out who holds each one.
3. Take a full backup and check that it can be restored.
4. List external modules, your own changes and integrations.
5. Count how many version jumps remain to reach 24.
6. Use that map to decide (upgrade, migrate or build custom) and set a date.

If the server hosts other systems, our guide to upgrading PHP on unsupported systems helps sort out the rest.

How we solve it at DCisGlobal

We run a technology assessment of your Dolibarr: version, server, modules, core changes and integrations. From there we present the upgrade path, the risk of each jump and whether it is better to upgrade or migrate.

We run the upgrade in a staging environment, validate it with your team and only then touch production. Afterwards we continue with support and maintenance so the system does not fall years behind again.

See legacy system modernization · Ask on WhatsApp