Hi - our Airtable-based content planning system over the past 2 years has grown very rapidly and organically, and this has resulted in a bit of an imbroglio. We’ve decided to trim the system in terms of tables, views, fields, and labels,… and also to review user permissions which are now all given at Workspace-level whereas for many collaborators they should be defined at Base-level.
A question that came up is whether the best change strategy is either to evolve/adapt the existing Bases and Tables or, alternatively, to set up in parallel new Bases and Tables and then, at an agreed moment, replace the old wit the new.
Do you have thoughts / experience to share with us? Thx!
It’s really a case by case situation.
If I can phase in changes with existing bases/tables, I usually do that. However, sometimes schema changes are so radically different that it is best to start from scratch and migrate data.
I often build a proof-of-concept in a different base/table and do a demo to get buy-in before making changes in an existing base/table.
Also keep in mind that building a new system is only part of the process. Migrating data and training are also important parts of the process.
2 Likes
Welcome to the community, @guyvanpeel!
As @Kuovonne mentioned, I would typically recommend trying to make the changes in your existing bases & tables, if at all possible.
One big downside to switching to completely different bases is that you’ll get completely different base IDs, table IDs, and record IDs… which will cause problems with any external automations or apps that you have previously setup to communicate with your existing bases.