Help

Re: How to handle distinct environment and handle base migrations?

1631 2
cancel
Showing results for 
Search instead for 
Did you mean: 
Ambroise_Dhenai
8 - Airtable Astronomer
8 - Airtable Astronomer

I’m wondering how people handle several environments, for instance “production” and “staging” (AKA test/pre-prod)

My first thought was to use 2 different bases, one for production and one for staging.
This way, I can change my staging base/tables/fields structure without affecting end-users, try things out, develop new features, etc.

But how can I sync both once that’s done? Assuming I renamed an existing field, added new fields, deleted some, etc. How do I update the production base accordingly? Or, put differently, how do I run a base migration?

Doing it by hand is just impossible. Untestable, unreliable. Also, it’ll bring the product down while doing the manual operation, which is a no-go.

Duplicating the existing staging base and move the production base’s data into this new base doesn’t seem reliable either if fields have been renamed, or configured differently, removed, etc.

At this time, I don’t see a proper solution. AirTable doesn’t provide a Base Migration feature as far as I can tell, and this is my biggest unknown/worries about switching my app database to AirTable.

But maybe there are solutions out there that I don’t know about? :slightly_smiling_face:

3 Replies 3
Mac
8 - Airtable Astronomer
8 - Airtable Astronomer

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.