Everything you said is true. If you don't want to work on the live files whenever you want to apply the changes to the live system you will need to close the old (current) version of the database(s) on the server then clone your new version (or just delete all the records) and then import all of the records from the old version into the new version before you put it up on the server.
Depending on how many tables you have it can take a while to write a script like that. The good news is you can easily map the fields in the import records script steps by using the "matching names" option if your field names haven't changed since the last version.
One thing that we do sometimes when we expect to have to make changes like this is create a data seperated model. Basically we have a couple files, one interface file that has no tables in it, one data file that has the main data, one file for documents with a table with container fields, a file for value lists etc. etc. etc. That way if you only have to make a change to a layout you can just copy over the interface file without having to worry about any data migration.
P.S. I also vaguely remember hearing about a third party program designed to help do a sort of version control and deployment assistant thing with filemaker but I can't remember what it was called. It may have just been a hallucination after having done a particularly large data migration.
Thank you for your reply. I was afraid the database would have to be transferred. This seems like a negative in terms of maintaining a Filemaker solution. Are you aware of any documentation on how best to go about making changes to a Filemaker Solution on a Server?