Here is how I've done this... in simplistic terms...
A. create your new solution with new tables, fields, layouts, scripts, etc.
B. create a specific script in the new solution that would IMPORT all data from the old solution
C. give the users your new solution with instructions to RUN the 'import script'
1. TEST TEST TEST
2. you should 'archive' the users existing data before the process (this could be scripted)
2. the users will need to 'point' to their existing solution during the 'import'
3. the users will need to 'destroy' their 'old' solution so as not to reuse it
4. the 'import script' could be part of a 'startup script' that runs the first time the user opens the new solution -- this could be done using a 'status field' that tracks whether the data has been imported
5. the new solution MUST have fields that match the fields on the old solution -- you could have extra tables in new solution that match the old solution and then the data is 'manipulated' (using scripts & calcs) into the new tables of the new solution
When deploying any solution... the developer should "keep-in-mind" that there will be future upgrades... always include a process (using scripts) to perform 'archiving' of data and the process of moving the data to a new solution.
Hope this helps... Good Luck!
Thanks for your help. That is a very useful sugestion.
One more consideration when importing data from another Filemaker database, as suggested by Kundinger, is that only selected records in the orignal database are imported. If one record out of 100 records has been selected then only that record will be imported. You might want to include a script in the original database to find all records and then run it remotely from your import script in your revised database.