Map what the BDE actually does
- Inventory aliases, drivers, NET DIR, private directories and session configuration.
- Identify Paradox/dBase tables, SQL backends and mixed local/remote workflows.
- Trace TTable/TQuery usage, cached updates, filters, calculated fields and transactions.
- Record locking, autoincrement, null, date, memo and case-sensitivity behavior.
- Locate reports or utilities that access the same tables outside the main program.
Migration choices
| Path | When it fits | Risk |
|---|---|---|
| Preserve BDE temporarily | Application is stable and operational isolation is acceptable | Deployment and support risk remain |
| Replace data-access layer | Source builds and database behavior can be tested | Dataset semantics and UI coupling may surface widely |
| Migrate data to SQL | Concurrency, scale or platform support requires a new backend | Types, indexes and business rules need explicit translation |
| Replace application incrementally | Build or component constraints make direct refactoring unsafe | Parallel behavior and synchronization must be controlled |
Validate behavior, not only records
Compare record counts and totals, then test lookup order, edits, concurrent users, failed transactions, reports and exceptional data. Preserve a rollback copy and avoid migrating live local tables while users write to them.
The data-centered process is covered in BDE database migration. Use Delphi support when continuity comes first and Delphi reverse engineering when source or behavior is incomplete. The database pillar covers recovery boundaries.
Provide
Delphi source/build status, BDE configuration, complete table sets, active aliases, concurrent-user requirements and representative workflows.