Managing 3rd Party Components in Migration

Third-party components are a massive accelerator for Delphi and C++Builder developers, extending the IDE with advanced UI grids, hardware interfaces, reporting engines, and domain-specific APIs. By leaning on the component ecosystem, you avoid reinventing the wheel and stay focused on your specific business logic.

However, during a major version upgrade, your 3rd-party components are often the largest source of friction. Incompatible DCUs, abandoned open-source projects, and breaking vendor changes require a structured approach to resolve.

Before you start

Make a single inventory of every 3rd-party package, including version numbers and where they are used.
Note whether you have full source code or only DCUs/BPLs.
Check whether each vendor is still active and which RAD Studio versions they support.

Component Migration Decision Tree

To systematically approach upgrading your component packages, follow this standard decision matrix. Do this before attempting your first full compile on the new environment.

1. Upgrade Supported Components

Before migrating your own code, audit your vendors. Many vendors provide updated components that take advantage of the latest IDE features.

Use GetIt first

Check whether your existing components are now distributed via GetIt Package Manager.
Installing via GetIt keeps libraries discoverable and simplifies updates across the team.
Always review vendor release notes for breaking changes before upgrading your projects.

2. Handling Source Code Without Vendor Updates

If you rely on an older component that is no longer commercially available, having the source code (.pas/.cpp) is your lifeline.

You will need to manually open the package in the new IDE and recompile it.
Depending on how old it is (e.g., Pre-Delphi 2009), you will need to apply manual fixes for Unicode string compatibility, PChar casting, and potentially adjust integer sizes if you are also targeting 64-bit compilation.

When you only have DCUs If you only have compiled .dcu/.bpl files for a component and no source, that component cannot be migrated to a new compiler version. DCUs are compiler-version specific and cannot be “patched” forward.

3. Replacing Dead Binary Dependencies

If you have a component where you only possess the compiled .dcu/.bpl files and the vendor is gone, you cannot migrate this component. DCUs are compiler-version specific. However, this isn't the end of the road. Your next steps are to:

Audit the RTL/VCL: Over the years, Embarcadero has integrated many features into the core VCL and RTL (for example, JSON handling, REST clients, Zip compression, advanced grids). What required a 3rd-party tool in Delphi 7 may now be native.
Find a Replacement: If it's not native, explore GetIt or the broader community for a modern equivalent and budget time to refactor those specific forms.

Stuck? Ask the Technical Pre-sales Team

Talk to a migration specialist: Auditing a massive legacy app with dozens of scattered components can be daunting. If you are struggling to map out equivalents for dead components, our technical pre-sales engineers can assist you.

They have guided thousands of customers through these scenarios and can often quickly recognize legacy libraries and recommend the cleanest upgrade path.

3rd Party Components