A Liferay portal kept up to date. And someone who answers when it fails.
Who it is for
For companies and public bodies with a Liferay portal or intranet in production, whether we built it or not. Also for anyone left without the supplier who built it.
The problem
A supplier built the portal and no longer answers. Every small change takes weeks. Nobody applies the patches because nobody dares. And when it goes down on a Monday morning, you do not know who to call.
How we solve it
We take charge of the portal. We start by reviewing it, to know what is there before we commit. Then we keep it up to date: we apply the patches, handle the incidents and make the changes your team asks for. And we take it from one version to the next before it runs out of support.
What it includes
Entry review
Architecture, data, access, deployments and technical debt. With the risks in priority order.
Patches and versions
Security patches, applied. And the version upgrade, planned before support runs out.
Incidents
Handled with agreed response times, in writing.
Ongoing changes
Pages, templates, forms, integrations, and performance and search ranking improvements.
Watch
Availability, response time and certificate expiry, with automatic alerts.
Regular report
The state of the platform, what has been done and what is worth doing next.
How we work
Every request comes in as an issue you can follow. Changes are delivered to a test environment, your team sees them and approves the go-live. Response times are agreed at the start and put in writing. The team that maintains is the team that builds, so the portal never has to be explained twice.
What we measure
Open and resolved incidents, response time, portal availability, pending patches and the version in use against the latest supported one.
How it is built
The first step is to bring the portal under control: the code in a repository, environments reproducible with Docker and deployments automated with CI/CD, across environments and with rollback. What gets published is what was tested.
New changes are built as React client extensions whenever possible, so the portal is not tied to one Liferay DXP version. Old modules are maintained and replaced when it pays off.
No change reaches production without going through four review agents (security, accessibility, quality and functionality) and a person. Static analysis carries our own rules for Liferay and stops the integration if a new finding appears.
Performance is worked on in the web server configuration, in Liferay's caches and in search. Backups are checked by restoring them, and secrets are centralized outside the code.
Frequently asked questions
Can you maintain a Liferay portal you did not build?
Yes. We start with a technical review to know what is there and, if it makes sense, we take it under maintenance.
What if my Liferay version is out of support?
We maintain it while we prepare the upgrade. A portal without patches is a risk, so the migration is part of the plan from the start.
Do you maintain the server too?
If you want, yes. Hosting, backups and monitoring are our managed systems service, run by the same team.
How do I know what state the portal is in?
Through a regular report on the state of the platform: incidents, changes delivered, patches applied and what we recommend doing next.
Also in Portals and development
Liferay migration
From an unsupported version to a current one, with a rehearsal and a rollback.
Liferay consulting
Architecture, performance and integrations, to decide with data.
Liferay audit
The real state of the portal, with the risks in priority order.
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.