How to Modernize Legacy Systems Without Migration: A DXP Approach
You can modernize the experience on top of your legacy systems, including governance and AI, without migrating the backend underneath.
• October, 2026
Key Points
If your organization runs on legacy systems that are too critical to replace but too rigid to keep up with what users expect, this one's for you. We sat down with two of Liferay's senior solution engineers to talk through a way to modernize the experience layer without touching the backend, plus the governance and AI questions that come with it. Here's what we took away.
- Full "rip and replace" trades one risk (technical debt) for another (multi-year timelines and cutover risk); a DXP modernizes the experience layer without replacing the backend underneath it.
- Liferay Objects turn a legacy data structure into auto-generated REST and GraphQL APIs without custom integration code. That's the mechanism that let Zions Bank cut new-feature go-to-market time from a year to one month.
- A unified experience layer built on personalization, omnichannel delivery, and SSO replaces fragmented logins. MyNavy Portal used this approach to unify access for 870,000+ users.
- Governance scales through a centralized control plane and atomic-level RBAC (not just "admin" vs. "user"), so business units can move fast without breaking brand or security.
- AI is best understood as a third kind of user, alongside external partners and internal teams. It needs the same two answers as anyone else: who is asking, and what they may see, enforced before the model ever sees the data.
You don't need to rip out your legacy systems to modernize your digital experience. A Digital Experience Platform can sit on top of existing ERPs and core legacy systems, surfacing data through modern interfaces, unifying the experience, and layering in governance and AI, all without a multi-year migration project. That's the throughline of our recent webinar, Legacy System Modernization Without Migration, featuring Liferay's Wes Kempa (NA Sales Engineering Manager) and Bryce Sperling (Senior Sales Engineer).
| Rip-and-replace | DXP layer (no migration) | |
|---|---|---|
| Timeline | Multi-year projects, high cutover risk | Weeks to months for first release |
| Legacy data | Migrated into a new system | Stays in place, exposed via API |
| Backend risk | High, one big cutover | Low, legacy evolves on its own schedule |
| IT role | Builds and maintains every integration | Provides a governed platform; business units self-serve |
Why doesn't "rip and replace" work for legacy modernization?
Full rip-and-replace fails because it trades a known problem, technical debt, for new risks: multi-year timelines, ballooning budgets, and a real chance the new system breaks on cutover. Most IT teams have been told that true modernization means replacing the legacy system outright. In practice, that stalls before it delivers value. The old ERP or database isn't a foundation to build on. It's an anchor holding the organization in place while user expectations keep moving.
What's the alternative to a full legacy replacement?
The alternative is innovating around the legacy system instead of replacing it. A DXP sits on top of the existing backend, exposing its data and workflows through modern interfaces while the legacy system keeps running underneath. This lets a team ship new customer-facing experiences immediately, without waiting on a backend rebuild. The legacy system still gets modernized, just on its own timeline, evolved gradually rather than swapped out in one high-risk cutover event.
What does fragmentation actually cost the business?
Fragmentation shows up as three distinct costs, not one vague sense of disorganization. Data silos force teams to build custom connectors because a legacy database doesn't talk to a modern CRM. Experience silos mean a customer logs into separate portals for separate needs, turning even a strong organization into one that feels disorganized. Operational silos make IT the bottleneck for every minor content change or new department site.
That comes at a cost, paid in three ways: Data Silos, Experience Silos, and Operational Silos... Add it all up, and you're not managing a digital ecosystem — you're managing a house of cards.
NA Sales Engineering Manager, Liferay
How do you unlock legacy data without migrating it?
By treating the DXP as a decoupling layer instead of a destination for data migration. Liferay connects directly to a legacy backend rather than moving its data into a new system, so the data stays put while the platform exposes it through modern APIs. The mechanism is Liferay Objects, a low-code way to define a business entity, like a loan application, directly in the platform. The moment an Object is defined, Liferay auto-generates REST and GraphQL endpoints for it, ready to feed a portal, mobile app, or third-party system.
In this architecture Liferay connects your rigid, old-school backends — think a core banking system, or a database that's been in place since the 90s — to the modern interfaces your users actually want. That gives you the best of both worlds: the stability of your legacy systems with the agility of a modern DXP.
Senior Sales Engineer, Liferay
What did this look like for Zions Bank?
Zions Bank faced a fragmented, slow-moving legacy environment where feature releases could take up to a year to reach production. After implementing Liferay as a modern layer over their existing systems, they cut that go-to-market time down to one month. They consolidated fragmented legacy services onto one foundation and used Liferay's multi-site capabilities to turn a single built site into a template for seven others, keeping brand and security consistent across public, treasury, and digital banking portals.
How do you unify a fragmented customer and employee experience?
By putting one experience layer on top of the systems instead of forcing separate logins for separate needs. Fragmentation shows up as friction for customers and a maintenance burden for IT. A DXP addresses this through dynamic personalization (the same URL renders differently for a retail customer versus an advisor), true omnichannel delivery (build once, deploy to web, mobile, or kiosk), and unified SSO with SAML 2.0 or OIDC, so a user moves from checking a balance to starting a mortgage application without re-authenticating.
How did MyNavy Portal apply this at scale?
MyNavy Portal consolidated a digital presence that had been scattered across dozens of systems into one single sign-on experience for over 870,000 users. It used role-based access control to automatically personalize homepages and permissions by rank, surfacing the right data to the right person without compromising security. Despite that scale, a cloud-native architecture kept performance high. That's proof the same unification approach works whether the user base is a few thousand banking clients or hundreds of thousands of sailors.
How do you scale governance and security without slowing the business down?
By giving business units a sandboxed, self-service layer instead of routing every request through IT. Without it, IT either builds every departmental site from scratch or a department buys its own unmanaged tool outside IT's control. Liferay's centralized control plane solves this with global templates, pre-approved headers, login widgets, and CSS any new site inherits automatically. That lets business teams move fast without breaking brand consistency or bypassing security protocols.
How granular does the permission model actually get?
Permissions go well beyond "admin" versus "user." They go down to the atomic action level. A client sees their own portfolio, an associate can initiate a trade, and a compliance officer approves it, all on the same interface, governed entirely by role. Every login, action, and data modification is logged centrally, so an audit doesn't mean hunting across five systems. Liferay also integrates directly with existing identity management, including Okta, Azure AD, or SAML 2.0, so there's no new identity silo to maintain.
Where does AI fit into a modernized, governed DXP?
AI fits in as a third kind of user, not a feature bolted onto the platform. Alongside the external users unified above and the internal teams governed by RBAC, an AI agent now authenticates and carries a scope like everybody else. That means it needs the same two answers as any other user: who is asking, and what may they see. Gartner projects that over 40% of agentic AI projects will be canceled by 2027, citing escalating costs, unclear business value, and inadequate risk controls. Of those three, risk controls are the one that's an architecture problem. Liferay's AI-agnostic approach lets teams connect OpenAI, Gemini, or Claude instead of one model, with Model Context Protocol support enabling secure, governed integration with enterprise data.
That's governance and AI working together, not as separate conversations — the same permission model that protects your content is what keeps your AI agents honest.
Senior Sales Engineer, Liferay
How does an AI agent actually inherit those permissions?
Retrieval is filtered by the requesting person's permissions before anything reaches the model, not afterward as cleanup. If someone can't open a document, it's never retrieved, so the model can't reveal it, however the question is phrased. There's also no second permission model to maintain: every role, reorg, and personnel change only has to be reflected once, and every interaction stays attributable to a real person rather than a shared service account. This matters most for the population outside the organization, such as customers, brokers, dealers, and contractors, since an agent can only inherit a model that already exists.
What does this look like in practice?
In practice, this runs through an AI Hub as a single entry point, with specialist agents for distinct jobs: content creation, workflow approvals, knowledge lookup, and translation. The pillar bank example from the webinar shows the same pattern: a Wealth Assistant that pulls trending portfolio data and masks account numbers before answering a client's question, an Advisor Co-Pilot that respects existing RBAC so it can't use a document the user isn't permitted to open, and automated translation into more than 30 languages.
The pattern holds across all three pillars, and now across AI too: modernization doesn't require starting over. The systems already running your business can stay exactly where they are. What changes is the layer sitting on top of them, and who, or what, is allowed to see through it. That pattern isn't specific to banking or government either. The same layer-not-replace approach applies whether the legacy system is an ERP in manufacturing, a claims platform in insurance, or a billing system in utilities. That's a smaller, faster, and considerably less risky project than a full replacement, and it's one most organizations can start well before their legacy systems are anywhere near the end of life. If that describes where you are, request a demo to see what this looks like against your own environment.
FAQ
Does this reduce total cost of ownership compared to a full replacement?
It reduces the costs specific to running two systems at once. A full replacement typically means a parallel run: paying for the old system and the new one, plus the integration work to keep both in sync during the transition. Layering a DXP on top of a legacy system that keeps running skips that parallel-run cost entirely, since there's only ever one backend in production.
What happens to our existing integrations and middleware during this kind of rollout?
They stay in place. Because the DXP layer connects to the legacy backend rather than replacing it, any middleware, custom connectors, or integrations already built around that system keep functioning as they are. The DXP calls into the existing system through the APIs Liferay Objects generate, rather than requiring those integrations to be rebuilt against a new platform.
Will this work with our existing identity provider?
Yes. Liferay integrates with SAML 2.0, OIDC, LDAP, and SCIM, and connects directly to identity providers like Okta and Microsoft Entra ID. User roles, groups, and attributes continue to be managed in the system you already use as your source of truth, and Liferay enforces those same rules across every experience built on the platform.
Do business teams need a developer to build or update pages?
Not for most day-to-day changes. Liferay's Page Builder and Fragments let non-developers assemble pages from pre-approved, on-brand components without writing code. Developers remain involved for defining new Objects, building custom integrations, and setting the governance rules and templates that business teams then work within.
Do we have to roll out all three pillars at once, or can we start with one?
You can start with one. Unlocking legacy data, unifying the experience, and scaling governance are three separable initiatives, not a single all-or-nothing project. Most organizations start wherever the pain is sharpest, often unlocking a single legacy data source first, and expand into the other pillars once that's proven out, rather than committing to the full scope upfront.
