Finding developers for older stacks, and keeping them

Developers for older stacks exist, but you have to look for them differently. Most of them no longer work with .NET Framework, Web Forms, PHP 5 or Delphi every day, but they started out on it and can still read that code fine. My advice is to look for someone who can read the old code and wants to build something new next to it, step by step. Such people can be found, and that work gives them a reason to stay.

Why they are scarce

Few new developers learn these stacks. Universities and bootcamps teach modern .NET, TypeScript or Python. People who know Web Forms usually learned it on the job, years ago.

Meanwhile the systems keep running, and for understandable reasons. .NET Framework 4.8 and 4.8.1 are Windows components and follow the lifecycle of the Windows version they are installed on. So Web Forms stays supported as long as .NET Framework ships with Windows. Microsoft has also said that Web Forms will not be ported to .NET Core or modern .NET. It stays a Windows-only framework without an open source contribution model.

PHP is less forgiving. PHP 7.4 has had no security fixes since November 2022, and PHP 8.1 none since the end of 2025. The supported branches today are 8.2 to 8.5, and security support for 8.2 ends on 31 December 2026. An application on a PHP version without updates is a security problem, and that affects hiring too: good PHP developers do not want to spend years on a version without updates.

Delphi is its own case. Embarcadero still releases new versions, targeting Windows, macOS, iOS, Android and Linux. The language is alive, but the pool of developers is small and mostly senior.

Who to look for

Look for developers with eight to fifteen years of experience who started on these stacks. A .NET developer working with ASP.NET Core today often has years of Web Forms or WinForms behind them. A PHP developer who works in Laravel now has usually seen code from before the frameworks.

Be honest in the job description about how much of the work is legacy. If you write "modern stack" and most of it is Web Forms, you will lose that person quickly. State the share of legacy work, and state the plan.

For Delphi, cast a wider net. Look for developers with a Delphi or Pascal background who now work in C# or Java. Going back is a smaller step for them than you might expect.

Where to find them

Search on past experience and look beyond the current job title. On LinkedIn and in CVs, Web Forms or Delphi often appears under a job from ten years ago. If you only search for "Delphi developer", you miss many candidates.

We recruit in Serbia, from offices in Belgrade, Novi Sad and Niš, and the client decides who joins the team. For legacy work a candidate does not need to know everything about the old system. They need to be able to read it and work in it safely. Our technical screening is described in how we screen developers in Serbia.

How to test

A standard coding test tells you little about legacy work. Use a real piece of old code instead, with secrets and customer data removed, and ask questions such as:

• What does this page do, and where would you look first for a bug?
• How would you add a test here without restructuring the code first?
• What would you tackle first if you had to maintain this for three months?

Watch how they reason. A good legacy developer reads first, changes little at a time and wants to know how deployment works before touching anything.

How to keep them

I think developers leave legacy projects when they feel their skills are going stale. A pay rise does little about that. What does help:

• A clear path towards modernisation, even in small steps.
• Time for tests, a build pipeline and better tooling on the old system.
• Never one person who is the only one who knows the system. Always put a second developer next to them.
• Room to build new parts in a modern stack.

Vision Healthcare shows what that path can look like. A PHP back end and a .NET Framework Forms front end were migrated step by step to .NET Core services and a React and Next.js front end, without halting day-to-day operations. A project like that is attractive to a developer as well: you work with the old system while building the new one.

Modernise or leave it

Not every old system needs replacing. Microsoft itself writes that staying on Web Forms on Windows is fine if you do not need cross-platform support or the other new features of modern .NET. An internal system that runs reliably and rarely changes can be maintained by a small crew.

If a lot of new functionality is coming, build it next to the old system rather than inside it. New parts get their own service and the old part shrinks over time. Make sure knowledge of the old system gets written down before people leave. Erik covers that in handing over legacy code to a new team.

Sources

• Microsoft: Lifecycle FAQ, .NET Framework
• Microsoft: An introduction to Blazor for ASP.NET Web Forms developers
• PHP: supported versions
• PHP: unsupported branches
• Embarcadero: Delphi