Migration to Liferay DXP


The activity of this company focuses on the design, manufacture, installation, maintenance and modernization of elevators, escalators, ramps and corridors. It is made up of more than 30 companies in Spain, Portugal, France, the United Kingdom, Ireland, Belgium, the Netherlands, Luxembourg, Norway, Brazil and Poland.

As a partner specialized in developments under Liferay technologies, ZYLK led the migration of the company's Extranet portal from the Liferay 7.0. version to Liferay DXP. This multi-site, multi-site and multi-language portal, with content in Spanish, English, French, German and Dutch, hosts 4 instances formed by multiple sites. Each instance has a specific orientation:

• An instance oriented to be the communication environment with the client.

• An instance dedicated to the innovation network of the company.

• An instance dedicated to hosting applications and functionalities for the company's group's staff.

• An instance dedicated to the exchange of information with suppliers.

Initially, those project tasks that could be blocking and / or that caused uncertainty in the project were identified. Three key tasks appeared:

• The need for the teams that carry out developments in the company to be able to keep doing so without having to depend on the progress of the project.

• Given that the company's Portal used sharding in version 6.2, the challenge was to offer a solution that would unify the 4 shards in a single shard. The sharding of the database is a singularity not supported in Liferay DXP 7.0

• Identify those developments that can continue to function through the compatibility layer offered by Liferay DXP and those that need to be migrated to OSGi modules.

The migration project for the company's portal needed a multidisciplinary team with expertise in systems and Liferay Portal development. The manufacturer's support in the process of database sharding migration was essential in the success of the project.

Salek Saleh Deihan


A parallel development infrastructure was deployed to avoid interrupting and / or blocking the different teams that are responsible for evolving the developments of the Extranet. The infrastructure is based on free software projects such as SVN, Maven, Gradle and Jenkins. One of the challenges of the project, and in any product upgrade, is how to organize existing projects and development companies while continuing its Liferay 6.2 life cycle.

Given that Liferay DXP 7.0 does not support sharding in the database, a pre-process of the upgrade was drawn, together with the Liferay Support team, in order to adapt the Liferay Portal 6.2 with sharding to a Liferay Portal 6.2 without sharding ( with a single shard). This pre-process consisted of three phases:

• A first phase that consisted of the unification of shards through generic scripts and independent of the environment where they were launched. That way it was possible to merge all the tables of the 4 shards.

• A second phase that consisted in raising the Liferay Portal 6.2 pointing to the new database with a single shard.

• A third phase that consisted in validating together with the users that no data was lost during the first phase.

Once the pre-upgrade process to unify the shards in one was passed, the procedure was drawn up to migrate the three environments (development, preproduction and production) to Liferay DXP 7.0 through the upgrade process defined by Liferay.

To train the Liferay DXP core upgrade procedure, production data were used in all three environments. In total, the upgrade process of the core was executed four times:

• In the development environment.

• In the preproduction environment.

• In the production environment. This iteration was aimed at training the production machine and anticipating potential problems with the machine or connectivity to external services.

• The second and final iteration in the production environment.

The stack used is certified by Liferay, and uses Red Hat as the operating system, Jboss as an application server, Elastic Search as an indexing and search engine, and Oracle as a relational database.

The strategy for the migration of the developments was to identify which developments could continue to work in compatibility mode and which developments, due to their idiosyncrasy, should be migrated to OSGi modules (themes and projects of type service builder). Compatibility mode allows you to maintain the same project structure without having to migrate the portlet to OSGi by changing the references to the new Liferay APIs.

The subjects had to be updated to Gradle through the use of Yeoman, which are part of the Liferay recommendations. CSS styles were affected by changes in the structure of the page in DXP version. The use of the Bootstrap 3 libraries as well as the Automatic Single Page (SPA) in Liferay DXP also required some adaptations.

The use of OSGI modules in the portlets also required certain changes, for example, when making a configurable portlet in Liferay DXP. The adoption of an OSGI architecture incorporates many advantages to the product, but it will require numerous changes in those upgrade projects between versions 6.2 and 7.x, which have many customized and developed components.

The production was carried out smoothly, controlled and without setbacks, under strict revision and validation work, with a portal under Liferay DXP equivalent in terms of functionality and appearance. Due to the changes introduced in the product architecture in the DXP version, to a modularized OSGI architecture, this was a considerable challenge.

Currently, in the company's Extranet portal, there are several websites with several developments (among themes, portlets and extensions of Liferay there are around 30 projects) developed with different frameworks such as (MVC, Service Builder, Spring MVC ...) as well as different task automation tools (Maven and Gradle).

Tell us about your project