How We Actually Ship Modern Experiences Over 20-Year-Old Cores

Most of what I do at Convergent is build modern web experiences on top of recordkeeping systems that were never designed to be talked to. A participant portal on top of a 30-year-old core. A plan sponsor dashboard pulling from a batch-only data warehouse. An advisor tool that needs real-time data from a system that thinks in overnight cycles.

The reflex from architects who haven't done this is to say it can't be done without rewriting the core. That's wrong. It's done all the time. What it requires is a specific engineering pattern that respects the constraints of the legacy system instead of pretending they don't exist.

This is what that pattern looks like in practice.

The four layers we end up building

After enough of these engagements, the architecture converges. The four layers below are the ones that show up almost every time, in roughly this order.

1. A read-side cache and event layer. The first job is making the legacy data accessible without hammering the source system. That usually means standing up a read-side cache (Postgres or Redis depending on the workload), feeding it from whatever the legacy system can emit — nightly batch extracts, change-data-capture if you're lucky, scheduled polls if you're not. The cache is what the modern experience reads from. The core never sees the participant traffic.

2. A thin write-orchestration service. Writes are the hard part, because they have to actually land in the core. We build a small service that takes user-initiated writes from the modern interface, validates them against the rules the core enforces, queues them, and submits them through whatever the legacy system supports — a batch file, an API if one exists, an RPA-driven UI submission if neither does. The service tracks state so the participant sees "submitted / processing / completed" without needing the core to push updates back in real time.

3. A rules-and-validation layer. This is the unglamorous part that determines whether the system actually works. The core enforces hundreds of rules — contribution limits, eligibility logic, vesting calculations, plan-document constraints — and the modern interface needs to enforce the same ones at submission time, or users will fill out forms that fail downstream. We build this layer by reading the legacy rule logic (often by reading the actual source code) and replicating it in a maintainable form on the experience side. It's tedious. It's also the difference between a portal that works and a portal that generates a phone call for every other submission.

4. The experience layer. Only after the first three layers are stable does the actual UI work happen. Modern stack — React, Next.js, whatever the team uses — but architecturally lightweight, because the heavy lifting is all underneath. A participant portal built on a clean read-cache and a working write-orchestration layer can ship in 60-90 days. The same portal built without those layers takes 18 months and breaks regularly.

Where engineers get this wrong

The mistakes I see, in roughly descending order of frequency:

• Trying to make the legacy core do real-time things it was never designed to do. If the system is batch-oriented, build around that. Don't fight the architecture.
• Re-implementing rules without reading the legacy logic. The portal validates against what the engineer assumes the rules are. The core rejects half the submissions. Everyone is confused. Read the source.
• Skipping the cache layer to "keep it simple." It's not simpler. It's slower and more fragile, and the legacy system pays the cost in load that it can't sustain.
• Treating RPA as a permanent integration strategy. RPA is a useful bridge for write paths where no API exists. It's not a long-term architecture. Plan to replace it.
• Underestimating the operations work. Standing up a bridge architecture means standing up the monitoring, alerting, and incident response that goes with it. If ops isn't included from day one, you're building a system that nobody can support.

A recent example

On a Newport Group participant portal engagement, the brief was a fully modern enrollment and self-service experience for non-qualified plans. The recordkeeping engine underneath was years older than the team building the portal. The pattern above is essentially what we built — a read-side cache fed from the core's nightly extracts, a write-orchestration service that submitted enrollments through the supported channels, a rules layer that replicated the eligibility and contribution logic, and a clean Agile delivery against that foundation.

The core never changed. The participant experience was unrecognizable from what came before. That's the outcome the pattern produces.

When this works and when it doesn't

This approach works when the legacy core is stable, when the team is willing to invest in the bridge architecture rather than pretending the work is just front-end, and when the business case is incremental modernization rather than a deadline-driven replacement.

It doesn't work when the core is genuinely failing and needs to be retired, or when the politics demand a "transformation" narrative that requires the core to disappear on a fixed schedule. Those engagements need different conversations before any engineering starts.

For everything in between — which in retirement technology is most engagements — the bridge pattern is what gets modern experiences in front of clients without putting operations at risk.