Why I don’t sync RootsMagic with Ancestry, anymore.

Keeping my RootsMagic (RM) data and Ancestry data consistent is made simple by the TreeShare functionality in RM. Any work done on Ancestry, such as attaching documents to a profile or adding facts to a person, can be synced to RM without needing to manually reenter the data. Copies of the attached documents are downloaded to a designated RM folder, and citations created by Ancestry are transferred into RM.

While this functionality sounds excellent and timesaving, in practice, the data ported into RM is often of low quality and, in my opinion, unusable. I find myself having to track down every alteration to my RM database to make corrections or deletions. The changes that are imported into citations, locations, images, and fact types are all problematic.

Citations

My biggest issue with the sync process is the citations created by Ancestry. They are non-standard and do not follow Evidence Explained, the Chicago Manual of Style, or any established genealogical standards. Here’s an example of a citation brought into RM from an Ancestry sync:

“Ancestry.com, London, England, Church of England Births and Baptisms, 1813-1906 (Provo, UT, USA: Ancestry.com Operations, Inc., 2010), London Metropolitan Archives, Hampstead St Paul, Register of Baptism, p81/pau, Item 001.”

Every citation starts with “Ancestry.com,” which is unhelpful. When I see this citation, I can’t immediately tell who it was for or when the event took place. This “citation” is not useful for anyone reading my family history, as it doesn’t provide enough information to locate the original record.

To improve on the synchronization, I must delete the Ancestry-created citation and write a proper one, such as:

