The architecture of an AL-based system is different from one based on CAL. When a base table is modified in CAL, the new field is created directly in the corresponding SQL table. In AL, that new field is added to a companion SQL table that is related to the original table. When creating tables, instead of the table being alongside the base ones (like in the CAL environment), new AL tables are stored within specially named tables that are directly associated with the application that created them. As a result, existing data in both new tables and new fields needs to be moved when converting from CAL to AL.

The easiest way to move the data is to allow both the CAL and AL modifications to exist in the system at the same time. For this to happen, the object names and numbering needs to be different between the CAL and AL solutions.

As a recommendation, I would do the following:

• Rename the CAL objects and fields to a temporary name, such as by appending TMP to the end of everything. Do this in the C/SIDE environment after you have exported the objects for conversion so that your AL project will have the original names.
• After the AL files are created, renumber the table objects and table extension fields so that they do not overlap with the ones in the CAL solution. This is a far easier task to do within Visual Studio Code than it is in the C/SIDE environment.

When the AL application is installed, logic can be executed to move the data from the pre-existing CAL tables and fields into the new AL ones, while at the same time, you have the option of performing maintenance/updates to the data in order to account for any changes in the AL application.

The final step, of course, is to remove the old CAL modifications by deleting all custom tables and fields. If everything has been converted to AL, then this process just involves reverting all modified objects back to base and deleting any custom objects.