Peter, I've done many such migrations and have a few comments in "stream-of-conciousness" order.
These are all my own _personal_ opinions and some may run counter to the official materials. M8 below refers to multifile 8, S8 is single-file 8. 1) I believe the single-file solution is now the default and that the benefits are such that one must have solid business reasons for multi-file solutions, such as keeping a replaceable Catalog as a separate file, or keeping Accounting, for instance, as a separate file for security reasons. If you merely do a conversion to a similar 100-file setup in 8.5, you're not realizing the many benefits of the newer paradigm. If you roll it into one or a very few files, your file reference issue becomes almost nil. You will lose a huge number of redundant scripts. Many scripts calling externals will become simpler by a factor of 10. You're only maintaining a few Accounts & Privileges instead of dozens. 2) 8.5's copy/paste tools make it really easy to roll files into tables. 3) M6--do a _lot_ of prep work in your 6 solution before migrating to 8.5. Rename the relationships the way you want them to be in 8.5 ( see 6 below). Audit your files and make sure all identical value lists are named exactly the same across files. 4) Buy a screen shot utility--you'll need it to document things that are hard to print: relationships, value lists, accounts and permissions. 5) Go to www.kevinfrank.com and download and watch (1/2 hr) his powerpoint presentation explaining the Anchor-buoy method of structuring relationships. It is very similar to what you already know from 6. Most developers are now using this method for building their files. 6) In your 6 version, rename your existing relationships the same as you'll be using in Anchor-Buoy 8.5. 7) Buy FileMaker Advanced 8.5 and get the maintenance program so you'll be kept upgraded. Make a quickie 8.5 auto-conversion (M8) of the solution and use Advanced to run the HTML database design report at various stages. Use FireFox to search the html ddr for words like "unknown" & "missing". 8) I have personally spoken with other developers who've done a multifile conversion/migration/troubleshooting of 100 file solutions, and they say they would have been better off scratch-building as a single-or-few-file solution. 9) Audit your existing solution to determine which layouts are not being used at all and on those that are used, which scripts are not being used or are desired but don't work properly. Making a screen shot of every screen and marking with colored markers is easy. 10) M6--use the Size palette to document each existing layout you'll be re-creating in S8: dimensions of margins, parts, background colors--pixels are easiest. Don't forget sort fields on SubSummaries. Do a Select All and copy down the top 2 coordinates out of the Size palette. 11) S8--use this documentation to create new empty blank layouts with the proper margins, parts & colors in your 8.5 file. 12) don't be in a hurry to copy the layouts from M8 to S8: your new S8 will need to have all the tables, fields, value lists, relationships, scripts and properly-named blank layouts before you copy & paste the elements of a single layout from M8. If you do this correctly you'll be copying all the elements off your M8 files and pasting them into your S8 layouts and all the field names, related fields, portals, dropdown lists etc will appear perfectly and you won't have to re-link them. 13) dealing with scripts is your biggest issue. 14) when you're importing the scripts into S8, create a section for each in the script list. Sometimes it's easier to go thru M8 and identify the useful scripts and move them into a group for import to S8. Mostly I just import them all and don't worry about the many redundancies. In your S8 file scriptmaker, create Verified and UnVerified sections. All the raw scripts get imported as above into the unverified section. 15) in S8, go through each layout and verify that each script button works properly. Many of these scripts you'll be rebuilding differently but simpler. When a script is OK, move it to the Verified section. This is the most time-consuming part of the process. It might take a third to a half of your total time expended. When you're done, delete the dead wood scripts. 16) Personally I find it useful to use prefixes as shorthand for tables. PE for People, PR for Projects, etc. You can use these in scripts and layouts as a handy shorthand. Renaming your good scripts starting with a unique identifer as you move them to the verified section is a good way of telling them apart from your dead wood scripts. 17) Plan your big data transfer--if you're going to rename any fields, take the current actual files offline, such as over the weekend, and rename them then. Then leave all field names as-is so you can do your data transfer using Matching Names. Make a screen shot of the Tables list in Define Database and use it as a checklist for importing the data. It shows how many records each table contains. Compare this to the records in your M8 version. FWIW. -- Steve Steve B. Gerow FileMaker 8/7 Certified Developer President Abrazos Data Consulting, Inc. Dependable Database Development Pasadena California www.abrazosdata.com FileMaker Solutions Alliance Member Associate Level
