Upgrading to Liferay Portal: How to Migrate a Major Version to the Higher One

6 mins read 1989 views

Upgrading to Liferay Portal: How to Migrate a Major Version to the Higher One article image

The wellbeing of business depends on timely upgrades. There can be made no so much conspicuous issues as critical improvements which lift up the process to the new level. Most often, business owners decide to add an essential piece of functionality and besides to upgrade for many reasons. Experienced CTOs and CIOs know that new functionality will match better with the new version, out-of-the-box features will be greatly improved, and security breaches fixed. So they make up their mind to migrate to a higher version.

What is a migration?

Before we start talking about the concern to which the article is devoted — migration from a major version to the higher one, let’s outline what migration is.

Migration is the code movement process from the outdated operating software to another operating software thought to be a worthier one when all critical settings and data are saved and enriched with new features. Critical settings are all third-party integrations, URL accessibility, sites and community settings, etc. Critical data thought to be user accounts, corresponding user data, pages, content, etc.

Why do you need to migrate?

There are two versions of Liferay Portal platform available for business: Enterprise Edition and Community Edition. Previously we have written about the difference between them and what version is perfect for your business.

First of all, we would like to list further the reasons that motivate to migrate to a higher version. So they are:

Upgrading new features (or adding new out-of-the-box).
Improving performance.
Resolving security problems.
Improving UI/UX experience.

Pre-migration stage

Before taking up the case, we provide a rough estimate for each of our client. To better understand the issues, we discover a client’s source code, database, document library, external integrations, etc. Having it done, potential work is quantified by the Team Lead or responsible Senior Liferay Platform Developer. Under the Liferay development circumstances, the rough estimate is counted, and after that, it is evaluated the number of major versions to be passed while migrating. As is often the case, the migration flows from A to D major version passing B and C. The point is that the more major versions (e.g., 6.0, 6.1, 6.2) between two are the more breaking changes and possible incompatibilities are expected to happen.

How we estimate Liferay migration

Estimation principles

Here we’d like to explain principles relating the issues of estimation on the example of a rough estimate for testing web pages of the Liferay portal.

Let’s assume that testing of one web page after migrating one major Liferay version takes 1 hour and fixing bugs further, if some issues are detected, takes 3 hours. We take as a result the arithmetic mean of the two determinations and multiply them by the available quantity of web pages. Now we have the average estimate of time for migrating all web pages in the portal. The same formula is applied to calculate time spent for migrating the rest components such as portlets, themes, layouts, ex-services, etc.

Image 1. Estimation principles for Liferay migration at Aimprosoft

We acquire our client with the estimate to give an understanding of the scope of work, the number of specialists, their level, and specialty enabled, terms of delivery for specified milestones. Usually, checkpoints are a demonstration of current progress, which is taken in average three times during the whole cycle of development, after that in average two weeks of UAT (User Acceptance testing) and it goes live.

The rough estimate serves for information purposes only giving a client an approximate cost of needed software.

Research and development

Before planning any migration or manipulations with a project, we must wonder if this project is going to be successful. We don’t commence the project till we check its feasibility. The migration should be technically possible, achievable within a budget, and profitable as a result.

There are four steps we walk through at each stage of research and development.

1. Database migration. When we have estimated and agreed on a detailed estimation with our client, our dedicated development team is ready to try a database migration. It happens that always everything goes as planned. During the process, some difficulties required manual help can appear, not always the migration process is underway automatically. Each large engineering platform like Liferay has an automated migration tool. But up to our experience, no one code movement process goes without any issues. This is a tiny deviation considered as normal in case of database migration.

2. Deployment. At this stage, we have upgraded components of the entire system to be used for a particular purpose. We move ahead with deployment trying to open all themes and portlets into a new Liferay portal. It is normal to make some code change during migration, e.g., API changes, framework changes, etc. For example, in case of Liferay 5.2 to 6.0 versions, the JavaScript Framework AUI (AlloyUI a Liferay in-house solution) was replaced by JQuery. Starting from Liferay 6.2 Bootstrap is used out of the box. And Liferay 7.0/DXP uses OSGi deployment model instead of web container application.

Image 2. Liferay 5 to 7 migration. Calendar

3. Release notes. It comes to the list of breaking changes for the higher version. All new features are listed chronologically. Fortunately, Liferay community cares about scrupulous described functionality for CE and EE versions of Liferay. It goes without saying that we study religiously all changes which will not work in the next version but worked in the previous one. That simplifies finding correct solutions to solve the issues. Types of changes could be about API and third-party incompatibilities, execution requirements, deprecations, removal, replacement or end of support for some functionality, and of course recommendations on how to use newly announced options.

4. Resolving issues. So armed with the document where the difference between versions is clear put down in writing and agreed with the client, we can embark on resolving the issues step by step. At this stage, we fix issues related to portlets, themes, web pages one by one and deploy the project on the server regularly. The frequency of milestone deployments is confirmed with each client individually.

Image 3. Liferay 5 to 7 migration. Document Library

But luckily research and development is not the end of the story. To let you get some air and ponder over the migration of your Liferay portal, we take a break expounding for now. Next time it is going to be covered a large body of explanations about testing and acceptance rules.

Mykola Systems Architect

Mykola’s professional software journey started with C++ and Java and has led him to the current destination as JavaScript and Scala specialist. Mykola's business acumen revealed in high school when he sold his first commercial project in the form of an exam preparation app. His technological arsenal encompasses knowledge in several scripting programming languages, but it was Scala that became his pure passion. Mykola’s genuine nature of a programming languages polyglot allowed him to grow to a highly-qualified Systems Architect who delivers software designs on numerous projects.

Julia Copywriter, PR manager

Julia is a confident master of the writing craft. She combines a unique experience across marketing and sales, which enables her to convey the message. Julia is extremely knowledgeable and open-minded, so she has an extensive skill set that includes conducting thoughtful and effective research and gathering valuable information. It enables Julia to grasp the entire business picture and create content brilliantly for the high-tech sector and B2B needs. Julia also delivers Aimprosoft's PR activities, managing cooperation with media and developing the company communications system.