Split your solution into two files. File 1 holds all data-source tables and file 2 has all layouts, script etc. The Relationship graph for File 2 refers to the data tables in File 1 via external data source references. Now users can replace old copies fo File 2 with new versions and their data staysp put in File 1.
You can also write scripts that automate moving data from the old file to the new when you do have to update the data file.
So I create all of my tables in File 1. No tables in File 2. Use the Relationship graph in File 2 to display the tables in File 1 and then I can build layouts and scripts in file 2 relating to the tables in File 1. Smooth.
You will still need some "extra" relationships (besides the basics) in File 1, for relational calculations. Fortunately, because these are calculations not actual data, you can add them later.* In fact, you can add fields to File 1 later also. Because a new field does not usually have data at first, so no "import of existing data" is needed.
You should still do Phil's 2nd suggestion though, a routine to Import all tables' records into a (good) Clone (including updating the "next" serial number in every relevant table). There is one situation where an Import is critically needed. That is if the original file crashes badly. If you have access to the file, you should import all data to a clean Clone. Then you're good to go.
* If for some reason you are working on 2 separate copies of a "data" file, it is critical that the Field IDs of new fields line up. That is what FileMaker uses internally, in scripts, etc.. There is a way to see what the "next" Field ID of a table is going to be, so it is possible to check.