Skip to main content

Your COBOL Developers Are Retiring. Here's What to Do About It.

ArticleMarch 11, 2026By Dave DePue

The Numbers Are Clear

The average COBOL developer in the US is over 55 years old. In the retirement recordkeeping industry, many are in their 60s and 70s. They wrote the batch processing jobs, the data transformations, and the business logic that processes trillions of dollars in retirement assets every single night.

And they're leaving.

This isn't a theoretical risk. We've seen it firsthand. Clients calling us because their last COBOL developer gave two weeks' notice. Clients discovering that critical batch jobs were written by someone who retired five years ago and nobody documented how they work.

Why a Full Rewrite Is Usually the Wrong Answer

The instinct is to modernize everything. Replace COBOL with Java or Python. Move from mainframe to cloud. Start fresh.

Here's why that usually fails in retirement operations:

The business logic is the product. Those COBOL programs don't just move data around. They encode decades of plan rules, regulatory requirements, and edge cases that no one person fully understands. A rewrite doesn't just replace code — it has to replicate business logic that was never formally documented.

You can't stop production. Retirement operations run every single night. You can't pause batch processing for six months while you rewrite the system.

The risk is asymmetric. A failed modernization can result in participant impact, compliance violations, and regulatory action. The downside of getting it wrong far exceeds the cost of maintaining legacy systems.

A Practical Approach

What works is a staged strategy:

  1. Document what you have. Before you can modernize, you need to know what the code does. We've built tools that parse and analyze thousands of OmniScripts and COBOL programs, extracting business rules and dependencies.

  2. Stabilize what's critical. Not everything needs to be modernized at once. Identify the most critical batch jobs and business processes, and ensure they're documented, tested, and monitored.

  3. Modernize incrementally. Replace components one at a time, starting with the ones that carry the most risk or offer the most value. Keep production running on the legacy system while you build and validate the replacement.

  4. Build a 3-4 year roadmap. This isn't a 90-day project. It's a multi-year transformation that has to happen alongside daily operations.

We've helped recordkeepers and TPAs build these roadmaps. The key is starting before your last COBOL developer walks out the door.

Get the next one in your inbox.

One email when new research lands. No drip campaign. Unsubscribe anytime.

More from the library

Article

The Cost Line Nobody Puts on the Slide

August 24, 2026·Chandran Monikandan

Technology is the second-largest cost a recordkeeper carries, and the people who see it most clearly are the ones we keep asking to absorb it. The cloud proved the industry can change its mind in a decade. AI is the same story, on a faster clock.

Read article: The Cost Line Nobody Puts on the Slide
Article

Everyone Is Talking About FRP. Nobody Is Talking to Relius Users.

July 23, 2026·Kathy Sierra

FRP is a merger of Omni and Relius into one cloud platform, not a Relius upgrade. If you run Relius today, your migration is a different project from the one the industry is discussing — and the preparation that protects you does not need a date to start.

Read article: Everyone Is Talking About FRP. Nobody Is Talking to Relius Users.
Article

Retirement Is Complex. The Answer Isn't More Complexity.

June 25, 2026·Chandran Monikandan

The retirement industry's instinct is to meet a complex problem with an equally complex process. That instinct is the problem. The hard, valuable work is making it simpler.

Read article: Retirement Is Complex. The Answer Isn't More Complexity.

Your platform won't modernize itself. Let's talk.

Book a 30-minute platform assessment with a principal-level consultant. No pitch deck. No junior associate. Just a direct conversation about your systems, your challenges, and what it would actually take to solve them.