The question of how to migrate your C/AL modifications to extensions has been well answered several times, not least of all by Microsoft’s own documentation of the Txt2AL tool.
However, if you want to migrate an existing solution from C/AL to an AL extension and keep your data, it’s less clear how this should be achieved.

The answer is surprisingly easy, all we must do is look to processes and methods already used by MS themselves, that many of us are already familiar with.
In short, we can replicate the same process used for upgrades, migrate the data to upgrade tables, then process it into our extension tables, performing any transformation required along the way.

With a shift of perspective and an examination of the problem, the solution starts to seem a lot simpler.
We simply need to move data from one table to another.

The first, and most definite, complication is that the two objects we need to transfer between live in separate development environments.
This is solved by ensuring our symbols are generated for the table we’re moving from. Once this is done, and the symbols downloaded to our AL project (see here) and then refer to our C/AL table in our extension and run a basic data transfer process.

The second complication is that the two objects may have the same object IDs, so cannot exist in the tenant together at the same time. Again, there is a simple solution for this: we move our data to a temporary object range. The table sync that occurs when a table is compiled or removed already gives us a mechanism for this (see here). We simply create an upgrade table to hold our data, create an upgrade CU to handle the transfer of data to the upgrade table, then simply delete the original C/AL objects, let the table sync run, and then refer to the upgrade tables from your extension (don’t forget to update those symbols to include the upgrade table!)

I do have one small problem with doing the migration in my primary extension however.
As a conscientious developer it’s quite likely that I’ve done my best to develop this extension in a crisp, clean, cronus environment. In order to perform the data migration within this extension I must now add AL objects and symbols for C/AL objects which I only need temporarily – I would then need to remove and up-version my extension once I’m complete, in order to leave it clean and referencing the proper C/AL symbols, and to not be wasting some of that precious licence range.
This would be even more untenable if I were developing a product for consumption by other partners.

Therefore, I recommend handling the migration using a secondary, temporary extension which can be removed after, without affecting my primary extension.

Creating the secondary extension with a dependency on the first will allow for this secondary extension to utilise our new AL table from the primary extension, and we then only need to load our modified upgrade object symbols to the secondary extension.
We can then process the data from C/AL upgrade table to our AL table
within this migration extension; this could be via an install codeunit or through some other process you choose to run manually such as a processing report.

Once this is done, you can remove your upgrade table, remove your migration extension and you have a shiny, new extension with all of your old data, ready to rock.