Blog
January 8, 2019
Moving from one CRM system to another is never easy. There’s all the new and different functionality to learn and explore, the new lingo to figure out, and the biggie—data migration. Future business processes and the mapping of your data go hand-in-hand. No matter what your business processes will be, there are features and functions in Raiser’s Edge (RE) that most organizations use when they move to Salesforce (SF). Here are 10 tips for planning for your move to SF that apply to most RE users.
1. Relationships
- Review the relationships in Raiser’s Edge (RE) and decide which relationships are worth keeping. (Are relationships and reciprocal relationship fields required/are they consistently populated?) Either delete or don’t extract for conversion the relationships you don’t need.
- There is no such thing as a “non-constituent” in Salesforce (SF). It is, or it is not; there is no in between. Ideally, you already completed this in the step above. Take the relationships you deem important and where you see non-constituents, turn them into constituents.
- Review relationship and reciprocal relationship code values and clean them up (do you have “husband”, “wife”, “spouse”, and do you really need all three?).
- People to People relationships from RE are relationships. Org to People relationships from RE are affiliations. There are no Org-to-Org relationships in SF “out-of-the-box”. There are ways to handle this that aren’t too difficult to set up, but just know that you’re going to have to manage this.
2. Attributes
These seem harmless enough. They are just custom RE fields, right? They are actually lots and lots of “child tables” and you are going to have to find a home for each one you want to keep.
- The first thing is to figure out where they are lurking: Constituents, Gifts, Events, Event Participants, etc.
- Once you know where they all are, decide which ones you need to keep. Can some be left behind because they haven’t been kept up or used in a very long time?
- Where will these attributes go in SF? You’d be surprised how varied the target locations can be. Attributes can end up getting turned into simple picklist fields on contacts, or campaigns and campaign members, or even affiliations. But these all require careful mapping and prep work to prepare the load files.
3. Constituent codes
You are going to need to do the same kind of work you did with attributes. What condition is the constituent code table in? Is this a short, clean list or a long one with redundant values, some of which haven’t been used in ages? Are you using these not only to characterize an organization or person (“Foundation”, “Parent”), but also track their association with your organization (Trustee 1/1/2007-12/31/2008)?
- How many constituent codes are actively being used and which ones do you really need? (This is a recurring theme, if you haven’t noticed – do you really need that? Not suggesting you discard necessary data, like GIFTS, but moving to a new system is a great time to trim the fat and get rid of lots of old, bad, and unnecessary data.)
- Where will these go in SF? Primary constituencies often lend themselves to the org type and contact type picklists, but then you’ll have to figure out what to do with all the other values, especially the ones like Trustee, that contain start and end dates. Those may also end up being affiliations, but the main point here, as with attributes, is planning, mapping, and prep work.
4. Is spouse flagged?
Yes, this is on relationships, but I mention this separately because this will do two things for you.
- Use this to make sure you really have one spouse/partner per “household.” There is a constraint in RE that will prevent you from having more than one “is spouse” relationship flagged per person.
- The “is spouse” flag can be used as the basis to create household accounts in SF. (You can have the “is spouse” flag checked and the relationship/reciprocal values can be “Partner” or “Spouse/Partner,” whatever you like. The main point is that RE treats them as a household if you are using the flag. And you can then build your data pulls based on this as well.)
5. Addressees/salutations
There are two configurable fields on the Household account in the Nonprofit Success Pack (NPSP): the formal greeting and the informal greeting. You can configure those and that’s the “formula” that is used on all Household account records. You can manually override as necessary. Other than that, there is no true comparable functionality in NPSP like the addressees/salutations formulas in RE.
- Are addressees/salutations in RE heavily used by your organization? If so, do you need to bring over all addressees/salutation types, or just some of them? You will need to pull the text version along with the type.
- Once you know which addressees/salutations you wanted, what’s the long-term game plan? If addressees/salutations are used heavily, but only a few types are used, then you can probably live with some custom fields on the contact and the household. If there are many, many types of addressees/salutations, it may be best to consider a custom object to house them. And no matter where these fields are located, the auto-generation of the values within them needs to be built out. There may be staff in-house who can build some processes that will do that, or you may need assistance.
6. Campaigns
The term “campaign” causes a lot of confusion between the two systems. RE has campaigns, appeals, and packages. SF has a hierarchical system of campaigns, and the most common way of moving data over is to move appeals and packages (see below) to SF campaigns. So, what to do with RE campaigns? It depends on how they’re being used in RE. If you use RE campaigns as overarching marketing efforts, and appeals roll up to specific campaigns, then you can likely convert your RE campaigns as SF campaigns. Some organizations use campaigns as reporting buckets, and their campaigns and appeals relate in a mixy-matchy way, where any appeal can be associated with any campaign. Does this describe your organization?
If you are in a “mixy-matchy” situation, any appeal can be associated with any campaign, or some appeals can be associated with several different campaigns, there is no true comparable feature like this in NPSP. However, you are not without options. You just need to have a plan. Will a custom field somewhere be adequate, or do you need a full-blown custom object? Do you have an internal team who can build this out for you, or do you need help? How you use the field in RE will have an impact on how you build your solution in SF.
7. Appeals/packages
Appeals and packages, as noted above in section six, typically move to SF campaigns. If you are not using packages in RE, this will be a pretty straightforward move. If you are using packages, it will take some planning to move everything over so you can report on them how you would like. (Packages are not required to have unique names in RE based on the appeal they are associated with.)
8. Addresses
Yes, you can bring over multiple address types and old addresses, but how many do you really need? Also note that in NPSP, the address object is connected primarily to the Household, and then the default (RE preferred) address “rolls” to the contacts in the Household (unless a contact is tagged so this doesn’t happen). All other addresses reside in the address object, which is connected to the Household. If you have addresses that belong to one specific contact only in the Household, and it is not the default address for the contact, or are a business address that needs to be associated with the employer info as well as the contact, you will need custom configuration to accommodate this.
9. Phone numbers/emails
There are a set number of phone and email fields available in SF, and they are for current values only. If you have a lot of different phone and email types, think about whether you really need that many. (Do you need “Assistant’s Summer House Fax Number”? Do you have “Home,” “Home Phone,” and “Home Telephone”?). If you do,
- Clean up your types so they are consistent and not redundant
- Find additional places to store them. These may simply be additional fields on the account or contact.
If you are in the habit of keeping old or invalid phone numbers and email addresses, consider whether you need to continue to do this. If you decide that you do, (and there may be legitimate reasons to do this), you will need to find a place (such as a custom object) to store these and come up with a plan to move outdated phones and emails to this place when new phones and emails are added to a record.
10. Deduplicate records
Definitely run a deduplication job on your records, especially if non-constituents from relationships have been turned into constituents. There are deduplication processes in SF, but the overall conversion and validation process will be less confusing if these have been deduplicated before attempting to move the data.
Still feeling confused? Get help! There are lots of former RE users on the Power of Us Hub who will be happy to share their experiences. There are Salesforce User groups in many metropolitan areas where you can solicit advice and suggestions from others. And if the kind of assistance you need is more hands-on, there are many, many Salesforce consultants (it’s a popular system)! Whether technical, business process design, nonprofit expertise, or all of the above are desired, we have consultants and implementation partners who are ready to help. Contact [email protected] to learn more.
_____________________________________________
Wendy Jaccard
Principal Consultant, Salesforce Services Group
Attain Partners
Wendy Jaccard is a Principal Consultant at Attain Partners. Attain Partners is a management, technology, and strategy consulting firm delivering market-leading results to customers in education, nonprofit, government, and healthcare. Wendy has developed deep expertise in Salesforce and has worked with many nonprofit organizations and higher education institutions to help them achieve their missions by engaging their constituents in more efficient and effective ways. Specifically, she has worked on many implementation projects involving Salesforce and Raiser’s Edge data conversions while at Blackbaud, Inc. and Attain.
