For major structural changes, do not do it on the current file. This will lock other users out of your database at random intervals when you commit changes to the database--possibly keeping a script inititated by a user from functioning correctly. And any network glitches at the wrong moment can corrupt your file.
But you won't need to export any data. FileMaker can use Import Records to import data directly from your current file into the new copy. You can script this and set the script to also update serial number fields in the new copy to match current settings in the original copy.
You may also want to consider using a Convert to Seperation Model for this to minimize the number of data imports you have to do when making changes to your database.
Ok. Does this sound like a good approach? Download the file from the server and build my solution for the second dept. When I'm done, I will simply import data and replace the server file with the revised file. Then I will build my solution for the 3rd dept and repeat until all depts have a solution.
As a side note: Can I change my naming conventions and still successfully import data
"simply" might not be the best adjective. You should also either manually or in a script, update any fields set up as auto-entered serial numbers.
You can chagne namaing conventions, but it's safer not to do this in "mid update" as that may require manually matching fields to set up your imports.
Go into Manage | Database and change the names of fields, tables, table occurrences now, before you take a copy for developing the next update.
Note: in most cases, you can safely rename fields and table occurrences in FileMaker, but be careful of any script steps such as set field by Name, get Field, calculations that might use them (or evaluate), and any script parameters that might refer to a field or table occurrence as literal text (text in quotes). Name changes will keep those expressions from correctly evaluating to the renamed tableOccurrence::Field.