Replace Borland BDE with FireDAC: Trade-off map for a secure migration

Monday morning, 08:15. A freshly rolled-out Windows update, a new endpoint protection, plus a “small” package from software distribution — and suddenly a site is at a standstill. A business-critical Delphi application launches, but on the first data access it reports “Alias not found” or “Network path invalid.” The ticket history surfaces terms that in many IT teams no longer have a fixed place: BDE administrator, NetDir, local configuration files that live “somewhere” and behave “somehow.”

Those who want to replace Borland BDE with a BDE replacement with native connectivity usually do not face the luxury problem “we modernize for fun,” but a real conflict of objectives. Objective 1: maximum stability in daily operations, no surprises in posting runs, reports or interfaces. Objective 2: lift the application out of the legacy special case — away from fragile client configuration toward a data access approach that fits 64‑bit, Unicode, security baselines and a coherent database strategy. This decision map assesses benefits, effort, risks and limits and shows for whom which choice is plausible.

Conflict of objectives as a starting point: remain stable or buy the future?

Goal A: Stability, because the process depends on it

Many BDE-based applications are operationally settled. Support knows the idiosyncrasies, business units are accustomed to specific form workflows and lists, and even rough edges are accounted for. That is precisely why a change in data access is risky: errors often do not appear as a crash but as subtle deviations — a different sort order, a different rounding, a different handling of NULL values, an unexpectedly long lock. For IT leadership and operations this means: migration is only justifiable if result equivalence and rollback are realistically secured.

Goal B: Future viability, because operations and platform do not stand still

At the same time, the Borland Database Engine (BDE) is not merely “old” but officially deprecated. Embarcadero explicitly points out that the BDE will no longer be developed and, for example, will never receive Unicode support; migration to BDE-Ablosung mit nativer Anbindung is recommended for existing applications.^[Source] Practical consequence: the more consistently you harden clients, distribute software, restrict rights and standardize platforms, the less appropriate a data access method is that depends on historical global settings and an outdated driver ecosystem. This affects not only “IT aesthetics” but incident risk and operational predictability.

What really changes when you replace Borland BDE with FireDAC

In many project plans the implicit roadmap reads: TDatabase becomes TFDConnection, TQuery becomes TFDQuery, TTable becomes TFDTable. That is the visible part. The relevant part lies underneath: the BDE has carried implicit assumptions for years (conversions, default sort orders, transaction side effects, configuration locations). FireDAC is generally stricter, more transparent and closer to the underlying database. That improves maintainability and diagnostics — but forces you to document and test assumptions.

Four differences that affect day-to-day operations and the business unit

• Configuration and deployment: BDE setups historically rely on global alias/NetDir configurations and files that can vary per machine or per profile. FireDAC can be configured close to the connection and controlled per environment, but depending on the database it requires appropriate client libraries and a clear update and distribution strategy.
• Data types, parameters, implicit conversion: FireDAC is often more precise. SQL that „accidentally“ worked (date as string, number as text) is more likely to surface. That is good — provided you see the errors in tests, not during month-end closing.
• Unicode and collation (sorting/character set rules): If the application historically uses ANSI logic, modernization can expose character and comparison issues: sorting, case sensitivity, umlauts, export formats. This is solvable, but not automatically „identical“.
• Transactions and locking behavior: Many legacy patterns rely on dataset-driven side effects. FireDAC offers clean transaction control — but requires you to define where transactions begin and end.

Trade-off map: benefits, effort, risks and limits

When migration is particularly advisable

When deployment and security hardening regularly collide

The more standardized your client landscape is (software distribution, restricted permissions, segmented networks, endpoint protection), the more noticeable everything becomes that is configured „per machine“ or „per user profile“ and can only be repaired in case of failure by manual reproduction. FireDAC does not automatically force you into a good configuration model, but it suits an approach where connection parameters are defined, versioned and documented per environment.

When 64‑bit planning or new hardware is planned

Many companies do not change because of an IDE version, but because terminal servers are renewed, new OS releases arrive, or security policies are tightened. Data access then becomes a hard dependency. Modernizing it decouples follow-up projects: the next platform or infrastructure initiative does not have to simultaneously solve the data access problem.

When data storage is to become „mature“ anyway

In file-based scenarios (classic Paradox/dBase) the biggest risk is rarely the UI. It is locking, backup reality, data integrity, permissions and multi-user operation. FireDAC is primarily designed for SQL databases and clear transaction models. If a server-based database strategy is already on the table, the BDE-Ablösung is often the time to plan both together – with all consequences for operations (backups, monitoring, maintenance windows, role/permission model).

Three migration paths – with very different risk profiles

Path 1: Mechanical „recompile“ (only as an interim objective)

Embarcadero describes a typical FireDAC migration in the Upgrade/Migration Center as a multi-stage process and also mentions „reFind“ as a tool that helps with the mechanical part: replacing components, updating uses clauses, making basic changes to be able to compile again.^[Source] As an interim state this is useful. As a final state it is insufficient, because compiling says nothing about functional equivalence, performance under load or concurrency.

Path 2: Encapsulate data access, then switch (often the best compromise)

Instead of rebuilding each form directly, pull data access into a few responsible locations: connection creation, central error handling, logging/tracing, enforced parameter and transaction rules. Then migrate module by module. That reduces the migration surface and makes acceptance and operations more predictable, because behavior can be observed and corrected in a single place.

Path 3: FireDAC + database change (high benefit, but higher governance)

If a move from file-based to server-based is already planned, it can be efficient to combine both. The gain is significant (transactions, permissions, monitoring, improved operations processes). The price is that you are deciding more than „technology“: data migration, schema design, cutover, parallel operation, rollback strategy. Without a clear acceptance format and operational agreements, this path quickly turns into an ongoing project.

