2013-06-24 Switching from PAF

How-To, Problems and Solutions

How do I get my PAF database into another application?

The general answer, for practically any two current genealogy applications, is to use GEDCOM; export your database from one application to a GEDCOM file, and then import that GEDCOM file into the other application.

However, this is PAF we're talking about, one of the most popular genealogy applications ever. Major competing products will import PAF databases directly. Just start the other application and choose to import your existing PAF database, no GEDCOM required.
However, not all PAF imports are created equal, see the remarks below.

It is a little known fact that PAF is a customised edition of Ancestral Quest. If you decide to try today's Ancestral Quest, you do not even need to convert your PAF database, but can continue to use it, and even switch between using PAF and Ancestral Quest as you like.
You do have to convert the PAF database to an Ancestral Quest database to take full advantage of all Ancestral Quest features.

Which applications import PAF databases directly?

Unicode applications that can really import PAF databases directly include:

Ancestral Quest 12
RootsMagic 6
Personal Historian 2

Code-page applications that claim to import PAF databases directly, but suffer from limited character set support include:

Legacy Family Tree 7.5
The Master Genealogist (TMG) 8
Family Tree Maker 16

Unicode applications that claim to import PAF databases directly, but use TMG's import module include:

Family Tree Builder 7
Family Tree Maker 2012

How do I export to GEDCOM?

Follow these steps:

Start PAF and open your database
Choose File | Export to bring up the Export dialog bog
Choose the options
Choose "Export..." to bring up the Export GEDCOM File As (File Save As) dialog box
Enter a file name, e.g. PAFEXPORT.GED
Start the export process by choosing the Export button
Wait a few moments while PAF shows a progress dialog
When PAF is done the Cancel button becomes an OK button
Click OK

You're done. You've exported your database to a GEDCOM file.

What GEDCOM export options should I use?

You are exporting your database to switch to another application. So you should include all individuals, all notes, all sources, all private notes, etcetera.
Choose the options shown in the image:

Export To: Other GEDCOM 5.5
Char Set: UTF-8
Include: check all options
Selected Individuals: All

It is important to choose UTF-8, not ANSEL or ANSI.
UTF-8 and UNICODE (confused FamilySearch-speak for UTF-16) are the only two choices that are sure to export all your data correctly, regardless of what characters you used. Of these two, UTF-8 is the best supported choice. All modern genealogy applications support Unicode, but few applications support UNICODE (UTF-16), and those that do, support UTF-8 too.

If you try to import your PAF GEDCOM into another apllication and find that it cannot read it, avoid that application. A genealogy application that does not recognise an UTF-8 GEDCOM file yet is further behind the times than PAF is.

What about those _UID warning messages?

When you import your PAF GEDCOM file, the importing application may issue warnings for _UID tags in the PAF GEDCOM file. The _UID tag is a common GEDCOM extension supported by many applications, but it does not really matter if your application does not support it.
Those messages are nothing to worry about.

A genealogy application that does not recognise an UTF-8 GEDCOM file yet is further behind the times than PAF is.

What about those _AKA warning messages?

When you import your PAF GEDCOM file, the importing application may issue warnings for _AKA tags in the PAF GEDCOM file. Those warnings are cause for concern.

Although any tag starting with an underscore is a non-standard GEDCOM extension that may be ignored on GEDCOM import, you do not want the importing application to ignore PAF's _AKA tags. The data in the _AKA tags are the names you entered in PAF's Also Known As field, and you want to keep those.
It is mistake on PAF's part that PAF uses _AKA while it should be using another NAME tag. If you have a small database with just a few Also Known As entries, you could choose to re-enter that data, but that approach isn't practical if you have many Also Known As entries in your database.

There is a fairly simple solution for this particular problem. Tim Forsythe has created Clunk, the GEDCOM Fixer. Clunk will change _AKA tags into the NAME tags they should be.
It is up to you to make sure that all Also Known As field contain slashes delimiting the surname just like in the regular name field. See the Also Known As usage guidelines in the Also Known As article.