Rule 1 would be: do not work on the live, running, shared file.
Before you do any more work, make your next task to write an import script that cycles through all of the tables and 'Show All Records'. Then in the upgrade file have a script that runs that script in the 'old' file, then in itself runs an import script to import all of the data, table by table.
Take a copy of the current file (if you don't already have one, which would be better)
Take a back-up of that file, and date it.
Do your development work on the first copy. Make sure it is not available on the network, or people will accidentally log in to it.
When you want to do another upgrade release, make a clone copy of the file you have developed, take everyone out of the working file, and run your import script on the new file. Rename the new file as the correct current-file name the users are used to. Rename the 'old' file with a date appended and store it well away from where any users could possibly see it.
That's my suggestion, anyway.
Such an import script should also update the next serial values settings on all fields that use the auto enter serial number field option. There's a script step, set next serial value that you can use for that. You import data from a given table, determine the largest serial number value in the imported records and then set the next serial value to a larger number than that maximum.
You can also avoid the need for importing all togehter if you use a data separation design. You put all your tables in one file and keep your scripts, layouts, value lists etc in the other file. Since many updates, changes, corrections only change the interface, those kind of changes can be made and deployed simply by replacing the interface file with a new copy and then no data importing is required.
It's not terribly difficult to split an existing single file solution into two such files either: