A business owner — I'll call her Patricia, not her real name — posted a job listing for a developer to maintain a VB.NET and WebForms system that ran her company's core operations. She expected the usual trickle of applications within a few days. Three weeks later, she had six applicants total, and only one had touched WebForms in the last five years. The other five were either fresh graduates who'd never heard of it, or senior developers quoting a rate roughly double what she'd budgeted, because they knew exactly how few other companies could make them this offer.
Patricia hadn't done anything wrong. Her system wasn't badly built, her company wasn't a bad place to work, and her job posting wasn't poorly written. She'd simply run into a hiring problem that has nothing to do with how well a system was built, and everything to do with where developers choose to spend their careers.
Why the applicant pool keeps shrinking
This isn't a sudden shortage — it's a slow drain that's been running for over a decade. Universities and bootcamps teach ASP.NET Core, not Web Forms. The official Microsoft documentation, the tutorials on YouTube, the sample projects on GitHub, the Stack Overflow answers written in the last five years — nearly all of it assumes modern .NET. A developer learning the ecosystem today has almost no reason to ever touch VB.NET or Web Forms unless a job specifically requires it.
And developers choosing where to work actively factor this in. A newer developer looking at two similar offers — one working on a modern .NET codebase, one maintaining a Web Forms system — will often pick the modern one even at a similar salary, because they're thinking about what that experience does for their next job, not just this one. That's not disloyalty to your company. It's a rational career decision, and it means your applicant pool for legacy roles skews toward people near the end of their careers rather than people building one.
The risk compounds as your experts age out
Here's the part that makes this more than an inconvenience: the developers who do know these systems well are, on average, getting older, and some of them are the only person at your company — or sometimes the only person you've ever found — who fully understands how a given module works. I've seen companies where one specific person was effectively a single point of failure for an entire critical system, not because anyone planned it that way, but because nobody replaced them before they needed replacing.
When that person retires, takes another job, or simply isn't available for a few weeks, the cost of that gap isn't the cost it would have been five years earlier. It's higher, because the pool you're hiring from is smaller than it was, and getting smaller every year you wait. This is a compounding risk, not a flat one — the same system costs more to staff this year than it did last year, and will cost more again next year, independent of anything happening to the code itself.
This is a business argument, not a technical one
It's worth separating this from the purely technical case for modernizing. A system can be technically stable — no bugs, no outages, doing its job fine — and still be a real business risk purely because of who's available to keep it running. I've worked with companies where the code itself wasn't the problem at all; the problem was that replacing the one person who understood it would have taken months, at a cost far higher than what they'd planned on paying when the system was first built.
This matters because it changes the conversation. The question isn't just "does this system still work?" It's "if the person who maintains this left tomorrow, how long would it take to replace them, and what would that cost?" For a lot of legacy VB.NET and Web Forms systems, the honest answer to that second question has been getting worse every year, quietly, while the first answer stayed "yes, it still works fine."
What this actually points toward
None of this means ripping out a working system overnight. It means recognizing that the hiring pool itself is a cost that's been rising in the background, and treating that as one more piece of information in deciding what to do with the system — alongside the technical questions, not instead of them.
A move to modern .NET and C# doesn't just open up technical options; it reopens the applicant pool. The pool of developers who know ASP.NET Core and C# is enormous compared to the shrinking pool who still know Web Forms and VB.NET well, and that gap keeps widening in the same direction every year. Hiring gets easier, onboarding gets faster, and you stop depending on a small and aging group of specialists for a system your business actually needs to keep running.
Patricia ended up extending her offer, paying above what she'd budgeted, and getting lucky with a candidate who was willing to stay a few more years. That's a workable short-term outcome. It's not a long-term plan, and she knew it. The hiring pool she drew from that time will be smaller again the next time she needs to draw from it, and the cost of waiting doesn't go down while she does.