There are two "better ways" that you can consider and they are not mutually exclusive.
1) script the import process. This makes sure that every record of every table is successfully imported without omitting some records or a table. In this script, include code to update the Next serial value settings of any PK fields. Take a look at the GetNextSerialValue function and the Set Next Serial Value script step to see how you might do this from a script.
2) reduce your data imports by using the Convert to Seperation Model. This design puts all your data in one file and your interface (Layouts, value lists, scripts, etc.) in another file. Since many design update only change the interface, you can avoid any imports in those cases just by replacing the existing interface file with the new version.
I like the idea of doing the data separation model. Is this how most FMP databases are deployed?
I have no idea. Probably not. Much depends on the size of the user base and the level of complexity to your design as to whether or not it is worth it.
Be careful of any security settings--especially record level access control schemes that you employ with this model. Scripts set to run "with full access permission" don't when run from the interface file to modify data in the data file. Other means for "unlocking" the data temporarily have to be employed.