How to move your app to a new provider
In some cases, app creators would like to migrate their apps from one data provider to another due to changes in their needs or to take advantage of provider-specific features. If this happens after the app creator has already invested significant time and effort into building the app, it is necessary to move the app in such a way so as to preserve as much of the work that has been done as possible.
To accomplish this, you can use AppSheet's ability to clone apps across data providers. First, create a new AppSheet account associated with the new data provider of your choice. Once the new account has been created, log back into your current account, go to the "Manage" section of your existing app, and add your new account as a collaborator. This will make your app visible to your new account, which will allow you to clone the app to the new provider. The copied app will be identical to your original app, and will use your new data provider as its data source. All of the spreadsheets in the original app will also be copied into your new data provider.
It is important to note that this method does not work if you want to move your app to a database provider such as MySQL or SQLServer. This is because AppSheet currently cannot create new tables in users' databases and thus is unable to copy apps into database providers.
Ensure that your app works with the new provider
Due to differences between data providers, moving your app from one data provider to another can result in unanticipated issues. As a result, we highly recommend that you test and troubleshoot your new app before deploying, even if your original app has already passed the deployment check. A good practice is to ALWAYS keep your original app as a backup in case your app does not work well with the new data provider.
One common problem arises when the original app uses provider-specific features, such as scripts in Google Sheet or sheet formulas that are only recognized by a certain provider. In this case, the provider-specific features will not be copied over to the new provider along with your app. To solve this problem, we recommend that even before you move your app, make a list of all provider-specific features currently used by your app and find out if you can find equivalent features in the new data provider. If no equivalent feature can be found, make sure that you can implement workarounds that will ensure that the app's behaviors will not change substantially before moving your app. Once you have moved your app, ensure that you first re-implement all missing features and workarounds that have not been copied over so that your new app is functionally equivalent to the original app before attempting to add more features.
Another common problem arises if expressions in your app, or if your app users, rely on the folder systems of the original data provider. For example, expressions in your app might check if the folder paths of files/images match a certain pattern, or your app users might rely on the folder structure and naming convention in the original data provider to locate files. If this is the case, you will need to modify your app expressions accordingly and inform your app users of any differences in the folder systems of the data providers.
One last consideration is app performance. Different data providers can affect the performance of your app differently. For instance, certain data providers are subject to more frequent outages and longer down time. Also, different data providers can take longer or shorter to perform table operations, which will lead to changes in the sync time of your app. As a result, it is a good practice to closely monitor the performance of your app right after moving it to a new provider so that you can find and solve performance-related problems early.