Skip to main content

Legacy ADempiere and early iDempiere migration scripts

note

The folders referenced below can vary from release to release. The idea is to apply all migration scripts in order, until you arrive at the release you're migrating to.

From iDempiere 2.1 to iDempiere 3.1​

Apply migration scripts from the following three folders, in order:

From iDempiere 2.0 to iDempiere 2.1​

Apply migration scripts from the following three folders, in order:

From iDempiere 1.0 to iDempiere 2.0​

Apply migration scripts from the following three folders, in order:

note

These Bitbucket links point to the historic ADempiere-era repository and may no longer resolve.

From ADempiere 360 to ADempiere 361​

Apply migration scripts from the following folders, in order:

From ADempiere 360 to iDempiere 1.0​

Apply migration scripts from the following folders, in order:

From ADempiere 361 to iDempiere 1.0​

Apply the same migration scripts as migrating from 360, excluding those already applied when you migrated from 360 to 361.

Increasing speed of some scripts​

  • The script postgresql/789_GenerateUUIDColumns.sql can apply ALTER TABLE too slowly for big tables. This can be improved by dropping the DEFAULT NULL at the end of each ALTER TABLE.

  • It is highly recommended to run the "UUID Generator" process after migration to fill empty UUID columns, but this can be very slow for big tables. A faster way is to execute an update directly on the database. You can also consider deleting the related UUID index before the update and recreating it at the end, for example:

    DROP INDEX ad_changelog_uu_idx;
    UPDATE AD_ChangeLog SET AD_ChangeLog_UU=generate_uuid() WHERE AD_ChangeLog_UU IS NULL;
    CREATE UNIQUE INDEX ad_changelog_uu_idx ON ad_changelog (ad_changelog_uu);

  • The script processes_post_migration/postgresql/02_SynchronizeTerminology.sql tends to be slow on PostgreSQL versions higher than 9.1 with default memory settings. Tune the database memory to resolve this.

Note about migrating from ADempiere 370​

Experience and documentation about this migration path is shared by Pb_integratio on the "Migration from ADempiere 370 to iDempiere" wiki page.

Note about migrating from ADempiere pre-360​

Problem​

Migrating some ADempiere installations before 360 to iDempiere generates a problem when using PostgreSQL 9.2: applying the script 201309192024_IDEMPIERE-1370.sql throws:

ERROR:  cannot change name of input parameter "p_product_id"

Cause​

An issue has been detected migrating a database pre-360 to iDempiere using PostgreSQL 9.2.

The bomqtyonhand function from the database seed does not match the bomqtyonhand function present in the migration scripts for pre-360. The script 201309192024_IDEMPIERE-1370.sql fixes that situation, but PostgreSQL 9.2 does not allow changing a function's parameter name.

Solutions​

tip

You can perform the migration using PostgreSQL 8.4, which allows changing a function parameter's name, and migrate to 9.2 at the end.

Alternatively, you can drop the old bomqtyonhand function (and all its associated views) and recreate them properly.