* Switching tips? (RM->FH)

[strathglass]

I'm thinking of switching to Family Historian from RootsMagic (using RM7 and tried RM8).
This is largely because I personally find RM8 is just not as easy to use and navigate as FH7.

I have been testing FH7 using the free trial and found general use is much easier for me than RM8.

Mainly I am looking for any tips on any cleanup or changes I should do in RM7 before finally switching for good. Pointers here?

Any other points to be aware of in my situation?
Any specific limitations (or differences) in FH7 vs RM7 that I should know about?
Anyone want to talk me out of this? OK, I don't think I would find anyone on this forum to do that!

[tatewise]

I've moved this to the Importing and Exporting forum.

Have you seen the FHUG KB advice Importing to Family Historian which has both generic and RM specific advice?

[Sallion]

I'm in the same boat. I liked RM7 but couldn't get on with RM8 so decided to move to FH7. The issues I've found so far are with sources/source templates, RM7 had two levels but FH7 has three. This confused me for a while but there is a plug in you can get which will sort this out 'Create Source Template Definitions'. FH7 also works better if you're a splitter with your source citations, I'm a grouper so I'm still working my best strategy for this. The other issue I have found with FH7 is to do with maps. It will map any place field and this includes those from sources. I personally don't like this as I don't think the publication place of a book should be geocoded but if you don't use geocoding this may not be a problem.
The query feature is brilliant although again can take some getting use to especially if you're used to SQL type queries.
My suggestion is to run the two in parallel for a while as you can easily import the RM data into FH and then sort out one area at a time.
If you do find any problems the people on this site as very helpful. Calico Pie were also very helpful when I found a bug with Julian calendar dates and fixed the problem quickly.

[kevync1985]

I have been using RM8 Since it was preview edition. I ran both for a couple weeks before using RM8(Preview) entirely. Between 2004-2021 I used FTM. I was not used to RM7 so that was not an issue for me. I am glad I switched to RM when I did. However, what I am trying to do is to focus my research. While I am fairly comfortable with SQL(SQlite) queries, the query builder is very powerful and doesn't require you using another interface. so I am in very similar scenario.

The one question I have at this point is Shared (Witness) Facts -- Mostly I use for Census. Curious what FH use/prefer. I saw there were plugins to convert shared facts to non-shared. One of my other projects down the road will be to rebuilt Sources and Citations from scratch.

Kevin

[tatewise]

Kevin, please post your question about Census Fact Witnesses, etc, as a separate topic as it is straying off the topic of this RM import thread.

[jnunnally]

I'm working on an import/transition from RM7 to FH7. Most things here apply to RM8/9 as well.

All in all, it is amazing how well my RM data transferred with the FH7 direct import. More importantly, FH7 provides a framework where the imported RM data can be utilized as it is. However, that does not mean your RM data and the RM way of doing things complies with "best practices" for FH7. My impression is if someone tries to simply continue using their RM data in RM ways in FH7, it will be very much like swimming against the current. RM and FH7 are conceptually different. As the old carpenter says, "its works best if you use the right end of the hammer."

Here are a few issues you will encounter with your RM data import to FH7:

If you have exploited features of RM's Fact sentence structure, FH7 does not translate everything. The FH7 sentence building tools are extremely powerful but with that comes a little more complexity. I did quite a bit with RM sentences and so far I have been able to translate and even enhance my fact sentences in FH7 but it took some time and there is a learning curve.

• The RootsMagic "switches" structures don't translate well but there are FH equivalents.

• References to data in the RM "Desc" field may need attention. Since RM does not allow the note field in sentences, RM users have shoehorned all kinds of things into Desc. Generally [Desc] is imported as {cause} in FH7. {value} may be substituted if {cause} doesn't fit your fact definition. Usually, the needed adjustments are not difficult and the ability to include {note} and {inline-note} in FH sentences helps a great deal. Its what RM users have wanted to do for a long time.

• The Rootsmagic [Husband], [Wife], and [Spouse] values do not translate but there are FH equivalents available.

• [Place] and [PlaceDetails] translate to {place} and {address}, but FH handles punctuation and spacing differently, so adjustments may be needed.

• References to people in roles like [Bridesmaid] do not translate, but they can usually be replaced with the FH {role=Bridesmaid}.

• If you refer to a person's age with [Person:Age] or [ThisPerson:Age], RM calculates the age of the person using the date of the fact and a birth date, if available. This RM reference imports as {age}, but that refers to the age field of the fact. Since RM does not have age fields for facts, this will never produce a value. There is a function in FH that will calculate the person's age as RM does that will produce the desired result.

