This article provides a tutorial showing how to migrate a simple client-server application using BDE data access components, like TDatabase, TQuery, TTable to the AnyDAC. It shows the basic principles of replacing the common components, properties and code, preserving the developers working time and avoiding the common migration pitfalls. 

In general, the AnyDAC components have a high compatibility level with the BDE data access components. This includes the syntax and semantic of the properties and methods in the AnyDAC and BDE. But some parts are different:

• BDE and AnyDAC have components with different names. E.g. BDE - TQuery, AnyDAC - TADQuery.
• BDE and AnyDAC have different alias/connection definition systems. BDE stores aliases in the binary system wide file IDAPI.CFG; the AnyDAC stores the connection definitions in the ADConnectionDefs.ini file.
• Some parameters for BDE SQLLink's and AnyDAC drivers are different.
• BDE and AnyDAC may have the different data type mapping for the same RDBMS. AnyDAC follows more close to the dbExpress data type mapping. However the AnyDAC has powerful capabilities to adjust the data type mapping.
• The base API's (the BDE API and the Phys interface) are absolutely incompatible. If you have some code which directly uses the BDE API, it has to be be recoded.
• BDE and AnyDAC have different heterogenous query syntax and capabilities. AnyDAC offers Local SQL feature.

That is nearly all of what should be changed at migration from BDE to AnyDAC. After the migration (or in parallel with it), you should consider to review your application for:

• using the extended AnyDAC functionality to simplify your application;
• using the extended AnyDAC functionality to extend the functionality of your application;
• using the AnyDAC options to fine tune your application and speed it up.