A practical workflow in 7 steps (without Big Bang)

1. Inventory as a risk map: Which data sources, which access types (TTable-centric vs. SQL), which critical reports, which batch jobs, which import/export interfaces are tied to the dataset’s behavior?
2. Decide target mode: „FireDAC on the same database“ or „FireDAC plus database modernization.“ This is a portfolio and operations decision, not a pure developer question.
3. Define foundation: Central connection configuration, timeouts, error handling, optionally switchable tracing/logging. Goal: reproducible in Dev/Test/Prod.
4. Choose pilot process: Not the smallest form, but a functionally well-defined process with read and write (transactions, locks, validation) and clear acceptance criteria.
5. Prove result equivalence: Compare result sets, reports and key metrics on defined test data. Focus: NULL, date logic, rounding, character set, sorting.
6. Migration in waves: By modules/use cases, with a release ring (pilot group, support window, rollback package, communication). Parallel operation is allowed, but must be technically cleanly separated.
7. Decommission BDE in deployment: Remove installer, documentation, configuration remnants. As long as BDE remains installed „just in case“, part of the operational risk persists.

Typical risk zones – and how to manage them administratively

1) Data types, NULL and „historical“ conversions

Many mature Delphi applications contain edge cases that no one has touched for a long time: empty strings instead of NULL, numbers in text fields, dates as strings, „0“ as False. FireDAC does not automatically break those places, but it makes them more visible. For operations and the business unit this is an advantage, because errors become more reproducible — provided you define rules: Which columns may be NULL? Which default values apply from a business perspective? How are booleans stored? Which time resolution is relevant (date vs. timestamp)?

2) Transactions, Locks and Concurrency

In BDE legacy structures transactions often arise „incidentally“: open the dataset, the user clicks, at some point the record is posted. On server-based databases this can lead to long transactions and unnecessary locks. In an FireDAC migration a simple guiding principle pays off: transactions should be scoped to the use case, not to the UI. That can mean bundling save operations, moving validations earlier and centralizing error handling.

3) SQL dialect, reserved words, deterministic ordering

Part of the work is not „FireDAC“ but SQL hygiene. BDE historically tolerated many things: ambiguous alias names, implicit joins, non-deterministic ordering. FireDAC is not the enemy here but the amplifier: problems become visible. The robust solution is almost always to make SQL explicit. This also helps administrators, because queries become easier to analyze (index requirements, execution plans, load tests).

4) Reporting, exports, audit-relevant analyses

When reports are used for month-end closing, billing or audit-relevant analyses, „silent“ deviations are the real risk. Treat critical reports like standalone product components: defined test data, expected totals/row counts, documented filter logic, acceptance by the business unit. Where possible, stabilize the data layer (e.g. via clearly defined queries or views) instead of accepting UI-side filter chains as the source of truth.

Architectural consequences: What FireDAC enables — and what does not automatically appear

Good foundation for services, jobs and interfaces

Many companies extend desktop systems with REST services, background processing or portals. Modern data access fits this when connection lifecycle, error handling and transactions are cleanly encapsulated. Without that encapsulation you only get „a new driver in an old structure“ — and every follow-up project will build its own rules again.

FireDAC does not replace decoupling of UI and business logic

If forms currently assemble SQL, business rules live in event handlers and global state dominates, that will initially remain after the migration. FireDAC is not an architectural measure, but a good occasion to introduce a minimal structure: central connection management, a small number of access classes per functional module, defined error and transaction rules. That is often enough to make maintenance and operations noticeably more predictable.

Limits and special cases you should address openly early

Systems heavily driven by TTable/Paradox

If the existing estate is heavily file-based, the real question is not „BDE or FireDAC“, but „which data storage model“. FireDAC is not intended to preserve a file-based world unchanged. Anyone who must modernize Paradox data should plan the effort for data migration, schema design, permissions, backup/RESTore testing and cutover carefully — including parallel operation and data reconciliation when a hard cut is not acceptable from a business perspective.

Parallel operation is a tool, not an end state

Yes, BDE and FireDAC can run in parallel. The price is complexity: duplicated configuration, duplicated failure modes, more dependencies. Therefore set an end date for the BDE decommission early and define the separation line (modules, use cases, technical layers). A half-and-half approach without a target will usually be costlier in operation than a determined staged refactor.

Decisions IT leadership and operations should lock down early

• Environment strategy: How do you manage Dev/Test/Prod configurations? Who is allowed to change connection parameters? How do you handle secrets?
• Driver and update policy: How are client libraries versioned and distributed? Are there release rings and a rollback option?
• Observability: Which logs does operations need during an incident? Which SQL contexts may be logged for data protection or security classification reasons?
• Acceptance format: Which core processes must be represented as regression tests (lists, bookings, exports, reports)?
• Rollback plan: What is the fallback strategy per wave — technical (packages), organizational (communication) and data-related (no data loss)?

The lever that determines success: trust through demonstration

Most migrations do not fail at the „connection“, but at trust. Trust is created when you can demonstrate that critical processes remain functionally identical — or when deviations are consciously decided and clearly communicated. That is exactly the opportunity of the migration: it forces explicit rules (sorting, data types, transactions) and thereby creates a basis that will still be maintainable and operable in two years. FireDAC then becomes not the goal but the means to bring operation and further development back into a predictable normal state.

If you want to prepare the replacement in a structured way (risk map, pilot, test and rollout plan), you can kick off the initiative cleanly here: discuss project or modernization initiative with Net-Base.

For this topic, Delphi Modernization and FireDAC Migration are also relevant. The article places these aspects into context and shows what matters in everyday practice.

Discuss a project or modernization initiative with Net-Base.