4.0 to 5.0 Migration

This document and the embedded linked documents outline the steps for migrating Broadleaf 4.0 to Broadleaf 5.0.

Some disclaimers:

We assume that your project is currently on the most recent 4.0 version of Broadleaf

We assume that you had previously followed all migration and upgrade notes for the latest release version of Broadleaf 4.0

We assume you are running on a Postgres, MySQL, Oracle or SQL Server database

The migration scripts (and related Liquibase changelogs) makes certain assumptions regarding the installed modules which may not apply to your implementation. Therefore some adjustments of the scripts may be required.

This is a migration to Braodleaf 5.0 and is considered a major release. Migrating is a project in itself and will require discovery, database and code updates, and extensive verification. While this guide outlines the key changes needed to migration to 5.0, there will be differences in every migration which may cause deviations from the provided steps.

Create new tables and columns

5.0 introduces several new tables and new columns on existing tables. This step creates those new entities. Liquibase Changelogs and db scripts are available depending on your setup.

Data Migration Scripts

Some tables have been changes and data moved to accomodate improved features. Data migration is currently only managed with db scripts (not Liquibase Changelogs). Given the variations in database syntax, some scripts have special callouts for the different database platforms. It is recommended that there are worked through carefully and executed in small, managed increments.

Manual Migration

The expression syntax for Rule Builders has changed in 5.0. There is not an automated expression syntax converter utility that migrates from the old syntax to the new syntax. These rules will need to be manually converted from within the admin. The approach is to edit each rule and rebuild it to the new expression syntax. The Match Rule Queries are made available to provide a means to export the existing expressions as a reference point prior to recreating. Additional data beyond the defined select columns may be required based on sandbox state, required reference points, or other needs. There are meant as a starting point.

Project Updates

Once the initial data setup is complete, the project itself can be migrated. The following sections require manual changes for the update process.

Update pom versions

Update your main pom.xml versions to the following 5.0 versions. Omit any modules that you are not currently using, unless otherwise specified. We've deprecated the REST endpoints in core and introduced a new REST Api module​​. This way, going forward, we can make releases to REST endpoints without requiring a core framework release. You will want to migrate existing endpoints to the new module.

Apply applicationContext changes

SOLR changes

Fix compilation issues

This section will take the most time, and will vary from project to project. The more customizations and extensions that you have, the more compilation issues you will need to address.

Remove any Broadleaf provided class named NullPayment*

Change calls of solrIndexService.rebuildAllIndexes() to solrIndexService.rebuildIndex()

Fix any startup issues

This should also take some time, but not as much as the previous task.

Verify and test

This is important to do before the final step. Perform full regressions tests across your project to make sure everything is functioning as expected.

Final table and column migration

The final script completes the data migration and handles dropping of columns, removing tables, creating primary keys/constraints, etc. Some of these operations are destructive and appropriate caution should be made.