Database Schema Changes
Historically, performing a major- or minor-version migration in uPortal required a complete database re-initialization. In other words, the only supported way to have a portal database for your chosen minor release (e.g. 3.1, 3.2, or 4.0) was to run
Migrating from uPortal 3.x to uPortal 4.1 certainly requires database re-initialization. Migrating from uPortal 4.0 to uPortal 4.1 officially requires it, but you may succeed in running uPortal 4.1 against a database that was functioning properly with a late uPortal 4.0.x release (e.g. 4.0.12).
Even if you could run uPortal 4.1 against your existing portal database, it may be a good idea to perform a full migration anyway. Each new major- and minor-version of uPortal brigs exciting new features. More often than not, these features are implemented with data. In addition to the data changes driven by new features you want, there are often data changes driven by old data that you don't need any longer. When you're making a substantial portal update, it's often very pragmatic to choose a fresh start with portal data. uPortal 4.1, moreover, contains some pretty significant updates, including Respondr and Regions for portlets.
Use $ant data-export to get data from your existing portal, then selectively include elements of that data in the new, 4.1 portal.
uPortal 4.1 introduced an optional feature Entity-based PAGS which has new database tables. The default in uPortal 4.1 is XML-based PAGS. Multi-tenancy requires Entity-based PAGS. Refer to the Entity PAGS section below and the Person Attribute Group Store (PAGS) Overview documentation for more information.
Migrating from 3.x or 4.0.x to uPortal 4.2 generally requires an initdb as uPortal 4.2 does not support the universality theme anymore in favor of Respondr. Though you could retain most data and make layout adjustments to get your portal to look reasonable in Respondr without wiping out other data, switching the theme to Respondr is generally sufficient reason to take the opportunity to reboot your portal look and discard old data.
There are no additional tables between 4.1 and 4.2.
Topics for uPortal 4.1 Migration
Below are some data migration notes of particular relevance to uPortal 4.1.
As of uPortal 4.0,
Starting with uPortal 4.1, Person Attributes Group Store (PAGS) comes in 2 flavors: original (configured in PAGSGroupStoreConfig.xml) and Entity (JPA-managed database entities). Both approaches are functional and behave similarly. Consider switching to Entity PAGS now; in the future, Entity PAGS will allow uPortal to support management of PAGS groups through an administrative UI, without a re-build, re-deploy, and re-start of Tomcat.
Topics for uPortal 4.2 Migration
Below are some data migration notes of particular relevance to uPortal 4.2. If upgrading from a version earlier than 4.1, also see Topics for uPortal 4.1 Migration above.
Entity-based PAGS becomes the default configuration in uPortal 4.2.0. There is a new groovy-based script that can also be invoked from ant that converts an existing XML PAGS file to entity files and creates a SQL updae script that can be executed to upgrade a uPortal 4.1 database from XML PAGS to Entity PAGS. See - UP-4436Getting issue details... STATUS for more information.