Deploy FileMaker updates without migrating data by hand.

360Deploy automates the deployment of FileMaker databases from a Development to Production environment. It will handle getting copies of your Dev files, uploading them to the Prod server, importing all the data from the Prod file into the Dev file, then hosting the newly populated Dev file in the place where the Prod file was. With the click of a button, this allows you to merge the schema changes (new layouts, scripts, tables, and security) from your Dev file, and the data from your Prod file. So you can get the new features you have been developing, along with the data your users have been entering all merged together.

Altering live databases is risky. It is possible to lock tables, causing a pile up on the server, and potentially causing corruption. It is far safer to do your development in a separate, Development copy of your database. However, if you do development in a separate copy, your users will be entering data into the live, Production copy of the database. Now you have a problem—your new features are in one file, but all the data is in a different file. This is where 360Deploy comes in. It is purpose-built to merge the development changes from a Dev file with the data from a Prod file, and handle the uploading, merging, and hosting of the newly populated Dev file. Automating this process with 360Deploy also greatly reduces the chance for error during this process, as it is very tedious to do manually.

Review the licensing types outlined here

In short, the solution is to use Dynamic Data Sources to control which version of the file (Dev or Prod) uses which External Data Sources (Dev External Data Sources or Prod External Data Sources). There is a longer writeup in our docs with examples on how to do this here: 360Deploy - External Data Sources

The script that executes the entire deployment is called: "Upload Files and Start Migration ( $~configuration_id )". This script is server-side compatible, and you can specify this script in a server-side schedule in the FileMaker Server Admin Console. We recommend this approach for scheduling deployments because of the reliability you get with server-side schedules. Read more about this approach here: 360Deploy - Scheduling After-Hour Imports

Yes, archived Prod files are stored on the Prod server. You can find them in timestamped folders at the locations listed here

Although accounts are part of the schema which normally comes from the Dev file during deployment, accounts actually come from the Prod file during a deployment and are imported into the Dev file. This is the preferred way to handle this since users have been logging into the Prod file previously, and we still want their accounts to work. Therefore, if you have a new user, you need to add their account to the Prod file. Then, the next time you run a deployment, that account will get merged into the Dev file before it is hosted. All users who could log into the Prod file before a deployment, will still be able to log into the Prod file after the deployment.

Renaming or adding fields in the development database will work fine during the import. If you add fields in your development copy, be aware that this field will be empty after you migrate these changes to the production server, as there will be no data on the production server to populate it. Deleting fields will work as expected—the field will be removed from the production copy.

360Deploy uses the FMDataMigration tool, which will match up tables by id and name first, if no match then by name alone, then by id alone. Renaming tables will work fine as long as a new table is not created using the renamed table's previous name.