Application: Legacy Family Tree
Current Version: 8
Supported OS: Windows
Mobile Apps: None
Price: Free (standard edition), $29.85 (deluxe edition)
Publisher: Millenia Corp.
GenSoftReviews: 2.99 stars out of 5
Importing a GEDCOM file from Family Tree Maker (FTM) or any other app or website into Legacy Family Tree is fairly straightforward if you stick with the default options, but if you need help, Legacy has a short video, “Introducing Legacy Family Tree: the Simple FTM Upgrade,” on their website. I changed just two default options:
- When presented the Family Tree Maker Workaround screen (Fig 1), I selected, “Leave the Comments in the Place field because they are all place names.” I have never seen FTM 2012 or FTM for Mac (versions 1-3) put comments in the Place field. FTM correctly exports comments to Note fields.
- On the GEDCOM Import screen, I checked the box, “Put unrecognized items into notes field.” You could also check the box, “Sort events by Date while importing,” or you could do this after importing.
Version tested: Legacy 126.96.36.1996 Standard on Mac OS X using Crossover, Wine, and Parallels (all worked).
+ When importing a GEDCOM, Legacy presents a window showing the fields to be imported and fields not recognized. Legacy offers to map the latter to a different field, and it did.
+ There’s an option to save the list of items to be imported, so I took it. This list is for another import you might do so you don’t have to reset the options.
+ It asks how broken lines are to be handled: let Legacy decide, lines are broken in the middle of words, or lines are broken between words. Since I knew FTM breaks lines between words, I selected that option; it handled all broken lines just fine.
+ When exporting a GEDCOM, offers to add compiler information if there isn’t any yet.
+ When a GEDCOM import is complete, Legacy offers to open the import error log, so I did. Legacy saves this log with the same file name and location as your new Legacy family file but with the .log extension. While it’s good that Legacy creates a log file and offers to open it for you, the file itself makes little sense if Legacy encounters unrecognized data (see Cons).
+ Legacy imported most of my file correctly. Some additional information about how some fields were imported follows.
Name – additional names were imported as alternate names
Adopted Child-Parent Relationship was imported (the default relationship is Biological, which is shown as a blank).
Cause of death – imported as a medical note rather than a fact (but medical condition was imported as a fact); however, it was correctly exported to GEDCOM using the CAUS tag in a death event.
Height – imported the data but with the bizarre fact label “Preview Last Report”
Initiatory LDS – Imported as a regular event rather than an LDS Ordinance.
Marriage – If event detail is Y (no date or place), the Y is imported into the marriage note. There is a check box for “This couple did not marry.” It seems like it would be better to have a check box to the effect, “This couple married, but the date and place are not known.” When the file is exported to GEDCOM, the Y stays in the marriage note and is thus lost to the marriage field itself.
Military Serial Number – Imported as “Military”
Name Note – Imported into the general note on a person because LFT does not have a name note field
Nationality – Imported a note attached to it but not the description
Individual Media – Displayed the primary photo for a person twice, because of the _PHOTO tag in FTM GEDCOMs. If this bothers you, then you can delete these lines from your GEDCOM file before you import it into Legacy.
+ Custom FTM tags – imported all except for _HEIG, as noted above; when exporting these fields, it did so in the preferred way of using the EVEN.TYPE tag structure.
+ Generic Event: Most genealogy apps I’ve seen have a generic or miscellaneous event and/or fact field that can be used in conjunction with a type field like Arrival, Departure, etc. As I’ve stated elsewhere, this is the best way to define custom events for which there is no standard GEDCOM field, rather than using a user-defined field like _ARR. Legacy follows this best practice. Users can add their own fields using the Add/Edit an Event Definition window, and Legacy correctly exports them using the EVEN.TYPE structure.
+ Sources and citations: Legacy fared well here. It imported two of two sources and all citation data, to include media on both sources and citations. However, as I explain below, Legacy has a problem when citations don’t have any details.
+ GEDCOM Export – Legacy exports GEDCOM 5.5.1 files that are standards compliant with a few exceptions (see Cons).
It seems that there is a problem with Legacy’s GEDCOM parser. Legacy expects citations to have details such as the PAGE and/or TEXT tags, even though the GEDCOM standard does not require them. While citations will usually have such details, they may not always, so this is a flaw in Legacy’s parser. If I hadn’t thought to delete all such citations from my GEDCOM, I would have concluded that Legacy did a very poor job of importing a GEDCOM! Here’s an example from the Legacy import log:
---------------------------------------- Main Record: 0 @I11885@ INDI Sub Section: 1 FCOM * Unrecog. Line for an Individual Record: 2 SOUR @S68@ 1 _CIRC Source not found in GEDCOM file (The program that produced this GEDCOM file is at fault.) ---------------------------------------- Main Record: 0 @I11885@ INDI Sub Section: 1 FCOM * Unrecog. Line for an Individual Record: 2 DATE 11 JUL 1875 Source not found in GEDCOM file (The program that produced this GEDCOM file is at fault.) ---------------------------------------- Main Record: 0 @I11885@ INDI Sub Section: 1 FCOM * Unrecog. Line for an Individual Record: 2 PLAC Szepes County, Kingdom of Hungary Source not found in GEDCOM file (The program that produced this GEDCOM file is at fault.) ----------------------------------------
Now here’s the “Sub Section” from my GEDCOM:
1 FCOM 2 DATE 1865 2 PLAC Szepes County, Kingdom of Hungary 2 SOUR @S68@ 1 _CIRC 2 DATE 11 JUL 1875 2 PLAC Szepes County, Kingdom of Hungary
Notice that the FCOM and _CIRC sub sections are separate from each other, which Legacy should be able to tell by the fact that they are both at level 1 in the record. SOUR @S68@ really was in the GEDCOM file. As I said, Legacy’s GEDCOM parser seems to be faulty if it can’t read this perfectly acceptable structure. I love how Legacy’s log says,”The program that produced this GEDCOM file is at fault,” for data it can’t parse. After I removed the source record links (2 SOUR @68@), Legacy imported most data except for the following:
Email, phone, and WWW fields which were correctly attached to an event in the GEDCOM. The log reported only the WWW as not being recognized and that it was imported to the note for the person (which it was). Legacy supposedly imports data it doesn’t recognize into the person note, but the email and phone fields were not. Oddly enough, Legacy exported these data after I added them back, with only one minor issue (see below under GEDCOM export). Presumably Legacy would import them also if they were attached directly to an individual record, which is how FTM exports them.
LDS Confirmation – simply disappeared without any mention in the import log.
Annulment and Social Security Number – Legacy doesn’t import the standard tags ANUL and SSN into the existing fields for them. Instead of importing ANUL into the existing Annulment field, it creates a new field called “Annulled,” which is then exported back to GEDCOM using “EVEN.TYPE Annulled.” For SSN, instead of importing it into the existing “Social Security Number” field, Legacy creates a new field called “Soc Sec Num,” which is exported to GEDCOM using “EVEN.TYPE Soc Sec Num.” The built-in fields “Annulment” and “Social Security Number” are exported correctly using the standard tags ANUL and SSN.
Note on title – imported one but stored it in a location that seemed inaccessible to the user. I could tell it was still there because it was exported. However, when it was exported, it was attached to an EVEN structure with the TYPE “No Name,” rather than to the NPFX tag.
Media Date – my GEDCOM file contained the proper structure for a media date (CHAN.DATE). However, when I deleted the CHAN line and reverted to the FTM structure, the date imported fine. This seems to be one of those cases where it may be better not to follow the GEDCOM standard.
GEDCOM Export – Legacy has a few issues when exporting GEDCOM 5.5.1 files:
Addresses: exports addresses in the main address book for an individual directly subordinate to the individual’s record in a GEDCOM file. Addresses must be attached to an event, which Legacy can also do correctly.
Caste & Property – uses the EVEN.TYPE tags instead of the standard tags CAST & PROP. For both backwards and future compatibility, if there is a standard tag for an attribute or event, then it should be used in favor of the EVEN.TYPE structure.
LDS Seal to Parents – missing required FAMC tag (child-to-family link).
Ordinance – Incorrectly used the ORDI tag, which according to the GEDCOM 5.5.1 standard should occur only in a Submission Record as “A flag [yes or no] that indicates whether submission should be processed for clearing temple ordinances” (p. 57). In my original GEDCOM file, _ORDI was a custom individual event tag to store a religious ordinance other than one of the LDS ordinances. It should have been exported using either the same custom tag or the EVEN.TYPE structure.
Character Set: Legacy provides the option of the character set ANSI, which is not a valid option in GEDCOM 5.5 or 5.5.1. In fact, GEDCOM 5.5.1 specifically states, “Systems using code pages to support diacritical characters, such as the windows ANSI 1252 code page, must convert all characters above character code 0x7F to its ANSEL representation for that code page” (p. 77). So the ANSI option should be removed from Legacy, since it already offers the option of ANSEL (as well as UTF-8). (Added 6 Apr 2016)
I added the Legacy fields to the GEDCOM Crosswalk at Family Tree Maker to GEDCOM to Other Apps Crosswalk. This table shows at a glance how the major genealogy apps name their fields within the app and how they are exported to GEDCOM. The color coding indicates areas of concern: fields in red are not imported and/or exported correctly, while fields in yellow use custom tags that may not be recognized by other apps or websites.
I think former FTM users will find Legacy to be fairly easy to transition to. Almost all data are imported, even FTM’s custom tags. The user interface seems to be a hybrid of FTM and Reunion with a little bit of RootsMagic thrown in, but it’s not so different from FTM that it’s difficult to learn. I found the buttons and menu items fairly intuitive, and I could generally find what I needed without resorting to the Help file, which seemed comprehensive. Legacy seems to have many more features than FTM, which I’ll explore in more detail in a future update.
GEDCOM 5.5.1 Test: Legacy Family Tree 8 passes the GEDCOM 5.5.1 Test. While it has a few compliance issues, both with import and export, it exports GEDCOMs using UTF-8 encoding and correctly labels the files as version 5.5.1.
21 Mar 2016: Various updates based on feedback from the publisher.
6 Apr 2016: Added a point about the ANSI character set.
30 Apr 2016: Added a statement about the GEDCOM 5.5.1 Test.
20 Aug 2016: Revised the information on the ANUL and SSN tags based on my finding that the problems with them originate upon import, not export.
The Family Tree Software Alternatives Series
Part 1: How to Scrub Your Data
Part 2: How to Get Your Tree out of FTM
Part 3: RootsMagic 7
Part 4: Reunion 11
Part 5: MacFamilyTree 7
Part 6: Family Tree Builder 8
Part 7: Heredis 2015
Part 8: Gramps 4
Part 9: iFamily for Mac
Part 10: GEDitCOM II
Part 11: Legacy Family Tree 8
Part 12: Ancestral Quest 14
Part 13: Family Historian 6
Part 14: Should You Stick with Family Tree Maker?
Part 15: Brother’s Keeper 7
How Well Does Ancestry.com Handle GEDCOM?
Family Tree Maker to GEDCOM to Other Apps Crosswalk
The Perils of Following the GEDCOM Standard
Why All Genealogy Apps Should Support GEDCOM 5.5.1
*Information current as of the date of this post