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 2132]

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

 

Am I wrong?

[DelphiUdIT 268]

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 1956]

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 268]

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 2132]

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 268]

@Anders Melander

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

[PeaShooter_OMO 52]

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 yesterday at 10:39 AM by PeaShooter_OMO

[Lars Fosdal 1956]

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 2132]

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 688]

1 hour ago, Anders Melander said:

Usenet worked so much better.

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