If you’re reading this blog, then you are either planning a Liferay DXP 7.2 upgrade or considering one. You may be running a version of Liferay that’s reached its end of life or desire the new features/enhancements in Liferay DXP 7.2. If you’re on the fence, here are a couple of other blogs on Liferay DXP 7.2 features and why you should upgrade.
Top 10 New Features in Liferay 7.2
Now back to the primary goal of this blog. You’ve decided to upgrade to Liferay DXP 7.2! Congratulations! That’s the first big hurdle. Now you just need to plan your upgrade.
Liferay DXP Upgrade Planning Overview
A successful Liferay DXP Upgrade starts with proper planning that covers a broad range of topics including –
- Existing Liferay implementation review
- Current pain points
- New and changed requirements
- Reviewing Liferay version-specific topics (related to the Liferay version that you are upgrading to and any versions that you are skipping) and determining which new Liferay features you will leverage in the course of the upgrade
- Planning your Liferay data upgrade
- Planning your Liferay code upgrade
- Planning your Liferay environments upgrade/migration
- Technical constraints review
- Security review
- Resource and development process review/planning
General Considerations When Upgrading Liferay
- Do you have any hard deadlines? Is your current version close or past its end of life? Do you have any market-driven deadlines for your business such as harvest-time (fall) for an agriculture harvesting company or Christmas time for a popular video game manufacturer?
- What Liferay version are you upgrading from?
- There is a direct code upgrade from Liferay 6.2+ to Liferay DXP 7.2
- For database (data) upgrades, there’s more work for jumping multiple versions (ex: 6.2 -> 7.0 -> 7.1 -> 7.2). A little more time should be planned here.
- Do you have any older “war” modules that need to be upgraded to OSGi modules
- You made it through the upgrade to 6.2 without converting to OSGi modules, eh? Well, it needs to happen now. But don’t fear, it’s not hard if you have the right team assembled and make the correct decisions in this migration. Here are a few common pitfalls we’ve seen when converting older Liferay portlets to OSGi modules.
- Naming conventions need to be defined correctly. Collisions in the OSGi container can be hard to debug.
- Define a clear package structure. It’s important to have a separate package structure for each module. The OSGi container can easily share code between modules but needs a well-defined package structure for each module.
- Clearly define your package exports and package imports. Once you’ve cleaned up the package structure for each module, you can decide what packages should be exported and imported.
- Only export what another module can consume or extend.
- Do not export the same package from multiple bundles.
- Stop bundling JAR files into each module. You can leverage the OSGi container for sharing common features & functionality. Common JARs should be added to the OSGi container as a shared module and used by multiple OSGi bundles.
- For example, when building your new OSGi modules you should have a long “compileOnly” list of dependencies and a very small list of “compile” dependencies.
- You made it through the upgrade to 6.2 without converting to OSGi modules, eh? Well, it needs to happen now. But don’t fear, it’s not hard if you have the right team assembled and make the correct decisions in this migration. Here are a few common pitfalls we’ve seen when converting older Liferay portlets to OSGi modules.
- What does your build environment look like? Have you automated it yet? How about Infrastructure as code? It’s a great time to fix these technical debt issues during an upgrade.
- How many environments do you currently have (dev, qa, pre-prod, prod)? How many are needed? Perhaps now is a great time to talk about a container or cloud deployment? Here is a great blog on Demystifying Docker and Kubernetes if you are considering containers.
- How is the digital experience for your customers? Perhaps it’s a good time to redesign your site? Do you want to plan a redesign as part of your upgrade? Perhaps port the site over as-is and plan a redesign later? If a redesign has been on your mind, check out this blog on a Frictionless Enterprise: Five Enablers To Improve Operations And Digital Experience.
- Another similar question to a site redesign is an architecture redesign. There have been many advances in modern web applications. Perhaps now is the time to move to a SPA framework with React/Angular/Vue/etc?. Are you ready for a mobile-first strategy?
- Here’s a great case study from one of our clients: SPIRE: Providing Modern Customer Experiences
- It’s also important to note that a Liferay upgrade will surely require a JDK upgrade. We just need to account for that in our plans.
Liferay Specific Considerations
- All of your portlets will need to be upgraded. Here are a few checklist questions to support your portlet upgrading plans.
- How many portlet apps do you have? How many portlets are in those modules? Are they simple or complex portlets?
- What kind of portlets are we dealing with? Are you still using Liferay MVC or Spring MVC portlets? If so, perhaps we jump back up to the previous section and talk about an architecture redesign?
- Do you still have an EXT environment? If you’re coming from DXP 7.0 or 7.1, you may not even know what I’m talking about. If that’s the case, then congratulations! Yay! If not, then we’ll need to do some more planning. This may be the hardest part of your upgrade but it’s not unsurmountable. Having the right partner makes a big difference.
- The EXT plugin was deprecated in newer versions of Liferay. We’ll need to analyze your EXT plugin and prepare for this part of the upgrade. In many cases, we’ve found that old Liferay customizations in your EXT plugins are no longer necessary in the upgraded Liferay.
- Most of the time it’s simpler to rebuild a theme rather than upgrade it. We can also use this time to fix any technical debt. How many themes do you have? Can we consolidate them and use color schemes?
- Is your theme already developed in Freemarker? That makes things simpler since Liferay no longer supports velocity themes OOTB.
- How many hooks have you developed? What kind of hooks are you currently leveraging? Are they JSP hooks? Model listeners? Pre/Post actions?
- Upgrading hooks generally isn’t too difficult but we’ll need to build a catalog of the hooks and decide what needs to be upgraded and what doesn’t. It’s a common pitfall to assume all hooks need to be upgraded. In many cases, I’ve seen customers develop a hook to get around a scenario that’s no longer valid in the current version of Liferay.
- For JSP hooks and fragment bundles, it’s important to use a version range for the host fragment bundle version.
- Do you leverage any common internal libraries? Are they already deployed as OSGi modules?
- What other common industry libraries are leveraged? I’m referring to libraries like React, Angular, Spring, Hibernate, etc. We’ll need to plan an upgrade for these libraries also.
- What build tools are you leveraging? Are you already using gradle? How about Gulp? We’ll likely be upgrading your build tools as part of this initiative.
- We’ll need to plan a deep analysis of your portal-ext properties. This isn’t a big effort but in many cases, we find optimizations that can be made for performance and scalability.
- Are there any Marketplace Apps we need to upgrade also?
Liferay Site & Content Considerations
When planning your content upgrade, here’s a few questions that help provide a high-level estimate on the time required for both the upgrade and regression testing. This is perhaps the simplest part of our upgrade. Liferay does a great job upgrading your content. However, it might also be a good time to perform a content review and clean up any stale/old content.
- How many sites are utilized within Liferay?
- Approximately how many pages are in the site(s)?
- Approximately how many users are on the site?
- Approximately how many web content articles are in the site(s)?
- Any current content/site publishing workflow?
- Do you have any custom Liferay patches applied?
- Is the current site responsive?
Infrastructure Considerations
- What app server are you currently using (Tomcat, JBoss, etc)? If it’s not Tomcat, would you be averse to moving to Tomcat? This is not a requirement but can simplify things. The vast majority of Liferay environments are running on Tomcat. Therefore, it stands to reason that any container-specific issues would have been likely found and already resolved. This is something to consider if you have some flexibility.
- Are there any existing applications integrated with the Portal? How are those applications integrated?
- What is your current user repository? Is it the Liferay DB? LDAP/AD?
- How do users authenticate to Portal (simple username/pwd login or something more robust like 2-factor authentication)?
- Is there an SSO infrastructure in place or required as part of this upgrade?
Liferay DXP Upgrade Planning Summary
Upgrading Liferay doesn’t have to be difficult but does require careful planning. This is not an exhaustive list of items to review (in fact, it is a subset of the checklist we use at XTIVIA while planning a customer Liferay DXP upgrade) and every DXP solution has its own unique challenges. However, this list should give you a good start on planning your Liferay DXP 7.2 upgrade.
If you have questions on how you can best plan your Liferay DXP Upgrade and / or need help with your Liferay DXP implementation, please engage with us via comments on this blog post, or reach out to us at https://www.xtivia.com/contact/.
Additional Reading
You can also continue to explore Liferay DXP by checking out The Top 10 New Features in Liferay DXP 7.2, Top 5 Reasons to Choose Liferay DXP, Migrating To Liferay DXP, and at our website.