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 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 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.
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.
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.
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:
fatherwill imply that the reciprocal relationship is
daughter. And NPSP will automatically create a record representing that reciprocal relationship.
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.
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.
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.
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.
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.
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.
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:
RE data areas where we've encountered this situation:
primary alumnidata
primary businessdata
relationshipdata
Personsinto 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:
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.)
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.