Know the state of your Liferay before deciding what to do with it.
Who it is for
For companies and public bodies that inherit a Liferay portal, are about to change supplier, have a migration to decide on, or want to know what they have been handed before signing it off.
The problem
You have inherited a portal and do not know what state it is in. Or the supplier says it has to be rebuilt from scratch and you have no way to check. It is slow, it does not show up on Google, and nobody can tell you whether the problem is the code, the server or the version.
How we solve it
We review the portal inside and out and tell you how it stands, plainly. What works, what is a risk and what should be fixed first.
What it includes
Version and support
Which version you run, whether it gets patches and what upgrade path exists.
Custom code
What is there, how it is built, what is used and what complicates the next upgrade.
Performance
Web server, caches, database and search. Where the time goes.
Security
Dependencies with known vulnerabilities, configuration, permissions and forgotten credentials.
Accessibility and search ranking
State against the EN 301 549 standard, indexing, internal linking and structured data.
Prioritized report
The risks in order, what we would do first and a fixed-scope proposal.
How we work
We agree the scope. You give us read access to the code, the configuration and an environment of the portal. We work without touching production. You get the report and we go through it with you, in the order things should be fixed. Then you decide: we fix it, your team fixes it or you hand it to your supplier.
What we measure
Findings by severity, version in use against the latest supported one, load times, indexable pages and the result of the accessibility analysis.
How it is built
The code goes through static analysis in SonarQube, with our own rules for Liferay, and through scanners for dependencies, configuration and credentials in the history. What they find are leads: each one is checked before it reaches the report.
Custom code is reviewed against the model Liferay DXP recommends: what stays as a module, what could be a React client extension and which Service Builder entities could be Liferay Objects. When the question is a migration, we simulate the upgrade in a separate environment to anticipate the problems.
Performance is measured in the web server configuration, Liferay's caches, database queries and Elasticsearch indexes. Search ranking, with the portal's own crawl and indexing data.
Accessibility is analysed with the official validator of Spain's Observatorio de Accesibilidad Web and can include a manual review for the accessibility statement. A report measures the state; on its own it does not guarantee compliance.
If we then fix what came up ourselves, no change reaches production without going through four review agents (security, accessibility, quality and functionality) and a person, with deployments automated with CI/CD.
Frequently asked questions
Will you touch my portal?
No. The audit only reads. We do not change the code or the configuration, and tests are run in a separate environment.
Is it useful if another supplier maintains the portal?
Yes. The report is yours and is written so that any team can act on it, your supplier's included.
And after the audit?
You decide. We can fix what came up, prepare the migration or leave it at the report: the audit ends when it is delivered.
Also in Portals and development
Liferay migration
From an unsupported version to a current one, with a rehearsal and a rollback.
Liferay maintenance
Patches, incidents, changes and versions, with the same team.
Liferay consulting
Architecture, performance and integrations, to decide with data.
Liferay training
Tailored Liferay courses for teams, on their own portal.
Public sector
Accessibility, sign-in with Cl@ve and the Spanish National Security Framework (ENS).
The next step
Tell us how you work today and we will tell you where to start.