Large enterprise intranet projects have a predictable failure mode: they get specced against a wishlist, built against a deadline, and handed over before the organisation is ready to use them. We've seen it happen with SharePoint, with Confluence, and — if you're not careful — with Liferay DXP too.
What makes the difference isn't the platform. It's the architecture decisions made in the first two weeks of the project. This post walks through what we built, why we made the choices we made, and what we'd do differently next time.
The brief: one intranet, 8,000 users, three countries
Our client operated across India, Saudi Arabia, and Malaysia. They had three separate SharePoint environments that had diverged over seven years — different content structures, different permission models, different integrations with their HRMS. The business wanted one unified intranet with localised content, role-based visibility, and a single search experience.
The non-negotiables were Arabic language support (including RTL layouts), integration with their Azure Active Directory, and a mobile-accessible experience for field operations staff who never sat at a desk.
Why Liferay DXP over the alternatives
We evaluated Liferay DXP against SharePoint Online and a custom-built React portal backed by a headless CMS. SharePoint Online was ruled out early — the client's Azure AD was a hybrid configuration that SharePoint's admin model didn't handle cleanly, and the Arabic RTL rendering required significant custom CSS work that would be brittle across updates.
Liferay DXP won on three specific capabilities:
- Native multilingual support with RTL layout switching per language, not per theme
- Segment-based personalisation at the page level without custom module code
- OSGi module architecture that isolates custom functionality from platform upgrades
- OpenID Connect integration with Azure AD that worked out of the box with minimal configuration
Architecture decisions that held up
Cluster and caching strategy
We ran Liferay in a four-node cluster behind an Nginx load balancer. Session affinity was on — we found that sticky sessions reduced cache invalidation events significantly compared to a round-robin configuration with distributed sessions.
Redis handled both Liferay's portal cache and the session store. We kept portal cache TTLs aggressive (15 minutes for most content) because the client's content team updated pages frequently and stale content visible to 8,000 users is a political problem, not just a technical one.
Information architecture before platform architecture
We spent three weeks on information architecture before writing a line of configuration. Department leads, HR, and IT each had different mental models of what the intranet was for. Without that alignment, any technical architecture would have been building in the wrong direction.
What we would do differently
- Start content migration planning in week one, not week eight — it always takes twice as long as estimated
- Involve HR in information architecture decisions from the beginning, not as reviewers at the end
- Use Liferay's headless REST APIs for the mobile experience rather than the portlet-based approach we inherited from the initial prototype
- Automate the permission sync with Azure AD groups on day one rather than managing it manually during the pilot
Key results
- 8,000 active users onboarded in 14 weeks from project kick-off
- Page load times under 1.2 seconds on the corporate network
- Department content managers self-sufficient after a half-day training session
- Three legacy SharePoint environments decommissioned within 60 days of go-live
If you're evaluating Liferay DXP for an enterprise intranet, the platform is capable. The work is in the architecture and the people decisions made before the first module is deployed.