The Delphi talent pipeline, in numbers

Short answer: The Delphi staffing problem is not cost, it is retirement.

• Nearly 6 in 10 professional Delphi developers are 45 or older, against about 1 in 5 for Java.
• More than a quarter (28%) are 55 or older, against 6–9% for Java and C#.
• Within five years, about one in six will be at or past 65.
• Hardly anyone new is learning the language.

When an experienced Delphi developer leaves, the business knowledge inside the system often leaves with them. Such developers are hard, sometimes impossible, to replace. Get that knowledge out of their heads and into tests and documents now, whether or not you migrate.

Key points

• The oldest workforce of any major language. In our analysis of the 2025 Stack Overflow survey data:
  • 59% of professional Delphi developers are 45 or older (Java: 21%);
  • 28% are 55 or older (Java: 6%);
  • only 21% are under 35 (Java: 51%).
• The retirement wave has started.
  • Already winding down: 7.7% of Delphi users say they are already gradually reducing their hours towards retirement, about four times the rate for C# or Java.
  • Five years: about 17% of today’s professional Delphi developers will be at or past 65.
  • Ten years: 28% will be.
• Few replacements. 2.5% of professional developers and 1.7% of people learning to code use Delphi.
• Not a pay problem. Delphi developers earn about the same as Java developers. They are scarce, not overpaid.
• Hiring can take years. Sometimes migrating is quicker than finding the next Delphi expert.

How old is the Delphi workforce?

Much older than any other major language’s. We analysed the public data of the 2025 Stack Overflow Developer Survey: 610 professional developers who used Delphi in the past year, against more than 7,000 each for Java and C#.

Professional developers who used it in the past year	Delphi	C#	Java	TypeScript
Aged 45 or older	59%	26%	21%	16%
Aged 55 or older	28%	9%	6%	4%
Under 35	21%	44%	51%	53%
Median years of professional experience	25	12	10	10
At or past 65 within 5 years (estimate)	17%	5%	4%	2%
At or past 65 within 10 years (estimate)	28%	9%	6%	4%
All users: already “gradually reducing work hours” towards retirement	7.7%	2.1%	1.8%	1.3%

The Delphi figures are not a sampling accident. The share aged 55 or older is 28%, with a 95% confidence interval of 25–32%. For C# it is 8–9%.

How the five- and ten-year figures are estimated: the survey records age in ten-year bands. We assume ages are spread evenly within the 55–64 band. So about half of that band turns 65 within five years, and all of it within ten, on top of those already 65 or older. Not everyone retires at 65, and some leave earlier.

These figures are a floor, not a ceiling. Stack Overflow respondents skew young; older developers are less likely to answer online surveys. The real Delphi workforce is probably older still, so treat 28% as the minimum share aged 55 or older, not the maximum.

Who will replace them?

Very few people. In the same survey:

• Professional developers: 2.5% used Delphi, against 29.9% for C# and 29.6% for Java.
• People learning to code: 1.7% used Delphi, against 40.8% for Java.
• Developers who want to work with it next year: 1.9% of all developers name Delphi, against 19.4% for C# and 15.8% for Java.

The popularity indexes agree on the direction:

• TIOBE ranked Delphi/Object Pascal 13th in September 2026, down from 9th a year earlier.
• PYPL had Delphi/Pascal at 1.17% in September 2010 and 0.07% in September 2024.

Embarcadero’s “more than three million users” covers all its tools and is not independently audited.

Put the two numbers together: a quarter of the workforce is within ten years of retirement, and almost nobody is entering. For every Delphi developer under 35 there is more than one aged 55 or over. For Java there are eight under 35 for every one aged 55 or over.

Is the problem that Delphi developers are expensive?

No. The problem is that they are hard, sometimes impossible, to replace.

Pay is not the issue. In StepStone’s German salary data, Delphi developers earn about the same as Java developers and about 7% less than C# developers.

The issue is what each of them carries:

1. The knowledge leaves with the person. In most Delphi systems, the business rules sit inside form event handlers. The reasons for them (which customer, which regulation, which incident in 2009) sit only in people’s memories. When the last person who understood a module leaves, that knowledge has to be rediscovered from the code and the data, which is slow and expensive. See why the rules are trapped in the screens.
2. The bus factor falls to one. The bus factor is the number of people who would have to leave before a module can no longer be changed safely. In many Delphi systems it is one.
3. Hiring is slow, sometimes slower than migrating.
   • What we see: finding an experienced Delphi developer who is available takes months, and sometimes years.
   • What that means: a slice-by-slice migration to a widely staffed stack can be the faster way to secure the system.

What to do now, whether or not you migrate

Find where the knowledge is concentrated, then get it out of people’s heads, starting with the modules that change most. None of these steps commits you to a migration, and all of them make one cheaper.

1. Measure your bus factor per module

Version control already records who changed what. For each top-level folder of the Delphi source, count commits per author over three years:

for d in src/*/ ; do
  echo "== $d"
  git log --since="3 years ago" --no-merges --format='%aN' -- "$d" |
    sort | uniq -c | sort -rn | head -3
done

• One author with most commits, nobody else in the past year: bus factor one. Mark the module red.
• Two or more regular authors: bus factor two or more.
• No commits: either stable or untouchable. Ask which.

A .mailmap file merges authors who used several names. In Subversion, svn log --quiet gives the same list. No version control at all is the first finding. Commits are a proxy, so check with one question: “Who would you call if this module broke at month end?”

2. Draw a retirement map

Put people and modules on one page. For each red module, record who can change it today, who could take over, and when the expert plans to step back. Ask people about their plans rather than inferring them from age; storing age data for this raises GDPR questions you do not need.

3. Turn knowledge into characterisation tests

A characterisation test records what the system does today, not what the specification says. The term is Michael Feathers’. Such tests are executable documentation that keeps working after the expert has left. Once a rule is out of its form, DUnitX can run them:

[Test]
[TestCase('Tier A order', 'A,1000,950')]
[TestCase('Tier B order', 'B,1000,1000')]
procedure TPricingCharacterisation.NetPrice(const Tier: string;
  const Gross, Expected: Integer);
begin
  // Records current behaviour, including any oddities.
  Assert.AreEqual(Expected, CalcNetPrice(Tier, Gross));
end;

Where rules are still inside button handlers, run a known business scenario and compare the resulting database rows with a saved copy. Have the expert explain each difference while they are still there to explain it.

4. Document the business logic, not just the code

Per module, write down:

• what it does for the business;
• which rules it applies, and why;
• which tables it writes;
• what it calls;
• its known traps.

Let the expert talk while a business analyst writes. Analysts ask “why” in a way developers documenting their own code rarely do.

5. Pair a second person with every red module

Every change to a red module is made by two people. Pairing on real changes transfers more than any handover document.

When does this push you towards migration?

When modules that still change every month have a bus factor of one, and hiring cannot fix it in time.

A Java (Spring Boot) back end with a React and TypeScript front end, our usual choice, draws on the largest pools in the survey: 29.6% of professional developers use Java and 48.8% TypeScript, and half of them are under 35. Depending on the case, C# (29.9%) can be the more convenient choice, for example where your other systems already run on .NET.

Migration does not make your Delphi developers redundant. They become the domain experts of the new system. They know:

• why the rules are as they are;
• which edge cases matter;
• where the data is dirty.

Pair them with the new team from the first week, and their knowledge becomes the test suite that proves the new system behaves the same. The cost case is in the hub article.

When not to worry

Do the cheap steps above anyway. But staffing alone does not justify a migration if all of these are true:

• the system changes a few times a year;
• at least two people can change each critical module;
• nobody key plans to leave soon.

How we approach it

PannonRex’s Delphi experts also work as business analysts, backed by project managers, dedicated analysts and test specialists. With decades of experience of under-documented systems, they can recover a system’s business logic efficiently, even when the last person who really knew it has gone. We have done this on many projects: rediscovering what a system does from its code, its data and its users, and turning that into documentation and tests.

That gives you four options, and we offer all of them:

• Document it. If you do not want to migrate, we document the business logic and build a characterisation test suite. Your system stays as it is, but the knowledge no longer depends on one person. We have delivered projects of exactly this kind.
• Strengthen the team. Our Delphi developers work alongside your experts, so the knowledge transfer does not rest on documents alone.
• Modernise. We upgrade the system to the current Delphi version, which extends its life and deals with security, compatibility and compliance issues along the way. See upgrading Delphi 7 to Delphi 13. It also makes a mixed migration possible: a new web front end, with the business logic kept in Delphi as services and migrated gradually where needed. See our case study.
• Migrate. We move the system slice by slice to the web, usually on Java (or C# or another stack where it fits better), with your experts as the domain authority. See how we migrate Delphi to Java and the web.

It starts with a technical and business audit:

• the bus-factor analysis above;
• a map of each module by how often it changes and how many people understand it;
• interviews with your experts about how the system really works;
• interviews with key stakeholders about business goals and risks, so the work starts with the challenges that matter most.

Frequently asked questions

Can we still hire Delphi developers?

Yes, but slowly. Experienced Delphi developers who are available are rare, and every year more of them retire. Plan for months, sometimes years, and have a plan B.

We have already lost the person who knew the system. Is it too late?

No. It is slower and more expensive than learning from the expert, but the business logic can be recovered from the code, the database and the people who use the system. We do this regularly.

Can you document our system without migrating it?

Yes. Business analysts and Delphi developers work through the system with your users. The result is a written description of the business logic and a characterisation test suite that guards it.

Will our Delphi developers lose their jobs in a migration?

They should not. Their knowledge of the business rules is what makes the migration safe, and many learn the new stack along the way.

Worried about who knows your Delphi system? Talk to an engineer about a technical audit, or see how our re-engineering practice works.

Sources

Checked 1 October 2026.

• Stack Overflow, Developer Survey 2025, and its public dataset (Open Database License 1.0). Age, experience, retirement and confidence-interval figures are PannonRex’s own analysis of that dataset, reproducible with model/age_analysis.py.
• StepStone.de salary pages for Delphi, C# and Java developers, September–October 2026
• TIOBE Index, September 2026; PYPL
• Embarcadero, About us (“more than three million users”)
• Michael Feathers, Working Effectively with Legacy Code, Prentice Hall, 2004