Guidelines For Migrating to FileMaker 7

Here are some guidelines about upgrading that I would propose. They are probably too long, but I got on a roll...

Simple Databases:

• Upgrading a single file database is normally painless...though there are sometimes some drawing anomalies (fonts, and such). So give it a try and see if it works.
• Do not let other people use an upgraded database for "real" until you (and they) have tested it (more on testing below).

• You can try upgrading it by dropping all the files in the solution on the FileMaker 7 icon at the same time.
• Test it thoroughly. There are some insidious ways these upgrades can fail:
  • Use every feature, layout, script, of your program
  • Compare reports run on the migrated data to the same reports in your earlier version of FileMaker, particularly if your reports depend on relationships for some of their data or use "go to related records"
  • It's often useful to have a copy of the database in FileMaker 6 or earlier open next to the copy in FileMaker 7 so you can do one for one comparisons.
• Do not assume an upgrade of a complex database will go smoothly. If it does, count your blessings and go forward (after thorough testing).
• Often there will be a number of small things you have to deal with, but, if you have some debugging skill, they may not be too hard to address. I was surprised one of my uglier databases upgraded with only a few broken relationships and I was able to address them relatively quickly. Of course when I first upgraded it, it looked really awful because two of the three portals that made up the homepage were completely empty. The big time sink was doing the testing to convince myself it really had worked.

• Migration generally involves multiple iterations. Sometimes it is easier to fix things up in the old version before you upgrade it. In this case you'll upgrade, check it out, change the old version and upgrade it again. Sometimes a number of times.
• There are a few things you should know to migrate the database yourself:
  • How to debug a database. If you've only had to build a database and never done anything so complex that you had to figure out why something wasn't working, you may want to have someone else do the migration or help you do it.
  • You will need to know your existing database (or learn about it).
  • You will need to know FileMaker 7 reasonably well.
  • And you will need to know something about the migration process. There are some clear best practice processes out there and there is a lot of info on changes between the versions.
• This is all fun stuff to learn, if you have time, the documentation (see FileMaker's and New Millennium Communications white papers), the training, and the right tools ( MetaData Magic can be really helpful, it's free for up to 3 tables).
• Don't do the migration when the deadline is breathing down your neck. (Been there, done that, wasn't fun).

• You don't have experience or inclination to debug things. (It's both an character trait and a teachable skill.)
• You didn't develop the database and don't know it well.
• You don't have or want to develop the expertise needed.
• You have a database that lots of people have worked on over the years and could use re-architecting to clean it up.
• The database is mission critical and you don't want it in limbo for long.
• You only have one large problematic solution to migrate. You may not want to take the time to become knowledgeable of the migration process.
• You may want to consider re-developing the solution in FileMaker 7. Techniques to do this efficiently are mentioned in lots of the migration literature. Done carefully you can re-use lots of the layout elements, scripts, and so forth. Early on this looked like the best option for many people, but people have developed best practices for migrating databases that make this much less necessary.