You have to run a backup of the database, stop the live database and then copy the backup to a working folder. Then you have to migrate the data from the live database you just copied to the version you have modified. Then you have to remove the database with the Admin console (the old live one) and upload the new one. Obviously best done after the close of business because the database is not usable while this migration is going on. Also, I usually don't work on a local copy ever. I rename the development file and put it on the server and work on it. This is much safer due to issues where corruption can happen if the UI crashes while opening it locally that almost never happen when hosted on a server. I just don't work on anything that is not hosted for this reason alone.
I personally do most of my development work on the live database so that I don't have to worry about such migration issues. It obvious is much more rapid, but there are risks to working on a live system. I mitigate them with regular and progressive backups and I make sure I understand well what I am doing so that changes I am making do not adversely effect on going business practices. You have to really know what you are doing and its impact on the system. Working on a live system is something almost unheard of in most database environments and is pretty amazing that you can even do it in FileMaker. The biggest risks are doing something that breaks a current business process. There also be issues if you are Managing Database and loose connectivity that could corrupt the database, which is a good reason to spend minimal time in Manage Database. Another reason is that once you start making changes in Manage Database, you start to record lock users and impact their work.
You might look at the separation model where you put the data and schema in one solution and the UI and layouts in another one. That way you can make modifications to the UI and layouts and just substitute that solution without having to migrate data.
The initial part of the update is done remotely. VPN and Remote Desktop.
We start by establishing a time frame when the client is absent for a short period of time. If it's not possible, we will sacrifice a week-end for it.
We ask the client to leave all his computers on, because our solution has 50+ files, some of which are pretty big.
We have a long checklist of things to do - and you should definitely build one too - which includes a list of the databases involved.
We make a backup of his current system, then zip it and download it on all the client's computers that we intend to use in order to do the update.
We upload on his server a clone of our release, then move to his computers, open the new version from the server and distribute on his machines the import of data from the local, now unzipped, copies of his last backup, setting the database file in the checklist as "in progress". Of course we do that manually, with some paranoiac twists like selecting Arrange by Creation Order then going back to Matching Names in the import field mapping, always checking visually the matches.
We do schedule a 4 - 8 hour session with the client immediately after the update, in which we introduce him to all the new features and measure the impact of the changes on his established interaction model - usually we did a good job and the news are welcomed and assimilated fast.
BTW, we never use the upload feature. After backup we stop the server, manually go into the correct directory, remove files and add files manually, re-establish permissions propagating the folder's one to all files, then start the server.
We rely on Goya's RefreshFM as the cornerstone to our update procedure. I highly recommend it. We built a robust AppleScript based procedure on top of it which allows fully automatic batch updates of our 300+ table solution for our clients. Each client is only down for about 20 minutes during the evening. Most users never see any interruption whatsoever.
So, it's possible, but it's a lot of work. In any event, investing in just RefreshFM will get you quite far.