It’s Not Just Your Org: Why Raiser’s Edge Migrations are Difficult

Database vs. CRM

At the core of the cumbersome feeling of migrating data from Raiser’s Edge to Salesforce is this concept: Salesforce is a CRM, not a database.

A database is a data repository. It stores data, and it can be organized about it — there are tables of data and fields to hold the data. In that way, it sounds exactly like Salesforce. But it is made and designed exclusively to store the data. 

A CRM is a process management tool. Does it hold data? Of course it does; we need data to inform our processes, but it is built to show us what steps we have taken, so we can best determine which next steps to take.

That particular point of distinction seems trivial, but it has an impact when it comes to data reporting and exporting and thus the migration process.

On Joins

Whether you are in a database or a CRM, the concept of joins is important. It’s what relates data from one table to another.

In Raiser’s Edge this might look like building a report of constituents that includes all of their gifts, their phone numbers, their relationships, and maybe even the constituents on the other side of those relationships. Because Raiser’s Edge is a database, its reporting works like one -- we have at our disposal a long list of data that we can pick and choose as filters or for display. In the UI, this looks like a list; in reality, we are creating and using joins across multiple tables.

In Salesforce, we have to create those joins before we enter the data, and this is in fact a big part of the confusion and frustration that comes out of one of these migrations. We cannot simply create a table and enter data, then use a query tool to build those joins — we need to plan those ahead of time, so that we create those relationships among our data during the course of migration. This ensures that when we need to answer the question “How much did Donor A give two years ago,” we have entered the data in a way that allows us to see Donor A and their gifts from two years ago.

In addition to the requirement to plan those joins ahead of time, the structure of the data when we export it is important.

Depending on how you build your query, your export of Constituents with Attribute data may come out looking like this:

This is a problem. Point of fact, there are a couple of issues here:

• This data separates information related to the Constituent into column groups. To import data into Salesforce, it must be in rows. If this were a list of Gifts, this would be completely unusable.
• The data in the columns are inconsistent. In the example above, I have two different Attribute types listed in the same column (Eye Color and Hair Color). In order to make this in any way usable, I would have to sort multiple columns to determine type and then rework my data into a table that is consistently grouped. And also in rows.

The format of exports out of Raiser’s Edge is extremely important for creating usable CSV files to import. Even with careful planning and mapping, the above is not very clear in its purpose or contents.

Accordingly, you may need to consider running exports without any joins (one table at a time), in order to get the cleanest format for a data migration.

On Reporting

In the midst of a migration, Joins allow us to relate our data. We import Contacts (Constituents), then we import Opportunities (Gifts), and then we import Relationships with other Contacts and Affiliations with other Organizations (Relationships). And so and so on.

This part is often easy enough to follow. We are taking related data and importing them. Makes sense. No major differences here.

But let’s go back to our original query in Raiser’s Edge — Constituents with their Phones, Gifts, and Relationships (oh, and don’t forget the Constituents on the other side of the Relationship). What if we want to recreate that same report in Salesforce?

We can’t. At least not without some additional customization (Custom Report Types or even a third party application like Apsona).

A database is built to hold data for users to query. A CRM is built to use data in the course of some sort of process. It’s compact for a reason.

Since we cannot generate our joins across data as we go, our reports are limited to those joins that already exist, and in order to keep the system running smoothly, those reports can only make so many jumps across joins to give us our data. Accordingly, we are limited to reports on up to three objects and whatever fields are available on those objects, so discussing your reporting requirements with your consulting partner early on is important; they will be able to structure your data in a way that makes your key reports easy to build and access.

On Table-to-Field Transitions

Speaking of fields…

Attributes.

If you are working with a consulting partner on a migration and they do not ask you about this table early on, consider your options.

Attributes (and Constituent Codes) is a table in Raiser’s Edge (a table meaning that it holds fields/header columns and data/rows). Users can customize these — you can add Attributes specific to your organization, and you can add Attributes to any other table of data in Raiser’s Edge. Perhaps they are being used to identify voting district or the Congressional representative for a Constituent. Perhaps they are being used to identify that an individual completed a specific form or course that your organization provides. Eye color. Hair color. Dietary preferences on an event registration. The list goes on (and on and on and on and on).

Regardless of any of that, when it comes to migration, that data needs to move. And if it’s required in reports, it may need to become a field and move onto what is called the Parent record (for an Attribute related to a Gift, the parent record would be the Gift, which becomes an Opportunity). Or it may need to hold multiple values over time and instead be created as a custom object. Or maybe it’s duplicate data that is already stored elsewhere and doesn’t need to be migrated. Those details need to be sorted out as early as possible.

The key to getting it right is careful planning and testing.

Collaborate & Communicate

Despite these challenges, our clients (and others out there!) have been able to successfully transition to Salesforce with the Nonprofit Success Pack.

The key to success is the same as any other migration or project — collaboration across teams and open communication. Knowing the potential pitfalls upfront means that you can tackle them head-on, plan for them, and avoid them during crunch time. Knowing the source of those potential pitfalls means that you are better equipped to handle the unexpected, and you will ensure your organization is successful — even when the going gets tough. 

Have you migrated, or are migrating, from Raiser’s Edge and had these frustrations? Have you watched our webinar on it yet? What tips would you share with others going through the same thing? Tell us all about it on Twitter, on the Salesforce Community, or chat with me @thesafinhold.