home   about   contact   downloads   links   pricing   reading list   [salesforce]   site map  

Current loctn: salesforce > data mig > re > re index

Salesforce Data Migration - Raisers Edge

The most problematic areas of Raisers Edge data encountered in our data migrations are explained below.

A more detailed description of RE data migration difficulties may be downloaded from Key Raisers Edge Data Migration Difficulties Download

RE Multiple Addresses

RE typically allows multiple addresses to be linked to a single constituent record. Salesforce typically provides standard fields to accomodate only two addresses. (However, current versions of the Salesforce NPSP can store an arbitrary number of addresses linked to a household Account.)

As a result, it is inherently difficult to decide which RE addresses should be placed in SF address fields, which RE addresses should be discarded, etc.

In addition, RE address type designations often apply multiple values that do not neatly correspond to type designations provided as a standard in SF databases. By comparison, SF addresses are most commonly indicated to be either work or home addresses. Conversions of RE address type value to appropriate home/work values is sometimes impossible to do exactly, and an approximation might need to be accepted as the best achievable outcome.

It is a great help to restrict the data migration to include only those addresses marked as current or primary addresses.

RE Phone Records Also Store Email, Website, etc.

RE stores email addresses within the same records (labeled phone records) that are used to store phone numbers.

These same records sometimes also store website URLs, twitter and facebook account names, etc.

Multiple RE Phone Numbers Linked to Constituent/Relationship

RE Constituents and non-constituents documented only within RE Relationship records may have multiple phone numbers linked. By comparison, SF typically provides a smaller set of home/work/mobile/fax phone fields on the SF Contact object.

It is common to find phone numbers marked with type values that do not neatly translate to the SF Contact record home/work/mobile/fax phone fields typical in SF.

Determining appropriate conversions for placement of phone numbers in SF can be challenging. Development of a detailed code conversion mapping is often required.

RE Phone Numbers and Email Addresses Used with Multiple Addresses

It sometimes happens that the same phone number, email address, or website URL is stored in linkage to several addresses stored for the same person.

Efforts to detect and appropriately handled these situations can be complex and time consuming.

Inconsistent Reciprocal Relationships in RE

The SF Nonprofit Starter Pack includes a Relationships package. Relationship records are used to document person-to-person associations. Automation provided with this package typically assumes that a standard reciprocal relationship can be assumed. In the most common configuration, NPSP automation actually enforces this standarization.

For instance:

However, it is common within RE relationships data to find unusual reciprocal relationship types that often violate the expectations of the SF NPSP automation. For instance, a relationship of father might be paired with a reciprocal like owner. As a result, loading of data into SF often requires development of a detailed code conversion map specifying relationship code conversions. Those maps often will need to be constructed to eliminate nonsensical combinations of relationship and reciprocal. Complicated deduplication steps may also be required during data processing.

To minimize costs, it might be wise to accept the NPSP determination of the what the reciprocal relationships should be. But even this simplifying decision often requires a fairly detailed data examination as support.

RE Relationship Records Carry Multiple Information Items

A single RE relationship record carries multiple information items:

This data structure present logical difficulties. For instance, say a constituent is linked to an organization with a role of ceo and as a contact, and then indicates an end date value in the past. Are both the ceo and contact roles terminated by the end date value? In our experience, that interpretation is not reliable. But it might be the best intepretation available from the RE data alone.

RE Relationship Records Provide both Person-to-Person and Person-to-Organization Links

The SF NPSP provides different objects for person-to-person (the SF Relationships object) and person-to-organization links (the SF Affiliations object).

Typically, a complex code conversion map is required to indicate which RE relationship codes should be converted to SF Affiliations, and which should be converted to SF NPSP Relationship records. This code conversion will often need to indicate, for instance that an owner relationship should not be represented in an NPSP Relationship record used to document a person-to-person relationship, etc.

RE Gifts Indicating Exact Link to Matching Organization

Matching gifts in RE often contain a direct and explicit link to the exact organization that is offerring a matching contribution. SF does not typically provide this ability unless a recent version of the SF NPSP is installed in the destination system. Even in that case, additional data processing complexity is required to transfer these data correctly.

As in other cases noted here, if minimizing cost is a desirable goal, it is wise to consider whether this linkage is really needed. Most organizations using Salesforce seem to function quite well without it.

RE Attributes

RE Attributes can be used to represent custom data in tables linked to the major RE tables like Constituent, Gifts, etc.

However, standard RE Exports do not label these data clearly within the output data.

For instance, RE exports to MS-Access databases provide tables representing these data that are labeled in an uninformative fashion (Attribute1, Attribute2, etc). Because orgs using RE often have numerous Attributes in place, a laborious check of code values must be undertaken and cross-matched to values used in each RE Attribute to determine which Attribute corresponds to Attribute1, etc.

A better approach is to export each RE Attribute using a separate RE query. But this does require construction of a query corresponding to each RE Attribute that will be transferred to the new system, and this require considerable time if a large number of RE attributes are defined. And these queries must be carefully constructed to ensure that key fields are included that will allow proper joins to Constituent, Gift or other records exported from RE.

In addition, some organizations end up defining large numbers of attributes within their RE databases. In this situation, it can be time-consuming and expensive to catalog the attributes, indicate their essential characteristics, indicate which ones should be transferred to SF and construct code conversion maps defining the final values that will be transferred to SF picklist fields.

RE Gifts May Provide Undefined Campaign/Appeal Combinations

It may be natural to assume that every RE Gift will indicate a Campaign/Appeal combination that is also defined formally in the RE Campaign/Appeal heirarchy, but that may not be the case.

We have often encountered RE Gifts that indicate an Appeal which is not defined as a child of the Campaign that is indicated on that RE Gift.

If the migration goal is to accurately represent RE Gift Campaign/Appeal combinations in records transferred to the SF Opportunity object, SF Campaign records might need to be constructed by merging Campaigns and Appeals defined in the RE Campaign/Appeal hierarchy with the Campaign/Appeal combinations encountered on RE Gifts. A more simple and direct transfer of RE Campaign and Appeal records may not be sufficient.

Partial Overlap of Records in Some Data Areas

We've encountered situations where data areas in RE provide records that overlap or duplicate records in most, but not all recods. These situations might require complicated data handling to:

  1. process data from different areas in a similar fashion
  2. merge data from different areas
  3. deduplicate the combined records

RE data areas where we've encountered this situation:

  1. Constituent primary alumni data
  2. Constituent primary business data
  3. RE general relationship data

Clumping of RE Persons into SF NPSP Households

Data processing to determine how to form SF NPSP household Accounts can be complicated. We have standard automation that operates to link SF Contacts derived from RE Constituents and individuals documented only in RE Relationship records for this purpose.

However, that automation is complex. If a change in the clumping rules is desired, that can be time-consuming.

Our standard automation clumps individuals into NPSP household accounts in this fashion:

  1. If an RE Relationship record for a non-constituent spouse provides no first name (for instance, a relationship indicating only Ms. Smith), then no SF Contact record is created to represent them.

    A record like this is typically too ambiguous to justify the creation of a SF Contact record. (For instance, if Mr. Smith has remarried, there is no way to determine which of his spouses is actually indicated by the Mrs Smith record. A record like this in effect does nothing more than indicate the Mr. Smith is married.)

  2. Otherwise, if two persons are linked by RE Relationship records indicating a spouse or partner type relationship and they share the same street address, they're both represented by separate SF Contact records linked to a shared SF NPSP household Account.

    If the addresses differ, it's assumed that separate households are appropriate, and that is represented by linking the two SF Contact records to different SF household Accounts.