Camden, England, baptism register, record no. 129 on page 23, Maude Jane Corderey, 14 June 1866; digital images, Ancestry, “London, England, Church of England Births and Baptisms, 1813-1923” (https://www.ancestry.com/search/collections/1558/ : accessed 17 August 2024) > Camden > St Paul Hamstead > 1860-1917, image 12 of 202; The London Archives.

This reworked citation demonstrates how much helpful data is missing from the Ancestry-created version.

Since every Ancestry-created citation brought into RM through the sync process requires correction, there’s no reason for me to sync the systems.

But that’s not all. Deleting the Ancestry-created citation isn’t enough. The sync process also creates a source on which that citation depends, which also needs to be found and deleted. Often, there are multiple entries for the same Ancestry database, leading to unnecessary duplicates that need to be merged or deleted.

Why are there four different sources for the London Birth and Baptism database on Ancestry? Why are the dates different when this is all the same Ancestry source? Determining which sources to delete or merge is another unwanted sync byproduct.

Locations

Ancestry locations lack uniformity. Place names attached to Ancestry digital images can vary significantly—sometimes including just a city, sometimes a state, and sometimes a combination of city, county, and state. Sometimes names are abbreviated and sometimes not. These variations, along with frequent misspellings, are all imported into RM. Here’s an example of location pollution in my RM database:

Note the different spellings of Hallows and Hollows. These five entries likely refer to one location—All Hallows Parish pre and post the Revolutionary War. This means I shouldn’t merge all five options into one without understanding the timeline of where these locations are used. I need to carefully trace where these locations are used and then merge them into two standardized options.

This location name pollution is another unwanted byproduct of syncing.

Images

Another feature of TreeShare is that all documents attached to Ancestry are downloaded into a designated RM folder. Although this sounds super convenient, it requires significant rework.

When the documents arrive, they have Ancestry-derived filenames like:

• ohvr_d_1913_4-2856.jpg
• rhusa1862_101678-00364.jpg
• 4123466_00175.jpg
• 40340_1220706416_0388-01669.jpg
• sid_131933_1949_0018.jpg

What do these filenames mean? What type of documents are they? Who are they for?

To make sense of this, I need to trace where each document is attached in the database. Then I locate the original file on my computer and rename it according to my standard naming convention, such as:

• 1930 NY Westminster Yonkers – Clapp family
• Birth – OH Madison – Benjamin F Walker 1923

My file naming system includes the type of record, the place the record was created, a year, and some information about who the record applies to. At a glance, these names provide clear information about the record type and purpose. However, renaming the files on my hard drive will break the link in RM.

But then what about my digital filing system? All my digital documents are organized into surname folders. Under the main family folder, there are subfolders for vital records, census records, military records, newspapers, etc.

Moving the file to the correct folder without renaming it will also break the RM link. This can be easily remedied by using RM’s “Fix Broken Media Links” tool. But if the file is renamed, the relinking tool won’t be able to find it. All imported documents need to be relinked manually by finding the newly renamed and repositioned digital file.

But there’s more. The original synced document still has a thumbnail image in the RM media tab that now shows a broken link with a red “x” in the lower right corner. The final step in correcting all the unhelpful Ancestry filenames is removing the thumbnail remnant. In the Media section of RM, highlight the thumbnail and click the trashcan icon.

Fact Types

Ancestry has facts like birth, marriage, and death. These facts translate easily in the TreeShare sync. But all census facts in Ancestry are listed under “Residence.” Yearbook sources are also shown under the fact type of “Residence.” Ancestry also lumps Draft Cards into the same “Residence” fact. Ancestry uses the Residence fact type for many non-vital records.

When syncing, RM imports data using the same fact types assigned by Ancestry, which is unsatisfactory for me. I prefer to categorize census records under the Census Fact Type, yearbooks under the Education Fact Type, and draft cards under a custom Draft Fact Type.

This is another unwanted byproduct of syncing RM and Ancestry. Each person’s profile altered by the sync needs to be reviewed for fact types that may need adjustments to maintain data consistency.

What I do instead of TreeShare syncing

In my experience, syncing RM and Ancestry creates a lot of cleanup work. The citations are non-standard and uninformative. Locations need to be merged into a standard that includes all location parts. Images need to be found, renamed, repositioned, and then relinked. Then the fact types need to be scoured and corrected.

The pollution created in each of these areas of RM is too much for me.

What works better for me is using a two-screen system for manual data entry. On one screen, the RM database is open; on the other, Ancestry, FamilySearch, Newspapers.com, county websites, or any other online sources are open. When a record worth including in my database is found, all the details are entered manually.

For example, if I find a 1779 birth record in Westminster County, New York, (note the genealogy humor) for Abigail Rainmaker, I will:

1. Open Abigail’s profile in RM and create a birth fact.
2. Enter the fact date as 1779.
3. Enter the location of Westminster County, NY, which is likely already in my database. Using the same previously created location maintains consistent place names.
4. Create and attach a citation that adheres to standard genealogical templates. I use copied versions of the helpful RM templates.
5. Download the document image from the source website, rename it according to my standards, and move it into the appropriate folder (e.g., Rainmaker > Vital Records).
6. Back in RM, open the image section for the birth fact then drag and drop the new image into RM.
7. Done.

This process involves many steps, but it ensures that a clean RM database is maintained with consistent standards. In my experience, the TreeShare sync shortcut isn’t worth it because it creates too many issues that require time-consuming and aggravating cleanup. Finding and correcting the many TreeShare issues requires more steps than my manual data entry process.

I used to sync RM with my Ancestry trees but was always dissatisfied with the unwanted byproducts. When RM 8 was released, I decided to start fresh with a genealogy do-over, aiming to create a squeaky-clean and consistent database. To achieve that goal, I banned TreeShare syncing. However, the fault for unclean data lies with Ancestry, not RM. Ancestry-styled citations are unusable, their filenames are uninformative, place names lack consistency, and their fact types are limited. All these Ancestry-based problems are brought into RM through syncing. The TreeShare function in RM would work better if it had a cleaner partner to work with.

I’ve been a fan of RootsMagic since version 5. It provides an excellent database system with great tools and reports for managing my genealogy work. Creating manual entries is made easy thanks to RM’s thoughtful programming. The fact type list is more comprehensive than Ancestry’s, and creating custom fact types is simple. When entering a location, RM suggests entries already in the database, which cuts down on work and inconsistencies. The CountyCheck feature is a helpful verification tool. The source templates provided by RM are extremely useful, and I copy the originals so I can make modifications when needed. The drag-and-drop feature for adding images is a breeze and prevents the need for many clicks when hunting through the folder tree. Best of all are the many report outputs that make all this manual entry worth the effort.