Well, the scripts are in the file. The client's data is in the file. There are various methods to deal with this problem, which most independent (ie., not in-house) developers have. The best method is a 2-pronged approach.
1. Build a (long) script to automate Import of all data of all tables into an empty Clone (structure only, no data). The script must include steps to update the "next serial number" in all tables which require it (this is sort of a long topic of its own).
So, some evening or weekend, your client sends you his file(s), and your run the Import script. Then check a few things, to be sure it worked. Then, before he starts work again, sent him back the new file, with your new structure and his data.
2. Use the "separation model" to separate an "interface" file from a "data" file. This is easier to do than it sounds. It only really works for structural changes like scripts and layouts (which are the build of maintenance development). But you still need to have access to the "data" file if you need to create fields, or relationships for calculations; though relationships for navigation, viewing data, etc., can be done only in the "interface" file.
You can make changes to the "interface" file, and just send the new one to the client. He can stop the files (on FileMaker Server), upload the new "interface" file, replacing the existing, and he's good to go, with your script & layout changes. The only glitch is new or modified Accounts & Passwords. But hopefully those are few, or you can implement a script to do that (not easy).
If you have both of these methods implemented, and clean (never crashed) "master" copies of the two files, then you can handle almost any situation. But you really need both.
Remote access to the file is also helpful. But this should not be used for structural changes, ie., Field & Relationship changes, unless you're desparate. The chance of a disconnection or crash damaging the files is real.
Thanks for the thoughful answer Fenton.
Wow, I never realised the difficulty in improving the product and getting it back out to existing customers.
Luckily I have only deployed one (a test case) so far.
What about all the other FM developers? So, every FM developer has this obstacle to contend with whenever they update their product.
A new release of FM should have a function to Replace a script, or Update a Structure, Replace a Layout etc.
One command to export a database, and one to populate the data back into a new database, filling every field of the same name.
Thanks for taking time to help!