Raiser's Edge Migration Tips
Most of the information you will read here is based upon the assumption that you are either personally familiar with the migration process or working with a consultant who is well-versed in data migrations regarding Raiser’s Edge. Some of the ideas and best practices may seem complex or overwhelming. Don't expect to know and memorize all the words, steps, and information below, but use this information as a guide. Read through the recommendations a few times to make notes and prepare questions.
Raiser’s Edge Terminology
One of the most important things you can do early in the process is to familiarize yourself with how terms translate between Raiser’s Edge and Salesforce. Here is a typical use-case chart I normally start with:
Constituent Migration
Once you’ve taken a few deep breaths and looked those terms over a couple of times, you’re ready to start planning. There are a few things I always consider during a migration from the constituent module in Raiser’s Edge to Salesforce. Along with the new terms, it’s important to familiarize yourself with the types of fields you’ll be pulling data from. The key indicator field is aptly named because it’s the key to pulling out household contacts instead of organizational account records. Even more important than the key indicator field is the Constituent ID. This field allows you to tie contacts and organizations to gifts, attributes, campaigns, and everything else in Salesforce. Depending on your familiarity with Raiser’s Edge, you could choose one of two options for extracting your data.
- Export your data through a data export and separately export an Organization Export and Constituent export.
- Use a Constituent Query and create separate queries for Organizations and Constituents using the key indicator field to segment them.
Either way, it is important when you export all fields to also go through and choose the fields you want to migrate.
Creating Households from Constituents
Personally speaking, I find the next step of creating households to be the trickiest part of a Raiser’s Edge migration, depending on a few factors. If your constituent spouse records are name fields without their own unique constituent ID, you are golden. You can use the primary constituent to create the account record and attach the spouse directly to the household using that primary constituent ID. If your records have both constituent and spouse with separate constituent IDs, it’s a bit more tricky to do this. In the past, I have created a new field on all constituent records and created a unique ID to tie all household members together so that when I go to migrate and create households, I can use that unique ID to tie them all together in a household account in Salesforce.
Relationship Migration
Migrating Relationships out of Raiser’s Edge can also be a tricky part of the process. With Salesforce, Relationships are split into Affiliations and Relationships.
- Affiliation = Relationship between Contact/Constituent and Organization Account
- Relationship = Relationship between two Contacts/Constituents
Be aware that when you create a data export from Raiser’s Edge, it will list one relationship multiple times. Since a unique relationship ID is hard to find, you run the risk of exporting the same relationship twice (Berkeley Baker - Arkus, Arkus - Berkeley Baker are treated as separate relationship records in Raiser’s Edge).
Attributes / Constituent Code Migration
When migrating Attributes and Constituent Codes, consider how that data needs to be reported on or stored in Salesforce. If your Constituent Codes overlap, or you need to track an active vs former status in Salesforce, I would create a custom object to house that constituent code data. Creating a custom object allows you to track both current and former attributes/constituent codes with date ranges using the Constituent ID to attach those to each person. It allows you to easily see both current and former “groupings” for migrated constituents as well as easily report on that data from records in Salesforce.
If date ranges are not associated with your constituent codes, then a mere checkbox field on the contact would suffice. For example, creating a Major Donor checkbox on the contact and checking that box in Salesforce could be an adequate replacement for a Major Donor Constituent Code migrated from Raiser’s Edge. Before migration, it is also important to make sure this list is cleaned and up-to-date so that you are not importing any unnecessary data.
Gift and Campaign Migration
Gift Migration from Raiser’s Edge to Salesforce is mostly about making sure you are creating the appropriate opportunity types in Salesforce with your legacy data. The gift type field from Raiser’s Edge is key in determining what opportunity record type you plan to migrate that historical gift to in Salesforce. Here are more terms to consider:
- Cash = Donation
- Recurring Gift or Recurring Gift PayCash = Recurring Gift
- MG = Matching Gift
- Pledges or PayCash = Pledge (Opportunity Record Type) and Pledge Payment
A common use case I have found for non-profits is the ability to track pledges separate from donations and have a specific pledge balance report. I have normally created a custom opportunity record type for Pledge and migrated all historical pledges there. That way, I can create a Pledge report from those gifts and track the pledge balance and payments more efficiently. Campaigns and Appeals that were separate in Raiser’s Edge can be combined in Salesforce into the Campaigns object.
Depending on your structure, you may be able to migrate campaigns into Salesforce as parent campaigns and migrate your appeal structure as sub-campaigns beneath those parent campaigns. Campaign mapping can be one of the most complex parts of a data migration because it often requires you to rebuild the structure for legacy data as well as future data. When I create the new campaigns in Salesforce, I will generally try to tie the appeal from the Raiser’s Edge gift as an external ID to the Salesforce Campaign so that it’s an easy way to tie those Campaigns to gifts when I migrate that data.
Do you have any tips or suggestions to help with Raiser’s Edge data migration? Feel free to comment below, on the Salesforce Success Community, directly at me on Twitter @berkeley_t_b.