Some RM features that don't have a FH7 equivalent get transferred as "metafields." For example in Source fields, RM allows a full version and an abbreviated version of the data to appear in the same field separated by "||". The abbreviated portion of these fields is written to the citation note as a metafield. These metafield values can be referenced with the GetLabelledText function. Another example is RM WebTags become metafields in the FH citation note field.

RM Alternate Name facts have associated dates and source citations. If you import alternate names as facts, the sources will not be attached to the imported FH fact. If you also import the alternate names as secondary names, the citations will be attached there. If you import alternate names as facts the date will appear in the imported fact, but there is no provision for a date for an FH secondary name. Having a date associated with a name is not part of the GEDCOM standard.

Almost all of my sources are based on custom RM source templates. They all imported and with the exceptions mentioned here, they imported very well and work in FH7 the way they work in RootsMagic.

Some source template footnote/bibliography formatting does not come across. In this case there are some issues for which I have not found an equivalent. 1) Citation fields cannot appear in bibliographies. (In FH's defense, they seldom should!) 2) The [Place:REVERSE] RM construct returns the place parts reversed, separated by periods (full stops). This is EE standard for Bibliography entries where the place is the leading element. There is a FH7 function that reverses place values, but it returns them separated by commas.

That has been my experience thus far. I'm sure there will be other things not yet discovered, but all in all, the import was extremely complete and I'm very impressed with how robust the FH7 options are for taking care of differences.

How far I want to go converting my data and workflows to better suit FH7 is the more difficult question and it comes with more involved answers. I have a lot more work to do in this regard.

[Gary_G]

"strathglass";

While you can do a lot of cleanup in FH7 after import, I'd advise taking a look at the issues people have noted and try to revise your records (to the extent possible) in RootsMagic before importing to FH7. The reason is simple; at this point you're still more familiar with RM and more likely to revise things quickly and more accurately.

I should note that, if you are a Lumper (as many RM refugees are), then you might want also see if you feel capable of re-jigging your records to be those of a full-up Splitter prior to import. That is; one document maps to just one source and that source is attached to all fact/events it supports. While FH7 can actually handle both styles, I think you will find it easier to work with as a Splitter. Trying to do the change-over in FH7 is quite a task for a newbie. While FH7 has some plug-ins that can help, you still have to know what you're doing to use them. You actually might feel more comfortable doing it in RM prior to importing to FH7.

My previous suggestions are predicated on the assumption you don't want to start by re-entering your data using an FH-related tool like Ancestral Sources (AS). For a complete re-do, however, I understand it is a rather good tool to use. If you want to consider doing that, then forget worrying about preparing the database for export, read up on Ancestral Sources and in the knowledge-base about source-driven data-entry, then port away!

[jbtapscott]

"strathglass";

While you can do a lot of cleanup in FH7 after import, I'd advise taking a look at the issues people have noted and try to revise your records (to the extent possible) in RootsMagic before importing to FH7. The reason is simple; at this point you're still more familiar with RM and more likely to revise things quickly and more accurately.

I would second your comment about trying to revise in FM. I moved from TMG to FH several years ago and spent well over three months modifying data in TMG / importing to FH / modifying data in TMG / importing etc etc. As I moved through almost daily imports (I am retired so had the time!), I also logged issues that I could not resolve within TMG such that when I made made the "final" cutover I had a series of tasks listed that I needed to complete within FH. As I became more familiar with FH during that 3+ months a number of issues in that list also got removed as I gained a greater understanding of the functionality offered and the way FH used the data.

[jnunnally]

I have already done more than one port of my RM7 data to FH7 and I have not made the final port yet. But with these test ports, I have spent quite a bit of time getting familiar with the FH7 user interface. In the process, I found that FH7 helped me locate areas where my RM data needed attention. If you are more comfortable with your current program for making changes, FH7 may still help you locate what needs to be changed.

[Gary_G]

I'm still in the process of switching from a Lumper in RM9 to a Splitter in FH7.
But here's how I plan to do it, if it is of use to anyone...

I ended up importing a copy of the best I could get out of RM9 and then removing all sources and repositories from within FH7.
That left me with essentially just my facts, addresses and places.
I have developed and new Splitter templates that work in conjunction with data in a selected repository and with AS. So I will set those up in the project.
Next I'll do a pass over the places to ensure they are all geocoded correctly and have a standard format.
In preparation for using Ancestral Sources for data-entry, I will remove any auxiliary facts like Occupation and Residence.
That type of fact will get regenerated when I do other BMD and Census events and removing them now precludes duplicates and legacy ones.
Then I plan to flag all remaining facts as "In Progress". Apparently the flags will not affect the operation of Ancestral Sources.
Once I start entering data with Ancestral Sources, I should be able to simply verify the data in existing facts and augment it as needed.
Letting AS write the updated fact back out and possibly overwrite the pre-existing event is exactly what I want to do.
That action will bring the data up-to-date and also effectively reset the associated fact flag.
When I'm done, I should have few fact flags left. Those that do still exist will have to addressed manually.

Well, that's the plan and, as we all know; "no plan survives the first encounter with the enemy"...

[jnunnally]

RootsMagic users may not be familiar with the difference between EVENTS and ATTRIBUTES as they are defined in GEDCOM and in FH. There is a specific list of EVENT tags defined in GEDCOM. Included are births, deaths, marriages, census, burials, etc. There is also a specific list of ATTRIBUTE tags including DSCR (physical description), OCCUpation, RESIdence, etc. Fundamentally, attributes have a VALUE associated with them where EVENTS do not.

RootsMagic lumps EVENTS and ATTRIBUTES together, generalizing them as FACTS. RootsMagic provides for the difference in the two with the optional Description field to contain the value for the Attribute facts. However, RootsMagic does not restrict using the Description field to just the ATTRIBUTE fact types. Thus many RootsMagic users activate the Description field for fact types that should actually be EVENTS and then use the contents of the Description field for all sorts of purposes.

If you have used the Description field for ATTRIBUTE fact types only, then converting your data to FH will probably work better. However, if you have used the Description field with EVENT fact types, then FH can't import them as EVENTS. To retain the data you have in your Description fields, FH has made the decision to import all fact types that have a description field as ATTRIBUTES. This means (for example) that you may have birth attributes instead of birth events.

It is not clear how this confusion of attributes and events may affect how my RM data works in FH, but starting out with this non-standard data formatting is something that RM users may need to address before converting. I would like to get some feedback from FH folks about what problems we might encounter.

[tatewise]

It is not clear how this confusion of attributes and events may affect how my RM data works in FH, but starting out with this non-standard data formatting is something that RM users may need to address before converting. I would like to get some feedback from FH folks about what problems we might encounter.

Many features of FH (and most other genealogy products) depend on the Standard FH/GEDCOM Events such as Birth, Baptism, Marriage, Census, Death & Burial.
e.g.
If there is no Birth Event then FH cannot calculate & display the Age of the person and cannot perform any validity checks on their Age at Marriage or Death, or the Birth of children.
Diagrams and Reports have fact descriptions and Sentence Templates predefined for all the Standard FH/GEDCOM Events that will need equivalent definitions for the imported Attributes.
Many plugins rely on the Standard FH/GEDCOM Events so won't work with the imported Attributes.

The Change Any Fact Tag plugin can convert those Attributes into Standard Events but will move the Value to the Source Note field. Then you must decide where that Source Note needs to go ~ maybe the local Note field or Address field.
Alternatively, those Attribute Values need to be moved before using the plugin, which may need a custom plugin.

[Mark1834]

The Ancestry GEDCOM export does something similar - exports custom Attributes as Events, with the value in the Note field. I convert them back to Attributes with the Change Any Fact Tag plugin, and have a simple custom plugin to move the Note back to the value.

[Gary_G]

[If there is no Birth Event then FH cannot calculate & display the Age of the person and cannot perform any validity checks on their Age at Marriage or Death, or the Birth of children.

Mike;
Just a quick side-quick question...
I believe RM9 will use a Christening event date as a birthdate for the calculation, if the Birth event is missing. I didn't see anything similar mentioned in the FH7 documentation. Based upon your post, I take it that FH7 does not do this?

[tatewise]

Gary, that is correct as far as automatic Age calculation is concerned.

[cwhermann]

I also migrated from RM7 and am still in the process of cleaning up citations and fact sentences because of issues noted by others. I am also facing a major clean-up of my place records, not because of the transition. I needed to clean up my places in RM before the move, but I decided it would be easier in FH.

I am one who has retained the custom lumped source templates I used in RM. Yes it took some clean up and "adapting" the lumped sources templates to the FH software, but I felt it was still less of an effort than starting over or using the plug in to split them. Additionally, it fits better with the way my mind works.

I have not found any issues in using method 2 once you get the templates set up. I understand there may be some issues if I want to use AS at some point.

The "Where Used Record Links" plugin has become invaluable in my transition process.

[NickWalker]

I have not found any issues in using method 2 once you get the templates set up. I understand there may be some issues if I want to use AS at some point.

The version of AS that is currently being tested now supports using Source Templates with Method 2 (lumper) sources.

[cwhermann]

I look forward to working with AS once I get my “transition cleanup” completed and I can refocus on data entry.

[MFriend]

This reply is probably too late for the original OP, but for others moving from RM to FH.

One function that I found in RM 8/9 to be outstanding is the place clean (and maybe the name clean) feature. I had thousands of place names that were so messed up from combining Ancestry sources and FamilySearch sources. I often would have a half dozen different variations of the same place (caps, not caps, missing the county, missing the county, etc.). I found RM to be more efficient than any other software to clean up and standardize these places. (you can for example have it search it's database and put United States or USA on all locations in the USA in just a minute or so). Same for places in Germany, etc. So my suggestion is that before moving to FH from RM, make sure you have cleaned up your places....

[Vyger]

One function that I found in RM 8/9 to be outstanding is the place clean (and maybe the name clean) feature. I had thousands of place names that were so messed up from combining Ancestry sources and FamilySearch sources. I often would have a half dozen different variations of the same place (caps, not caps, missing the county, missing the county, etc.). I found RM to be more efficient than any other software to clean up and standardize these places. (you can for example have it search it's database and put United States or USA on all locations in the USA in just a minute or so). Same for places in Germany, etc. So my suggestion is that before moving to FH from RM, make sure you have cleaned up your places....

I would echo this advice, when I first migrated to FH I became aware of many problems needing resolution back in Rootsmagic so my migration path was Direct Import > Clean Rootsmagic > Direct Import > Clean Rootsmagic >

The NameClean and PlaceClean utilities mentioned were a good initiative but like so many Rootsmagic features not refined to being completely useable. One big example for me was NameClean reporting McK and Mac spellings incorrectly so I always had hundreds of false positives on that list and no way to teach Rootsmagic Rules.

[Gary_G]

In RM9 I've used the "Alternate Name" fact, which has modifiers to say what type of alternative name it is. I understand that this doesn't port well to FH7. Is there a way to specify this info in RM9, so that FH7 will understand and store it as FH7 would normally?

[Mark1834]

My usual recommendation in these circumstances is to generate a simple test database in RM so you can experiment with which option you prefer.

The core issue is that RM allows dates to be included in name facts. This can be very useful, for example tracing name history over time, but is not GEDCOM-compliant. When importing an RM database, FH gives you the option of saving alternative names as just names (undated, the way FH does it by default, with the dates moved to a note), alternative name facts (which keep the associated dates), or both.

In both cases, the name description is saved, as in the screen grab below for the import of a one-person database, John Smith aka Mary Jones.

Capture.PNG (16.32 KiB) Viewed 799 times

[tatewise]

Gary specifically mentions the name type which is illustrated in Mark's screenshot as the Name Type field.
That does have some support in FH V7 because it is a standard GEDCOM 5.5.1 field.
i.e. It can appear in the Property Box tabs, can be used in Queries, can appear in Diagrams and Reports but with a few caveats.
So it depends on exactly what support you are expecting.

The Name Date field is more of a problem as explained by Mark.

However, there is light in the tunnel because GEDCOM 7.0 allows a defined extension _DATE field to be added to the NAME field and gives an example of how to achieve that.

[Gary_G]

Mark1834 & Tatewise;

I tend to prefer trying to represent my data as FH7 currently does, since I know CP tries to stick to the GEDCOM standard and that may improve future portability (if needed). So; I'll likely choose to import the RM9 alternate name facts as just other names. I think this should meet my needs. I have usually documented the actual event that caused the change in the name and I just need to make sure I can find the person by any of the alternate names.

Something in what you've both said also reminds me of a post (further back in this topic) that discussed the issue of RM9 not treating Events and Attributes differently wrt. dates and descriptions and that FH7 typically does treat them differently. Must find and re-read that. I think it may be helpful in a more general sense and save me some frustration in future.

[Gary_G]

A question came to mind regarding trying to conform to FH7's current usage of events and attributes. Is there a way in FH7 to list those "facts" that don't conform to the GEDCOM definition of event or attribute? I'd like to be able to revise those entries to look as they would had they been entered directly into FH7.

A second one is how does one handle "Occupation" attributes without resorting to specifying a date, which is typically something reserved for events?