How to handle distinct environment and handle base migrations?

The AT connector from Openside.com is probably your best bet.

Thanks, I quickly looked into it and I believe it’s too expensive and I also don’t see how it can help with my specific need.

Maybe it’s a viable solution for someone who already has an existing AirTable usage, but for me starting from scratch, I feel like a standard database is safer.
But I’m glad to be proved wrong! :winking_face:

Right now, the only solution I know of is through manual migration.

I create a grid view in each table of the original base ---- before making modifications — that moves all of the data fields to the right-hand side of the grid. (That is, all calculated or derived fields come first, followed by linked-record fields, followed by data fields.) While the original base remains live, I make whatever modifications are needed and allow the users to test. Once everything is ready to go, I make sure no one is using the base (I typically handle this by informing everyone, but depending on the sharing mechanism used, I guess one could move it to a different workspace) and then manually sync it.

To do so, I duplicate my development base, but I do so without duplicating records. I open the original base in one screen and the empty updated one in another. I then go through the base, table by table, using my <Update> grid view. Any newly defined data fields I place after the calculated fields but before the linked records; any deleted fields I move to the left-hand side of the grid and append ‘KILL -’ to the field name. (On occasion, I will have created a new data field that contains elements of two or more fields from the old base that users will now enter in a single field. If that’s the case, I’ll create a formula field in the original base that constructs the new field entry and then reconfigure the field to the new data type; such fields are moved immediately before the linked-records fields.) Usually, changes to field name or data type don’t require special handling.

Once the field layouts are the same — field names and, to an extent, configurations don’t matter, as long as they are in the same sequence in my <Update> view — I mark-and-copy all of the data and linked-record fields from the original base and paste them into the updated version.¹ I do this for each table. With luck, once I’m done the new base will be working correctly with up-to-date data, and the users can be directed to use it.

It’s also possible to go through the export/import cycle to move tables, but I’ve always found the copy/paste method to be faster and as reliable.

Admittedly not a perfect solution ---- but a much more viable approach than you might think at first glance.

1. Select cell corresponding to first data/linked-record field in Row 1 of the original (live) base; scroll to end of base and, **while holding down the Shift key, select the cell corresponding to the right-most data field of the final record of the table; press Ctrl-C to copy all values; move to the updated table; select the cell corresponding to the first data/linked-record field in Row 1 of the new base; and press Ctrl-V to paste the values.