Home/Expertise/Delphi development
Delphi / Object Pascal
Delphi applications run production and hold decades of business rules, while the market for engineers who can safely change them keeps shrinking. Delphi is our primary platform — we treat that as a specialization rather than an apology.
Scope
Rarely a greenfield project. Almost always a large, form-heavy codebase that has been extended by many hands over many years.
Desktop business applications with hundreds of forms, business logic distributed between event handlers, data modules and the database. Making a change safely means first finding where the rule actually lives.
Data access in older Delphi applications is often a mix of technologies from different eras, sometimes several in the same project. Consolidating it is one of the more reliable ways to make a Delphi codebase faster and simpler at the same time.
The reason many teams are stuck on an old Delphi version is not the compiler. It is a third-party component suite that is no longer maintained, and a build that only works on one machine.
A Delphi application does not have to stay a closed desktop system. Most of the value in modernizing one comes from letting other systems reach the logic it already contains.
The staffing problem
Delphi engineers are not scarce because the language is difficult. They are scarce because almost nobody enters the market through it any more, and the people who know it learned it on systems like yours.
And when the search fails, the fallback is usually a general developer learning the platform on your production system.
Often in one person. That is a business risk long before it is a technical one, and it is rarely on any risk register.
Reading unfamiliar Object Pascal is a week. Understanding what your application is actually deciding is the real ramp-up.
"We cannot hire for it" is a real problem, but replacing a working system is an expensive way to solve a recruitment one.
Questions
Yes, including codebases written before Unicode support arrived in the language.
Old Delphi versions are the normal condition of long-lived Delphi software, not an unusual request. A system still on an older compiler is generally a system that has been earning its keep for a long time.
Usually. The compiler itself is rarely the hard part.
The real work is third-party components that are no longer maintained, the string handling fallout from the Unicode change, and any code that assumed a specific pointer or record layout. That is scoped after looking at what the project actually depends on — an upgrade with two unmaintained component suites is a different project from one with none.
Not as a default. Delphi is not the reason most Delphi applications are hard to change — accumulated coupling is, and that is not platform-specific. Rebuilding the same structure on a newer stack reproduces the same problem with fewer people who understand it.
The staffing argument for moving is legitimate. But it is a business decision about hiring, and it deserves to be made with the real cost of a rewrite on the table rather than as a technical assumption.
Both. New features, new modules and new integrations inside an existing Delphi application are a large part of the work — usually running alongside the maintenance that keeps the same system healthy.
Next step
Tell us roughly how large it is, which Delphi version it is on, and what is currently blocked. That is enough to say something useful in the first reply.
