# When to adapt and when to replace a table (or Base)

**URL:** <https://air.tableforums.com/t/when-to-adapt-and-when-to-replace-a-table-or-base/722>\
**Category:** General Discussion\
**Created:** [June 30, 2023, 8:19am UTC](https://air.tableforums.com/t/when-to-adapt-and-when-to-replace-a-table-or-base/722 "2023-06-30T08:19:30Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![guyvanpeel](https://avatars.discourse-cdn.com/v4/letter/g/35a633/32.png) [@guyvanpeel](https://air.tableforums.com/u/guyvanpeel)\
**Post date:** [June 30, 2023, 8:19am UTC](https://air.tableforums.com/t/when-to-adapt-and-when-to-replace-a-table-or-base/722/1 "2023-06-30T08:19:30Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![Kuovonne](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/kuovonne/32/17_2.png) [@Kuovonne](https://air.tableforums.com/u/Kuovonne)\
**Post date:** [June 30, 2023, 2:57pm UTC](https://air.tableforums.com/t/when-to-adapt-and-when-to-replace-a-table-or-base/722/2 "2023-06-30T14:57:32Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ScottWorld](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/scottworld/32/5_2.png) [@ScottWorld](https://air.tableforums.com/u/ScottWorld)\
**Post date:** [July 2, 2023, 4:58pm UTC](https://air.tableforums.com/t/when-to-adapt-and-when-to-replace-a-table-or-base/722/3 "2023-07-02T16:58:24Z")

</div>

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.