Peter is retiring in six months. He’s been the RPG developer on your core order system for twenty-two years. The plan, as it usually is, sounds simple: post the job, hire a replacement, hand off the keys.
That plan works for capacity. It doesn’t work for Peter.
Two Different Problems Wearing the Same Name
There’s a difference between “RPG developer” and “the RPG developer who’s retired.” The first is a skill you can hire for—remotely, globally, at a range of price points. We’ve written about that gap before: North American RPG talent is aging, but the worldwide pool isn’t shrinking, it’s redistributing, and organizations that hire remotely are finding capacity without much trouble.
Peter isn’t that problem. Peter is twenty-two years of undocumented decisions—why the invoice job runs twice on Thursdays, which of four customer files is the real one, what that one flag actually controls. None of that is written down. None of it shows up in a job posting. A remote hire, however skilled, walks in the day Peter walks out and starts from zero on all of it.
So the honest framing isn’t “can we find RPG developers.” It’s “how do we replace the specific thing Peter did, which was never just writing code.”
Where the Market Actually Went
The gap left by retiring institutional-knowledge holders isn’t being filled by traditional hiring—remote or otherwise. It’s being filled by Managed Resource Enterprises (MRE): firms that specialize in IBM i support, modernization, and governance, and that sell a service, not a headcount.
What you’re buying from an MRE is structurally different from a hire. You get a team instead of a person, so no single point of failure. You get defined SLAs and escalation paths instead of “ask Peter.” You get developers who typically arrive broader-trained—comfortable with modernization work and integration, not just maintenance. And you pay a premium for it, because governance and bench depth cost more than one person’s salary.
That premium is real, and it’s the part that catches decision-makers off guard. A quote that looks like 1.5 to 2.5 times what Peter cost isn’t a markup for the sake of it—it’s the price of not depending on any single person again.
Where Decision-Makers Get Stuck
The reactions are predictable, and none of them are unreasonable on their own.
Some assume the pipeline will hold a little longer than it will—junior devs, a contractor, a few more years before the real decision has to get made. Some get real sticker shock from the first MRE quote and treat it as a negotiating problem rather than a different category of spend. Some reach for a six-month contractor as a bridge, only to find that experienced contractors are exactly as scarce as everyone said. And some overcorrect into “modernize everything now,” which trades one kind of risk for another.
All four reactions come from the same place: the cheap option—one dev replacing one dev—quietly stopped being on the menu, and nobody sent a notice.
What’s Actually Changed
The 1:1 replacement model isn’t dying because RPG talent vanished. It’s dying because the systems got too important to hand to one person again. A shop that’s run the same core system reliably for two decades has, without quite meaning to, made that system mission-critical enough that “one generalist developer” is no longer an adequate insurance policy against it.
That’s not a vendor’s talking point. It’s the same logic that made you protective of the system in the first place. You didn’t want Peter making unreviewed changes to it either—you just didn’t have to think about that as long as Peter was the one who knew where the bodies were buried.
The Real Choices
Once you accept that “hire a replacement” and “replace Peter” are different projects, four paths open up, and they’re not equally right for every shop.
Engaging an MRE makes sense when the system is stable and strategic and you need ongoing support or modernization work without building that capability in-house. You’re paying premium rates for predictability and reduced operational risk, and trading some internal control for a partnership.
Running an internal sprint to clean, trim, and modernize makes sense when the system has a defined end state and you have the budget and executive backing to get there before the knowledge fully ages out. It’s near-term pain for long-term relief, and it only works with real buy-in.
A hybrid model—keeping a small internal team for architecture and decisions while an MRE covers ongoing operations—makes sense when you still have people worth retaining but need capacity you can’t build alone. You keep the institutional judgment in-house and buy the rest as a service.
And for systems that are genuinely legacy and non-strategic, replacing with a COTS or SaaS product and sunsetting the IBM i footprint entirely is a legitimate option—more viable now than it used to be, and sometimes the honest answer is that the system doesn’t justify further investment either way.
Whichever path applies, the same discipline helps across all of them: clean what’s obsolete, trim what’s actually used, identify the programs that are genuinely critical, then modernize from there. That sequencing is what keeps any of the four options from turning into an open-ended budget line.
Where This Is Headed
None of this means IBM i is going away. It means the systems running on it are being repositioned as things worth protecting properly, not things to staff on the cheap.
Over the next few years, expect Managed Resource Enterprise (MRE) pricing to standardize as more organizations accept the service model instead of resisting it, hybrid arrangements to become the default for mid-to-large shops, and a new cohort of developers to train explicitly for modernization work rather than pure RPG maintenance. Remote hiring will keep solving the capacity problem it’s good at solving. It was never going to solve this one.
We’re building toward offering exactly this ourselves. Legacy Coders is putting together our own MRE, launching before the end of 2026—talent vetted and held to our own standards for skill and discipline, not just resold capacity with a markup. If your own Peter’s retirement date lands before then, it’s still worth having the conversation now.
The question worth asking isn’t whether you can find someone to replace Peter. It’s what you actually want your IBM i footprint to be once he’s gone, and which of these paths gets you there without discovering the gaps the hard way. If you’re not sure yet, that’s a conversation worth having before the retirement date gets circled on the calendar. Let’s talk.