Upgrade readiness check

You choose the target version, from the next major version up to 24.0, and the PHP version planned after the upgrade. You click Run the check. The module reads your installation without changing anything and gives you a report.

The code of your external modules

This is the main part of the module. The code of every external module is read file by file, without being run, and compared with the changes of every version on the path, not only the target version:

• removed core functions, classes, methods, properties, constants and files;
• overridden methods that became incompatible with Dolibarr’s;
• calls with fewer arguments than Dolibarr now requires;
• removed columns and tables in the module’s SQL queries;
• hooks and trigger events that are no longer called;
• functions, constants and syntax refused by the planned PHP.

Each finding gives the file, the line, the version where it breaks, a degree of certainty and, when known, the replacement. Each module gets a coverage rate: the share of calls actually verified. Encrypted code (ionCube, SourceGuardian, Zend Guard) is reported as impossible to verify.

The nine other families of checks

The report

It starts with a one-line answer — ready, almost ready or not ready yet — then the highest version you can reach without changing anything, the path step by step and the plan in order. It also tells you whether the installed and target versions still receive security fixes, what to back up and which step rewrites the most data.

Each finding has a level — no problem, to check, blocking or cannot be verified — with what to do and the source of the rule.

The report can be downloaded as HTML or Markdown. The anonymise option hides the domain, the paths, the company name and the user’s login. For each module at fault, the Report for the publisher button produces a file to send to them: files, lines, known fix, nothing about your company or your server.

What the report cannot guarantee

The report says so itself, at the bottom of the page: it reduces known risks, it does not guarantee that the upgrade will succeed. It does not prove that an external module will work — only a test on a copy can —, does not foresee bugs in the target version or how the migration scripts will handle your data, and does not check that a backup can be restored.

The code analysis is time-limited: 60 seconds in total, 30 seconds at most per module. Files over 2 MB and the vendor, node_modules and includes folders of modules are not read, and the report says so. Target versions stop at 24.0: the module’s reference data is up to date as of 25 September 2026.

The tool is under HomeAdmin ToolsUpgrade readiness check. The screenshots below were taken with the French interface.

The report for a test instance on 18.0.9 aiming for 24.0: “Pas encore prêt : 1 action(s) avant de monter” (Not ready yet: 1 action(s) before upgrading). The fictitious module DemoFutur breaks from 20.0, so you can go up to 19.0.4 without changing anything. Below: the security line — 18.0 no longer receives fixes —, the path from 18.0 to 24.0 and the plan: get a compatible version from the publisher, then move to 18.0.10 and go up one step at a time.

The starting screen: the target version, 24.0 (24.0.1), the PHP planned after the upgrade, and the “Intégrité des fichiers du cœur” box (Integrity of core files).

The “Vos modules” block (Your modules). For DemoFutur, a class removed in 20.0 and a function removed in 23.0, with the file, the line and the replacement, “code analysé à 100 % (2 appels vérifiés sur 2)” (code analysed at 100 %, 2 calls verified out of 2) and the “Rapport pour l’éditeur” button (Report for the publisher). DemoCasse, disabled and incompatible, should be deleted.

• Administrators only. The menu and every page check that the user is a Dolibarr administrator; any other user gets “Access denied”. The module has no dedicated permission.
• Read-only. The check writes nothing, neither to the database nor to disk. During testing, a full fingerprint of the database and the files was taken before and after a check: it was identical.
• Anti-CSRF token on every action: check, downloads, report for the publisher.
• No secret displayed or exported. For conf.php, the module only says whether a key is present, never its value.
• No command run. Repairs, such as harmonising the encoding of tables, are given, never executed.
• Only one possible connection. The “Integrity of core files” box is ticked by default only when the official signature of your version is already in install/: the comparison then needs no network. Otherwise it stays unticked, and ticking it is what allows the signature to be downloaded from dolibarr.org. With the box unticked, the module connects to nothing.

• The dolixmaj folder, in readable source, under the GPL v3 or later licence: the tool page, an “About” page with no setting, the check and code-analysis classes, and the Dolibarr 16.0 to 24.0.2 reference data (data/).
• The translations present in langs/: French (fr_FR), English (en_US) and German (de_DE).
• A README.md and a ChangeLog.md.
• Dolibarr 16.0 minimum, PHP 7.0 minimum, MySQL/MariaDB and PostgreSQL. Installed and run on 16.0.5, 17.0.4, 18.0.9, 18.0.10, 19.0.4, 20.0.4, 21.0.4, 22.0.5, 23.0.4, 24.0.0, 24.0.1 and 24.0.2.

• No table is created, no setting is stored. Only enabling the module records, as for any module, its status and its menu.
• Nothing is kept on the server: the report is computed on each request, downloads are generated on the fly.
• Downloaded reports stay on your computer. Anonymised, they contain neither the domain, nor the paths, nor the company name, nor the user’s login.
• When the module is disabled, the menu disappears. There is nothing to clean up in the database.