When the Expert Retires: How One IBM i Shop Built a Bridge to the Future
Jim Buck, cofounder of imPower Technologies, shares a case study in what to do when a longtime IBM i developer is getting ready to move on
For decades, a familiar and urgent problem has hung over IBM i shops: What happens when the person who built your system retires? This was a burning question at CareGivers Home Care, a family-owned business that has run on IBM i since the early 1990s, learned their seasoned programmer was planning to phase out to retirement.
The system had been built and maintained for years by a local developer, a seasoned RPG programmer who knew every corner of the code because he’d written most of it. As he began looking toward retirement, the owner of CareGivers, Carmen Flitt, faced a scenario that plays out across the IBM i community with increasing frequency: a mission-critical platform, deep institutional knowledge concentrated in one person and no clear plan for what comes next.
In response, Carmen decided to invest in growing his internal team to bridge the gap. He hired his son, Jared Flitt, a network engineer with no prior IBM i experience.
An Unlikely Starting Point
Jared didn’t come up through RPG or midrange systems. He holds a computer science degree and spent several years as a network engineer before joining CareGivers in that same capacity. IBM i, RPG, libraries, green-screen navigation—none of it was familiar territory.
That changed when his father, recognizing the risk posed by their vendor’s transition of responsibilities, pushed Jared toward formal training. Jared enrolled in our IBM i foundations and RPG courses. The goal was to make sure someone inside the company understood how the system worked well enough to carry institutional knowledge forward once the original architect stepped back.
The courses gave Jared a fluency in how IBM i is structured, how programs and libraries interact and, critically, how the system drives the actual business: accounting, HR, payroll, scheduling and so on. At CareGivers, the entire operation runs on IBM i.
The original developer is still involved today, now in a much lighter, part-time capacity, a transition that worked precisely because someone was trained to pick up the institutional thread before it was dropped entirely.
System Fluency as a Strategic Asset
Jared’s course-driven understanding of the system let him see clearly where modernization needed to happen and why. That gap between knowing what needs to change and being able to build it himself is where AI tools like Claude Code have entered the picture.
Jared is candid that AI hasn’t replaced the need for foundational knowledge. If anything, it’s the opposite. Asking an AI tool to explain an unfamiliar block of legacy RPG only works if you already understand enough about the system to evaluate the answer, spot what’s relevant and know where that code fits into the bigger picture. The courses gave Jared that baseline. AI fills the execution gap, helping him move on modernization priorities he can identify but wouldn’t otherwise have the hands-on developer skills to execute alone.
It’s a useful model for an industry that often frames the choice as either “hire more RPG developers” or “replace the system entirely.” CareGivers found a third path: Train someone to understand the system deeply, then use modern tooling to extend what that understanding makes possible.
From Network Engineer to Modernization Lead
After roughly two years at CareGivers, Jared moved from network engineer into a new role, director of information systems and network engineer, a position he’s held for several months. In it, he’s leading a broader modernization initiative: taking core RPG applications and extending them with callable APIs, then building modern ReactJS front ends on top.
Asked which single course he’d recommend to developers today, Jared doesn’t hesitate: RESTful APIs on IBM i. It’s the skill that makes the wrap-and-modernize approach possible, since it’s how RPG business logic becomes something a modern front-end can call.
The business logic underneath isn’t changing. Instead, the interface is moving away from green-screen navigation toward something closer to what employees expect from modern software, all while keeping the RPG that already runs the business intact underneath. It’s a pattern gaining traction across IBM i shops: Rather than a full rip-and-replace, wrap and modernize the interface while preserving decades of proven logic.
CareGivers is also running Profound Logic’s Genie tool alongside this work, giving them another lever for modernizing the user experience without touching the underlying programs.
Jared is direct about what he sees as the wrong lesson to take from all this. Green screen, he argues, is too often written off as a liability, a “shoot first, ask questions later” reflex that treats the system as a burden to escape rather than an asset to build on.
CareGivers avoided that reflex after acquiring another company running on an off-the-shelf, industry-standard system. The comparison was instructive. The acquired platform, built to generic specifications, was slow and cumbersome to change. Their own IBM i system, built and refined over decades to match exactly what their business needed, could accommodate the same kind of change far faster. It’s a tangible argument for treating the system as a competitive advantage rather than a legacy problem to route around.
A Model Worth Repeating
For other IBM i shops watching a key developer approach retirement, CareGivers’ experience offers a fairly clear playbook: Don’t wait for the crisis.
Get someone, even someone without a development background, enough system fluency to understand what the platform does and why it matters. Start with training on IBM i concepts and operations so the system makes sense, add RPG to read and understand the code that runs the business, and then take RESTful APIs on IBM i to start opening that logic up to modern interfaces. Stay connected to the outgoing expert as long as possible, even part-time. And don’t treat modernization as a one-time project with an end date. Modernization is an ongoing investment, the same way you’d invest in any other core piece of infrastructure.
Jared’s advice to others facing a similar transition is straightforward: Get involved in the broader IBM i community—organizations like COMMON, for instance—and recognize that many companies are navigating exactly this same handoff. And most importantly, understand what the system actually does for the business before deciding whether to walk away from it.