What you can do is write a script that imports data from the old database file into the new, resetting any serial number fields in the tables as needed. The user clicks a button in the old copy that does a show all records on every table, saves a copy of itself and shuts down the run time by quitting. The user then drops the new copy of the file into the solution folder (This is why you use save a copy, so that the old file has a predictable name and the new file can replace the old copy of the same name) Then the user re-opens the file and clicks an update in the new copy that imports all the user's data from the copy of their old file that was produced by the first script.
You can also design your system to use the Data Separation model. This set up splits your database solution into two files. File 1 is the Interface File with all layouts, scripts, value lists etc. defined in it. File 2 is the Data file with all the table definitions defined in it. Since most updates are changes to the interface, this greatly reduces the number of scripted imports needed as updated interface files can simply be dropped into the solution folder to replace the older interface file.