Delphi Migration Pitfalls and How to Avoid Them

[Serge Pilko 16]

After working with millions of lines of Delphi code, the same migration issues keep showing up: broken DevExpress styles, kbmMemTable links and legacy components with no 64-bit support. For example, outdated components. 

 

Delphi has thousands of third-party components, but not all are maintained, which might also cause a problem with licensing. 

 

The deeper third-party components are embedded into the project, the higher the chance you will face compilation errors or unexpected behavior during migration. The most common issues include:

• Changes in internal component logic or behavior, including fixes or removed legacy features.
• Compilation breaks due to new packages, modules, data types, constants, procedures or conditional compilation symbols introduced in newer versions. 

 

These issues often surface in subtle ways, and the more your app relies on these components, the more time and care will be required to resolve them during migration. Typical problems include: 

• Unicode conflicts. Legacy components often don't support Unicode, leading to corrupted text or broken logic.
• Removed or deleted components. For example, instead of TDBExpress, there is TFDConnection. In this situation, it is better to switch to new components, from DBExpress to FireDAC or UniDAC. You can also use conditional directives ({$IFDEF}) to support both old and new Delphi versions in the same codebase.
• No 64-bit support in older versions of Delphi. You need to update the calling of APIs.
• Third-party components. Many old components are not compatible with newer versions of Delphi. 

 

One of the solutions is to update all the components to a newer Delphi version and adapt the usage of components in the newer version. Possible alternatives:

• TeeChart -> TAChart, FMXGraphics, HighResChart
• kbmMemTable -> FireDAC.TFDMemTable, DevExpress.TdxMemData
• DevExpress -> TMS, LMD

 

If anyone here has gone through a large-scale migration, I'd be curious what was the hardest part for you or your team? Components, business logic, integrations?

 

We have also summarized a few other pitfalls (integration issues, hidden time traps, etc.) in a longer guide. If that is useful, it is available here: https://www.softacom.com/blog/delphi-migration-pitfalls-what-we-learned-after-working-with-125m-lines-of-code/   

[Anders Melander 2203]

TL;DR: Send us your email address so we can try to sell you our services.

 

Am I wrong?

[DelphiUdIT 275]

Over the years, we've all had more or less the same problems, although Delphi certainly has fewer issues than other competing languages.
I port all "maintained" projects—those that customers pay for maintenance—and active ones to the latest version of Delphi/Rad Studio.
And I always have a single version (the latest) of Rad Studio in production.
My porting efforts are primarily prevention:

• I only use third-party products with source code;
• I don't use the latest developments without thoroughly testing them;
• I comment on the source code with a lot of information, perhaps too much;
• I try not to use anything labeled "deprecated" or "obsolete";
• I try to use proven technologies that I know work;
• Once a new technology is established and working, I gradually update my code (both old and new) so as not to be left behind in upcoming releases.

I certainly don't have any problems with staff leaving: I don't have any. I have collaborators, but they always send me the source code, which I then verify and recompile myself (not just in Delphi).

 

With these precautions, I've never had any major migration problems.

 

N.B.: This doesn't just apply to Delphi, but also to other libraries (more expensive than Rad Studio) that generally require much more effort to update.

 

1 hour ago, Serge Pilko said:

If anyone here has gone through a large-scale migration, I'd be curious what was the hardest part for you or your team? Components, business logic, integrations?

Integration is certainly the most important part, but not for Delphi-related updates.
Then come the components (especially the graphical ones), which can cause some problems if updated.
Business logic has never been a problem.

[Lars Fosdal 1987]

17 hours ago, Anders Melander said:

TL;DR: Send us your email address so we can try to sell you our services.

 

Am I wrong?

I agree. The account email displays a different name than the forum nickname. The account never comments on posts. And, the referred posts all highlight the services that the company provides.
A different account, which is blocked, suggested the following:


Should we keep blocking accounts that post infomercials without interacting with the forum members?

[DelphiUdIT 275]

The posts don't appear aggressive, and the topic is interesting. It's obvious that, referring to a company, the purpose is subtly commercial.
Furthermore, the link makes a clear request: it's not in any way blatantly disguised.
If the forum administrators deem it appropriate, the link could be removed (as is standard practice), given that the topic hasn't been posted on the dedicated announcements page.
Adding a note such as "link removed due to violation of terms" might be a good indication.

 

But be careful, as many other posts contain references to commercial sites as a guide for users... you need to think carefully and act transparently.

[Anders Melander 2203]

I actually don't mind on-topic advertisements that much. After all, it's no different than 3rd party vendors announcing their libraries and not really participating beyond that. We got a couple of those already *cough* TMS *cough*.

 

What I do mind is the dishonesty of pretending to discuss a topic but actually only drive traffic to their site in order to harvest leads. It's trolling.

 

I agree that the topic was interesting, and I actually started to write a reply describing our own experiences and solutions, but then I noticed that neither the post nor the page that it links to actually contain any useful information; It's just a long collection of keywords and the whole message can be accurately summarized as "updating code can be problematic". It doesn't contain any actual solutions and some of the things that it says are just plain nonsense.

The other "articles" posted here and on their site are just more of the same: Here are some words, and now enter your name and email to get access to an article with more information on this topic that we just failed to say anything useful about.

 

2 hours ago, Lars Fosdal said:

different account, which is blocked, suggested the following:

Wow! F*ck 'em.

 

2 hours ago, Lars Fosdal said:

Should we keep blocking accounts that post infomercials without interacting with the forum members?

I think we should. We don't allow spam and this is spam - even if it pretends to be something else.

[DelphiUdIT 275]

@Anders Melander

