Batch conversion from FM6 to FM8?

[kfutter]

I need to convert a large number of databases from v6 to v8, and was hoping there was a way to batch convert them, for obvious reasons. I seem to recall v7 shipping with such a tool, but we skipped 7 and have recently upgraded to 8, which appears not to have anything like that. I've searched extensively but can't find anything useful - does anybody know of an approach or tool I could use to help here?

Thanks in advance,

Kevin

[DukeS]

You can use script step Convert File, but note that you can't input folder, files must be converted separately.

HTH

[Ender]

If the files all reside in the same folder, you can simply drag and drop them on the FileMaker 8.5 application icon. Converting all the files in a multi-file solution at once like this is preferable, as it does a better job resolving the file references.

[kfutter]

Thanks Ender. The files are sorted into separate folders on the server, but I've grabbed them from the daily backup, so as not to disturb the production environment, where they're all in one folder. I was going to do a dry run to see how everything would resolve, but your answer suggests that FM won't dynamically account for the differences in locations between my test folder and the production folders. Is that right?

Anyway, I'll give it a go and see what happens, reporting back as necessary. Might take a while though, as there's over 100 databases involved.

Cheers,

Kevin

[Ender]

If your separate folders contain different logical modules, then most of the references will be to files within each folder. I'd go ahead and try converting each folder separately. You'll likely need to check all the file references anyway.

On a similar note, if you haven't already done it, you should get MetadataMagic and use the File Reference Fixer to consolidate duplicate file references and remove outdated file references. This is well worth it for a large complex solution where you might otherwise have hundreds of references to fix by hand.

[kfutter]

Unfortunately it's not that simple, as these databases, and the way they've been organised, have grown organically and without much planning over the last 8 years or so (long before my time). We have one file in particular that nearly everything seems to reference, and the whole thing is a tangled mess of inter-relationships and file references that's due for a huge clean up. Most of which will happen *after* the conversion. I just need to get it all working first, and wasn't looking forward to opening and converting each database individually. It sounds like it would probably be better if I were able to maintain the original folder structure while converting, but this is just a dry run to see what happens.

I'll report back after the dust settles.

Cheers,

Kevin

[kfutter]

Well, having finally found the time to do my dry run, it mostly went well. It took forever (about an hour, including having to authenticate to each database after it converted), and with so many databases I haven't done any significant testing, so the results are still somewhat uncertain. However, file references are the obvious casualty, but they're really the least of my worries, as they're easily fixed. Besides, for the real deal, I'll be converting the files using the actual folder hierarchy that exists on the server, so most of the file reference issues should be avoided there.

The only other obvious issue is layout drift - quite marked in some cases (worse than I'd seen in previous conversions). This will be quite tedious to fix, but hardly a deal-breaker.

Thanks to everyone for their help and suggestions.

Kevin

[Ender]

If you haven't done so yet, be sure to read the Foundations & Migration Methodologies white paper on filemaker.com. It spells out some common conversion issues that one should look for and solve. Some things can be fixed prior to conversion, and other things must be fixed after conversion.

For a large solution, you'll likely have a few trial conversions, where you test and isolate some issues that should be solveable in the FM6 files (pre-conversion). Then the last one of those that looks the best will become the new structure where you begin solving the post-conversion issues and consolidate the files that you can (assuming you're not doing a total rewrite). Then you'll do some trial imports from a newly converted copy of the active solution. And finally, you'll plan a weekend to actually do the final import of the converted active solution into clones of the new solution.

If it sounds like a huge task, it is. You have to be very organized about the process, keep a checklist of things to do for each file/table, and keep backups of each stage of the process. With a large solution, expect to spend many months working through the migration.

[kfutter]

Thanks, I do have and have read that particular PDF. As you say, it contains much useful information. However, I don't have the luxury of the time or resources to follow its recommended approach fully. There will be much more 'fix after' than 'fix before'. We originally envisioned incorporating a rewrite of many of our databases into the conversion process, but have since decided that that is impractical. It's something we will begin doing after the fact, since v8 is much more flexible in that area anyway.

[kfutter]

Just a quick report back post-conversion. I did several test conversions prior to the real deal, with each revealing a new set of problems, most of which boiled down to having to manually amend each and every file reference in each and every file. Tedious, but not difficult.

Once this was done, most of the inter-file plumbing seemed OK, but there have been additional issues, and I'm sure many more will surface over the early weeks of next year.

One thing I have learned from the fallout is that v6 was quite sloppy internally compared to v8, allowing such things as matching on keys that had a random number of spaces at the end. Of course, v8 croaks on this immediately, so I still have a great deal of remedial work ahead of me.

Kev

Edited December 20, 2006 by Guest