Modernization is a staffing problem wearing a technology costume

Walk enough estates and the pattern stops hiding. The technology plan is never the thing that fails. The people plan fails, and it fails because there wasn't one, because everyone was busy drawing the target architecture.

Here is the shape of it. A modernization program is a bet that, for its whole duration, you will simultaneously hold: the people who understand the old system, the people who can build the new one, and the smaller set who can do both, the translators, who are the actual bottleneck of the entire program. The architecture diagram does not show these people. Every delay in the program is one of them leaving.

Count your translators today. Not developers, translators: the ones who can read a 2009 stored procedure, say what business rule it encodes, say which three downstream systems secretly depend on its side effects, and then design its modern replacement. A mid-size estate typically has four to eight. A program plan that would need twenty is not a plan. It is a wish with a Gantt chart.

The retirement wall is real and it has dates. The people who built the client-server estates of the late 90s and early 2000s are in their late fifties and sixties. When we plan retirement waves, the finding that shocks boards is never a system; it is a birthday. The mainframe is not your problem. The four people who understand it retiring within eighteen months of each other is your problem, and unlike the technology risks, this one's dates are known years ahead and still ignored.

So the staffing plan is the modernization plan. Four practices from estates where this went well.

Pay for knowledge transfer like it is deliverable work, because it is. "Shadow Marge" is not a plan; Marge is busy running payroll. Booked pairing hours, recorded walkthroughs of the ugly modules, and the junior's name on the runbook after each session. One estate we respect gave every translator a standing Friday: no tickets, one apprentice, one subsystem at a time. Eighteen months later the bus factor on their worst system had gone from one to four. Total cost: fifty Fridays.

Make the old system a career, not a punishment. The fastest way to lose your translators is to signal that the future belongs to the new-build team while the people keeping revenue alive are the past. Pay the legacy-keepers at parity or better. Put them on the new system's design reviews, where their veto is the most valuable one in the room. The moment "maintenance" becomes the B team, your A-team translators update their résumés, and they are the most hireable people you employ.

Hire for the seam, not the stack. Job postings want "modern .NET, Kubernetes, event-driven". The program actually needs "can sit with a WinForms codebase without flinching and leave it better". Those people exist, they are cheaper than the fashionable profile, and they stay longer, because the market undervalues them and they know it. One good seam hire per translator buys you slack the Gantt chart never shows.

And write the people risks into the roadmap document itself, with names redacted and dates real. "Subsystem X: single expert, eligible to retire 2027-03" belongs next to "runtime EOL 2027-01" in the same table, weighted the same way. Boards fund what they can read. They have been reading birthday risk as an HR matter for twenty years; putting it in the modernization table is how it finally gets a budget line.

The pattern shows up outside our trade too. Look at any solo consultant's delivery record, an pipeline and release-process rebuild here, a reporting rebuild there: the work that sticks is the work that left the client's own people able to run the thing. That is the test, scaled down to one person. Scale it up to your estate: every quarter of the program, the number of people who can safely change the system should be going up, not down. If it is going down, the program is consuming the thing it depends on, and the architecture diagrams are decoration on a countdown.

Inventory first, as always. Just remember the inventory has two tabs, and the second one has birthdays on it.