Overview

Company database upgrades are supported all the way back from 1.4 directly to 1.9, using the 1.9 software. Company database upgrades from 1.3 and 1.2 are also supported, but due to the different nature of the upgrade process are called "migrations". The important difference being that when doing a migration, a copy of the data is being created in the 1.9 structure, while upgrades adjust the existing structure for 1.9. When upgrading from versions earlier than 1.8, please read the release notes and upgrade instructions and release notes of all the intermediate versions: these still apply but are not repeated here.

Before starting, please remember:

• Create a backup
• Don't do this when you're in a hurry
• When running into problems, check out the "Support" page

Technical upgrade

Upgrading the software works the same as with prior versions. Please refer to the procedure to upgrade a tarball installation for 1.7 for the 1.9 upgrade. Be sure to install the new and updated Perl module dependencies listed in the Changelog. Also note that the Docker image definition contains a comprehensive list of Debian Buster package dependencies.

Especially note that the minimum versions for Perl and PostgreSQL have been updated. The minimum required Perl version is now 5.24 and the minimum required PostgreSQL version is now 10. (If you run Docker images, the Perl dependency is taken care of for you. The PostgreSQL dependency needs your attention.)

Prior versions of LedgerSMB run fine against PostgreSQL, so there is no reason to combine the 1.9 upgrade with the upgrade of PostgreSQL: you could upgrade to PostgreSQL 10+ before upgrading LedgerSMB to 1.9.

Docker Compose upgrade

The docker compose infrastructure for all versions prior to 1.9 all used PostgreSQL 9.6. Since 1.9 requires at least PostgreSQL 10, the docker compose infrastructure has been upgraded to use PostgreSQL 12. Unfortunately, the docker container does not upgrade the database itself -- meaning you'll need to export your PostgreSQL databases using pg_dumpall and restore it into the new database using psql as per the example.

(More comprehensive upgrade instructions are solicited; i.e. "help wanted".)

Company database upgrade

Technically, this process hasn't changed since 1.7 and the instructions for 1.7 still apply.

Each new LedgerSMB release has tightened the checks on validity of the data stored in the database. 1.9 continues on that path and adds yet more checks - this helps us find bugs and prevents undesirable data entering into the ledger. During the upgrade, existing data is checked against these new quality criteria and optionally offered for correction (or deletion, depending on the type of inconsistency).

Before you begin

• Verify that all Reconciliation Reports have been either approved or deleted
  If you forget this step, the migration will offer to delete it for you; approval isn't supported during migration. Note that this does not refer to transactions; unapproved transactions can safely exist during upgrade.
• Create a backup
• Tell users not to use your system during upgrade

After the upgrade

<No known items at the moment>