Freight doesn’t stop. Not for weather, not for port congestion, not for a carrier who missed their EDI window. And it doesn’t stop when the person who built your warehouse management system retires after 30 years and takes half your institutional knowledge with them. 

Read also: Beyond ‘Vibe Coding’: AI as the Great Amplifier in Logistics Technology

Logistics leaders spend a significant part of their careers managing and preparing for disruptions. But the industry has yet to truly contend with the impending mass exodus of IT professionals who quietly administer its mission-critical systems. 

The platforms that move freight — terminal operating systems, WMS, EDI translation layers, freight settlement engines — are among the most reliable of any industry. They run continuously, handle enormous transaction volumes, and rarely fail. The teams that maintain them are lean by design, because lean has worked. For decades, a small cadre of deeply experienced developers and administrators has kept the lights on, and there’s been no reason to question this arrangement. 

The status quo is shifting, however. The developers who understand these decades-old IBM Z and IBM i codebases are retiring, and the people replacing them don’t have the skillset. The skills aren’t taught in classrooms because most new developers aren’t interested in building a career in what they consider “legacy” platforms. The replacement talent pipeline is drying up. 

The instinct is to treat this as a staffing problem. But you can’t hire your way out of a talent pool that is contracting faster than any organization can backfill it. The only way to make the math work is to stop using headcount as the measure and start thinking about knowledge: how it’s held, how it transfers, and how much productive capacity a small team can realistically carry. 

Shrinking pool, growing workload 

Look at the numbers and the picture isn’t pretty. 

According to the 2026 Fortra IBM i Marketplace Survey, the community’s long-running pulse check for the platform, IBM i skills ranked as the No. 1 concern among respondents for the first time, cited by 69% of the 315 IT professionals surveyed. That’s up from 45% in 2020. The reason isn’t hard to guess. The IBM i community is disproportionately composed of Baby Boomers, the youngest of whom are now in their early sixties and eligible for Social Security. The very last of the Boomers reach 62 — the average U.S. retirement age — this year, and while many in the IBM Z and IBM i community keep working well past this age, repeatedly bringing aging developers back for “just one more job” is hardly a sustainable approach. 

Meanwhile, the demand side keeps moving. According to the American Trucking Associations’ current U.S. Freight Transportation Forecast, total U.S. truck tonnage is projected to increase from roughly 11 billion tons in 2024 to nearly 14 billion tons by 2035. Meanwhile, partner counts continue to expand. Carriers, brokers and 3PLs are multiplying the number of EDI relationships a single operation must manage. Each new trading partner represents an additional integration to build, test and maintain. Each acquisition adds another WMS instance or terminal system to the portfolio. In short, the same shrinking team is being asked to manage a widening surface area.  

These developments exist in profound tension. The staffing gap can’t be closed when the talent pool logistics depends on is contracting faster than any organization can backfill it. The mechanisms that industry has historically used to correct the asymmetry between work and skillsets — hiring, training, promoting from within — don’t work like they used to. You can post a role for an RPG developer with WMS integration experience role and offer what seems like plenty of money. You might be waiting a while. 

The industry has absorbed this pressure so successfully because experienced teams are good at absorbing pressure. They’re good at finding workarounds. Sure, documentation is minimal, but that’s because carrying context in their heads has always been faster than writing it down. It’s this capacity for quiet competence that makes the risk so hard to see — right until it isn’t. 

Reading from the wrong playbook 

Farming the conundrum as a staffing problem feels intuitive because it’s the one logistics leaders know how to act on. You identify a gap, you post a role, you fill it. But there’s no hiring solution that can work at the pace that the retirements are happening. The people who could fill those roles were trained decades ago, and there just aren’t enough of them left. 

So, the industry keeps doing the one thing that can’t work and calling the result a “talent shortage.” 

The more useful question isn’t “how do we find more people for these systems?” but rather two distinct questions that the staffing framing obscures entirely. First: How do we capture what the people who are leaving know before they leave? And second, how do we reduce the amount of specialized knowledge required to keep these systems running in the first place? 

These are solvable problems. They don’t require a talent pool that doesn’t exist. They do, however, require treating the lean team not as a vulnerability to manage, but as a permanent constraint to design around. Lean IT isn’t going away, and the Boomer cohort isn’t coming back. The question is whether the knowledge and productivity those developers represent can be extended — captured, structured, and made accessible to a smaller and less specialized team — before the window closes. 

This reframe has major implications for how the industry should invest its resources. Instead of hopeless recruitment strategies and retention bonuses for developers already past retirement age, the investment should be in the knowledge and the system itself. 

Three variables worth managing 

The path forward requires accepting that the talent shortage won’t be solved and building accordingly. 

That starts with knowledge capture while the window is still open. The developers with the deepest understanding of these systems are still in the building (for now). The institutional knowledge they carry, the business rules embedded in decades-old code, the undocumented exceptions and the reasoning behind them — all that needs to be surfaced and structured before key employees walk out the door. This can’t be a retirement-eve scramble, either. It will require continuous discipline, and organizations that treat it as the former are taking a risk that they may not see coming until it’s too late. 

The second component is skill accessibility. If maintaining core logistics systems requires a narrowing pool of specialists to function, the systems are fragile by design. Lowering that barrier — that is, making it possible for a less specialized team to understand, maintain and extend what the experts built — changes the math in a way that no hiring strategy can. 

The other variable is integration burden. EDI onboarding, carrier connections, WMS extensions are the types of tasks that consume a lean team’s hours faster than almost anything else. Every hour spent on routine integration work is an hour not spent on the higher-order problems that require advanced expertise. Reducing that burden, whether that’s through better resourcing or smarter processes (or both), extends what a small team can realistically carry. 

The window is open. For now.
The risk that logistics IT faces from this skills gap arrives quietly. There’s no single failure mode, no obvious warning light. Just the slow erosion of a capability that the business has always assumed and never had to think about — until the person who held it together submitted their notice. 

The logistics industry has managed this for years because the teams running these systems are exceptionally good at their jobs. That competence has been an asset. It has also made the underlying fragility invisible. 

The developers who understand these systems most deeply are still in the building. The knowledge they carry can still be captured. The systems they maintain can still be made more accessible to the people who will inherit them. But none of that is true indefinitely. 

The time to act is while those developers are still available to validate what gets documented, correct what gets misunderstood, and transfer what can’t be recovered once they’ve given their notice. 

Author Bio

Rob has worked as an in-the-trenches IBM i developer since 1992, with the past 15 years focused on developing modernization efforts for legacy systems written in RPG. Currently serving as Senior Partner for CNX Corporation in Chicago, Rob is a strong advocate for introducing highly user-friendly web and mobile applications to conventional RPG shops and boosting the image of IBM i as a truly World Class application server.