Ancestry.com announced that they are abandoning (aka “retiring”) their venerable Family Tree Maker (FTM) desktop application. They will no longer sell it after Dec. 31, 2015. All features of the program will continue to work, but after Jan. 1, 2017, “features that require connectivity to Ancestry, such as TreeSync, uploading and downloading trees and media, and Web Search, may no longer be supported.”
Many genealogy bloggers have already addressed the question, “What do I replace FTM with?” Several genealogy desktop app retailers are offering discounts and help guides on how to transfer a family tree from FTM to their software. Most of them make it sound as if it’s as simple as exporting your FTM tree to a GEDCOM file and importing the GEDCOM into their application. I say, “Not so fast.” For starters, there’s no hurry, since we have at least another year of full FTM functionality. Second, TreeSync is one of the main reasons many of us use FTM, and we don’t yet know which 3rd party apps, if any, will be able to sync with Ancestry.com. Third, and critically, FTM does not comply fully with the GEDCOM standard. Few genealogy apps do, even the ones that claim to. Why is this important? Because if you blithely export your tree to a GEDCOM file without scrubbing your data first, you will lose some data, and your carefully crafted Evidence Explained citations will get mangled. If you want to take advantage of one of the current sales on genealogy software, you may have a smaller time window in which to decide, but you would still do well to clean up your data first. That’s the goal of this article: to help you identify areas where your FTM tree is non-GEDCOM compliant and start cleaning them up. Please note that this article is not about correcting factual errors in your tree. This article applies generally to both the Windows and Mac editions of Family Tree Maker, all versions since 2008, although your mileage may vary.
Before I continue, here’s an overview of GEDCOM, which stands for Genealogical Data Communication. It’s a specification for exchanging genealogical data using a plain text file ending with the .ged extension. It was developed by The Church of Jesus Christ of Latter-day Saints (LDS). The current official standard is GEDCOM 5.5, but the standard used by many, if not most, apps and websites is 5.5.1, as Tamura Jones has pointed out many times. While technically is still a draft standard, 5.5.1 includes fields for WWW and EMAIL and adopted the UTF-8 character set. Even the LDS Church’s FamilySearch.org website uses 5.5.1. Version 5.5.1 was proposed in 1999, and while several updates have been proposed, including version 6 and GEDCOM X, they have not progressed beyond the proposal stage.
The GEDCOM standard documents can be difficult to read, but they are here for your reference (note that “GEDCOM is no longer maintained!”). Technology blogger Tamura Jones has many articles about GEDCOM; A Gentle Introduction to GEDCOM and GEDCOM Tags are good references. The Complete Genealogy Products website has a good quick reference sheet for GEDCOM.
So GEDCOM is a standard for formatting genealogical data so that other apps and websites can read them, but as I mentioned, FTM doesn’t completely adhere to the standard. You can fix some of the problems or work around them in FTM before you export your tree to GEDCOM. Part 2 of this series will explain how to fix problems directly in a GEDCOM file. But before you do anything, make a back-up of your tree, and make a new back-up (with a different file name) after each major step so that you can revert to an earlier version if needed. Also, if you haven’t already done so, you might want to download any media from Ancestry.com that you want to attach to your tree, such as images of historical records.
FTM’s worst offenses are that it improperly exports some fields. Below are the fields that FTM incorrectly exports to GEDCOM and how to fix them in FTM, if possible. Some genealogy apps “know” that FTM has these problems and will fix them for you. My intent here is help you produce a GEDCOM 5.5.1 compliant file so you don’t have to rely on the mercy of other apps.
Also Known As: older versions improperly use the ALIA tag in the GEDCOM file. I see 4 options: 1) Don’t use this field (put it in a note to the NAME field) 2) Create a custom field for AKA (see below) 3) Fix it directly in the GEDCOM file 4) Use an additional NAME field entry; most other apps will import them as alternate names, but not all (note: option 4 was added on 9 Jan 2016). I prefer option 2. Update 5 Jan 2017: The Software MacKiev editions of FTM (2014.1 for Windows and 3.1 for Mac) now correctly export Also Known As using the NAME.TYPE aka structure. But here’s how to determine if you’ve used the Also Known As fact for users of older versions; these instructions also apply to any fact in your tree:
1. In the Tree pane of the People work space, click the Tree tab
2. Click the Filter button at the bottom and a selection window will appear (Fig 1)
3. Click the Filter In button and the Filter Individuals By window will appear (Fig 2)
4. Click the All Facts button and then the field you want to search on (such as Also Known As). Select “Any Data” and Conditions “Exists” and click OK
5. If there are any records matching your conditions, they’ll appear in the next window. Click OK again
6. Go through the list and correct each one
7. When complete, repeat steps 1 & 2 and then click the Exclude All button to clear the filter; click OK
Address: incorrect structure. There’s no good way to fix this within FTM because an address should contain a street address, city, state, country, and postal code in separate form fields. The Address structure doesn’t use the Date or Place fields. It must be attached to an event (like a residence), not directly to a person. In Part 2 I’ll explain how to add an address to a GEDCOM file. For now, I suggest putting any addresses in the note for the events they are related to. Use the steps above to find any filled Address fields. Update 9 Jan 2016: Be aware that few apps completely follow the GEDCOM standard on addresses, so if you try to follow the standard, you may end up losing data. See my article, “The Perils of Following the GEDCOM Standard.”
Email: should be part of address structure. Same as Address.
Phone Number: should be part of address structure. Same as Address.
Web address: uses EVEN/TYPE tags. While not exactly wrong, there is a structure for web address in GEDCOM 5.5.1, but it’s part of the address structure. For Type A people, another solution would be to change the EVEN tag to the FACT tag for web addresses under individuals, but this has to be done by editing the GEDCOM file directly, which I’ll explain in Part 2.
Race: uses the EVEN tag when it would be better to use the FACT tag. There’s nothing you can do about this in FTM, so I’ll explain what you can do in Part 2. Update 9 Jan 2016: I have yet to find an app that can read the FACT tag.
Sealed to Parents (LDS): missing required child-to-family link. There’s no way to fix this in FTM, so if you need this field, see Part 2.
Multimedia: missing required file format field, saves the Description to the wrong field (tag TEXT), and uses the wrong syntax for the date. The only way to fix this within FTM is to manually go through all your media and copy the Date and Description to the Note for the item, as shown in Fig 3.
Alternatively, you could use a text or GEDCOM editor to do a global search and replace on the Text field, but this will not work with the date. Also note that the media Category will not be saved to a GEDCOM. One problem due to the GEDCOM standard itself is that your media file paths and names will probably be too long. The standard allows for only 30 characters for the file reference! Fortunately, most modern apps will probably ignore this limitation. Update 9 Jan 2016: Many apps and websites will probably be able to read the media date; in fact, if it’s correctly formatted, they may not be able to read it!
Sources may use only the following FTM fields in a GEDCOM file: Author, Title, Publication Facts, Repository, Call Number, and/or Media. Source citations in an FTM GEDCOM file don’t include URLs from the Web address field of the Edit Source Citation form, so if you want to keep them, move them into citation detail. Update: However, be aware that if the citation detail is longer than about 75 characters, FTM will export the rest using the GEDCOM concatenation tag (CONC). The GEDCOM standard does not permit the use of concatenation or continuation (CONT) tags for the citation detail field. Most other apps and websites will probably import the illegal concatenation or continuation tags anyway, but if you want to try to have a standards-compliant GEDCOM file and your citation detail is longer than 75 characters, you might want to put part or all of it into the Citation Notes field; this field will be exported to GEDCOM using the NOTE tag, which can have as many CONC or CONT tags as necessary. Update: Thanks to reader Bob for pointing out the FTM 2014 has the option of exporting source URLs using the _LINK tag. However, since _LINK is a custom tag, other applications might ignore it, so the best advice is still to copy URLs to Citation Details or Citation Notes. Update 5 Jan 2017: FTM 3.1, for Mac, now also exports web address URLs to the custom _LINK tag; I still think the Citation Note is the best place for this.
FTM will dump any other elements into a note which may not be formatted the way you want. Therefore, I suggestion you use only the following fields of the default Source form (not a template): Title, Author, Publisher, and/or Repository. Put all the publication elements in the Publisher field, formatted the way you want. The Repository portion of a source record in FTM uses the wrong address structure. If you need this field, I recommend you use only the Source Repository Name and Call Number fields. If you need the address, phone number, or email, save them elsewhere. Comments on a Source will be saved to a GEDCOM file as a Note attached to the source record. You might like to know that Quality ratings are saved with the number of stars, and the justification is saved in a custom field (_JUST), which might get lost in some apps.
When you export your tree to a GEDCOM file, you want it to contain all your data without anything extraneous. The following things will not be saved to a GEDCOM file:
Tasks: I recommend copying them to the Note for the person.
Saved Publications: export any you want to save as PDF, CSV, RTF, HTML, or Image.
Unlinked media & sources: you probably don’t need these anyway if they’re not linked to a person. If you do need them, you can use the Media Usage Report to find unlinked media. In FTM for Windows, the Source Usage Report will show unlinked sources at the end of the report, but the Mac version does not. Oddly enough, I have found that FTM does export unlinked notes if you export selected individuals. However, most other apps will simply report them as an error and ignore them.
Weblinks: These are from the Web Links tab in the Person view of the People work space, not Web addresses added as facts. The latter will be exported using the Event/Type tags, which isn’t ideal (Fact/Type would be better), but most apps should be able to read them, so if you have Weblinks, copy them to the Citation detail of the source citations to which they pertain (see Fig 4). Unfortunately, there’s no way to search for Weblinks in your tree using either the Filter or Find functions. You should also copy any Web address for a source citation into the Citation detail or Note (if it would make the detail longer than 75 characters), also, because otherwise,
it will not be exported to your GEDCOM file unless you use FTM 2014, in which case it will be exported with the custom tag _LINK (see above under Source Citations) for both FTM 2014.1 and 3.1 (updated 5 Jan 2017).
Surprisingly, it is not permitted to include a source, media file, or note on the Sex field. FTM will let you add these, and some apps will squawk if you do or just ignore them. I think if you have sources attached to this field (like the US census, which are often added automatically), you can safely ignore them. However, if the individual was transgender, you should make sure those sources and any notes are copied to another field, like the Name field.
FTM also errs in misusing the Description field, which appears on some Facts by default (it can actually be turned on for all Facts). Technically in the GEDCOM Standard, there are really two major types of facts pertaining to an individual: attributes and events (families can also have events). An attribute is a fact about a person for which there may or not be a particular event. The following fields are attributes for which it is appropriate to use the Description box: Caste, Physical Description, Education, Nationality, Occupation, Property, Religion, Residence, SSN, and Title. These facts may but are not required to have a date and/or place.
However, events are facts that must have a date and/or place, or else include only the letter “Y” in the Description box. If a date or place is listed, then the Description box must be empty. The Description box also may not contain the letters “N,” “U” or anything else. Unfortunately, FTM will let you put anything in this box. To find out if you have other than Y in the Description box, do the following:
1. Follow Steps 1 & 2 above for filtering your tree.
3. Match the conditions shown in Fig 5. “Match All Values” is important—otherwise you’ll miss all words containing the letter Y, not just the letter by itself
4. Click OK, and then go through each person in the filtered list. I recommend copying any text in the Description box to the Notes tab on that fact (the note will be exported to a GEDCOM file, as will all other notes)
In Part 2 of this series I’ll mention a few other things that might be included in a GEDCOM output by FTM but can only be cleaned up using an editor. By the way, I’ve reported all of these problems to Ancestry Support, and you should too. Since these are complex issues, it’s best to put them in writing. Their email address is support [at] ancestry [dot] com. The problems I identified above should have been fixed long ago, but maybe Ancestry.com will fix some of them as bugs.
While not necessarily a problem, if you use the fields listed below, they will be exported as user-defined fields, which is allowed by the GEDCOM standard, but not all applications will import them properly. Some apps put data they don’t recognize into an import error log; you’d then be stuck manually reentering all of this data into your new tree:
Cause of Death
Military Serial Number
Primary photo for a person
If you know your chosen application will ignore custom fields, you can avoid the problem of data reentry by converting the fields to your own custom fields. This works because FTM uses the Event/Type structure instead of a custom tag like _DEG. Here’s how to do it:
1. Go to Edit > Manage Facts… (Fig 6)
2. Click the + button to add a Custom Fact (Fig 7)
3. Fill in the Custom Fact details. You’ll have to use a different label from an existing one. By the way, you can also do this with the Also Known As field to create a custom AKA field, as shown in Fig 8. Click the Add Fact Button
4. Now we’re going to replace FTM’s custom facts with our own. The Manage Facts window should still be open; select the Fact to change, such as Degree, and click the Data Options button. You’re offered the chance to make a back-up—take it
5. In the Data Options window, check the Change selected facts to this fact type box and choose the fact you want to change it to. All instances of the selected fact in your tree should be selected by default, but if they’re not, do so. I’m changing Degree to Deg (Fig 9)
6. After you click the OK button, FTM will change all instances of the selected fact
7. Repeat the process until complete and click the Close button
Now all your custom facts should import into any decent app. I highly recommend doing this to avoid losing any data from FTM’s non-standard fields; it’s what I did with my family tree.
That covers the data you can fix within FTM before you export your tree to a GEDCOM file. Take your time going through your tree (we have at least a year, after all), keep good back-ups, take notes about what you’re doing, and ask questions in the comments or the many forums for Family Tree Maker. In Part 2 of this series, I’ll explain how to export and edit your GEDCOM file so that it has a better chance of importing into a different application with most data intact.
21 Dec 2015: Added Circumcision, Father Relationship, Mother Relationship, Secondary Name, and Separation as a user-defined fields. Changed the information about Source Comments.
22 Dec 2015: Clarified how FTM exports the multimedia Description field.
26 Dec 2015: Corrected the advice about Weblinks. Changed “Secondary Name” to “Namesake.”
28 Dec 2015: Added “Primary photo for a person” as a user-defined (aka custom) fact.
2 Jan 2016: Added a credit to Tamura Jones.
9 Jan 2016: Made several additions to the article, as indicated throughout.
23 Jan 2016: Added information about FTM’s use of illegal concatenation and continuation tags on citation detail fields in exported GEDCOM files.
25 Jan 2016: Edited the paragraph about Source Citations.
3 Mar 2016: Now that FTM has been given a new lease on life, please see my post, “Should You Stick With Family Tree Maker?”
5 Jan 2017: Changed the information about the Also Known As field and web URLs in source citations, based on changes in FTM 2014.1 and 3.1.