Your analysis is certainly more in-depth than mine, I agree with your assessments.

[PeaShooter_OMO 53]

4 hours ago, Lars Fosdal said:

Should we keep blocking accounts that post infomercials without interacting with the forum members?

I do not think so. I would rather have them post to a Forum Category of their own. Maybe another one under Third-Party. As long as they stick to the Delphi/C++Builder ecosystem it should be allowed on that Forum.

It can be a good place for companies/individuals to post their DelphiC++Builder related products. Who knows, each post might turn into a solid discussion. I do not see @Serge Pilko post much after each "advertisement" and maybe if he has a place to advertise then he might engage more with those who ask questions. Who knows.

I use the "Unread Content" links to see any new post an all forums and I already filter out what I am not interested in by skimming the subjects of each. Having an "advertisement" on that Forum Category pop up amongst new Unread Content will not bug me at all.

But again; the moderators will know better than me what the intricacies of this community is.

Edited October 9 by PeaShooter_OMO

[Lars Fosdal 1987]

Personally, I'd like to simply put the account on my ignore list, but being an admin, I can't really do that since I feel obliged to comb through the posts.

[Anders Melander 2203]

The problem with sub-forums is that the most active people here doesn't really use them (is my impression, at least); They use the flat view where all posts are visible, ordered by activity date.

And the ignore functionality of the forum doesn't work that well. Even if you ignore a user or a topic, you still get to see the topics and that they post. Unfortunately it's apparently beyond the Invision Community (the forum software) developers to implement a property ignore/mute/block function. It's been requested for ages.

 

Usenet worked so much better.

[Sherlock 693]

1 hour ago, Anders Melander said:

Usenet worked so much better.

🎵Those where the days, my friend, we thought they'd never end....🎶

[Serge Pilko 16]

I appreciate everyone’s feedback. We just wanted to share some of the technical materials our developers have created based on real projects. We post those guides as detailed PDFs, and the file is automatically sent to the email after the request. That is the delivery method.

[Lars Fosdal 1987]

On 10/14/2025 at 9:58 AM, Serge Pilko said:

I appreciate everyone’s feedback. We just wanted to share some of the technical materials our developers have created based on real projects. We post those guides as detailed PDFs, and the file is automatically sent to the email after the request. That is the delivery method.

My question is why that email is necessary at all.

[Anders Melander 2203]

8 hours ago, Lars Fosdal said:

We just wanted to share some of the technical materials our developers have created based on real projects.

That's nice and if you had posted the actual article, either here or in Third Party, with a link back to your site, I don't think anyone would have raised an eyebrow.

 

But you didn't; You posted a useless word salad comprised of a bunch of keywords with a link to the same useless word salad on your site and a hook to capture the contact info. Like many of the other posts you've made here.

[Lars Fosdal 1987]

Ahem - Mr. Pilko said what you quoted, @Anders Melander, not me.

[Anders Melander 2203]

1 hour ago, Lars Fosdal said:

not me.

Heh. Forum glitch.

 

[Sherlock 693]

OK, let's not get too picky here. Embarcadero does the same thing. Want some "free" stuff? Let's see a mail address.

[Anders Melander 2203]

1 hour ago, Sherlock said:

Embarcadero does the same thing. Want some "free" stuff? Let's see a mail address

What they do on their own site is their business.

 

If they did it here it would become our business.

[Kim Madsen 5]

I wonder why you would change kbmMemTable to something else?
kbmMemTable has been and is maintained since its first release in 2000, constantly gaining new features and improvements.

Its supported on all platforms supported by Delphi and is 100% native Delphi code, which is included with the component.

[corneliusdavid 292]

4 hours ago, Kim Madsen said:

I wonder why you would change kbmMemTable to something else?

If switching to FD, less reliance on 3rd-party components. But switching to TdxMemData? Perhaps native support for other DevEx components? That doesn't seem like a compelling reason as I'm sure kbm is compatible.

[Anders Melander 2203]

9 hours ago, Kim Madsen said:

I wonder why you would change kbmMemTable to something else?

They are just using the various library and component names as keywords for search bots and to lure in clueless customers. Don't try to make sense of it.

 

5 hours ago, corneliusdavid said:

TdxMemData? Perhaps native support for other DevEx components?

There's nothing in TdxMemData that TFDMemTable doesn't do better. TdxMemData is a leftover from the time before we had TFDMemTable.

[Serge Pilko 16]

On 10/23/2025 at 12:49 PM, Kim Madsen said:

I wonder why you would change kbmMemTable to something else?
kbmMemTable has been and is maintained since its first release in 2000, constantly gaining new features and improvements.

Its supported on all platforms supported by Delphi and is 100% native Delphi code, which is included with the component.

Thank you for your feedback and for taking the time to read our article. I would like to clarify right away that the original intent of the material was not to criticize any particular component.
Our goal was to describe the real challenges we encountered when migrating projects from older Delphi versions to newer ones.
That said, after rereading the article, we realized that some parts of the text might have created the impression that we were criticizing certain components or suggesting replacing them, which, of course, was not our intention.
Our team has already made some edits to remove any wording that could be interpreted ambiguously.

We apologize for the misunderstanding and truly appreciate your response. It helped us look at the material from a different perspective and make it more accurate.

[Lars Fosdal 1987]

That response looks like an AI constructed apology.

 

Edit: I had to check 😄

 

Edited November 7 by Lars Fosdal
ran the text through an analyzer

[Attila Kovacs 695]

Phew, that took a few tries.

 

 

 

[aehimself 435]

People 50 years ago:

50 years from now, there will be flying cars!

 

Now:

"I used AI to detect if you used AI"

 

What a world we live in :D