
Your COBOL Developers Are Retiring. Here's What to Do About It.
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:
-
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.
-
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.
-
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.
-
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.
About David Depue
David Depue is a practitioner at Convergent LLC with deep expertise in retirement technology platforms.
More from the library
AI Won't Replace Your Retirement Operations Team. But It Will Replace the Parts They Hate.
Payroll file processing is the biggest time sink in retirement operations. AI-powered reconciliation is finally ready to fix it — but only if it's built for the complexity of retirement data.
Read articleLeading Recordkeeper — The Migration That Set the Standard
700K participants. $20B in assets. 600+ individual plans. Zero-day blackout. The largest single-platform retirement migration in recent industry history.

The Translation Gap
Why Most Retirement Technology Modernization Fails — And What the Winners Do Differently
The future of retirement technology will not be won by the firms with the most tools, the biggest teams, or the loudest AI announcements. It will be won by the firms that can translate domain knowledge into technical execution faster than their competitors.
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.