No data migration project is easy. Data migration projects involving donor data (read: “highly degradable”) and the nonprofit industry (read: “technology shy”) are even more challenging.
You have some avoidable decisions ahead of you. Facing down the unavoidable decisions now will ensure a more successful donor data migration project, saving you time and money.
Remember: all of your donor relationships depend on data. People know people. The nonprofit organization only knows donor data. There is too much information about too many donors, constituents, and prospects to rely upon anyone’s individual brain capacity. You need your donor data to be as complete as possible. We define “completeness” as “what you will use.”
Let’s get started.
Seven Tough Decisions
Decision 1: Must we have data governance policies before we migrate?
Yes. Your data governance policies define both the standards for data quality and your organization’s commitment to maintaining those standards. A good set of data standards will address many important issues such as the following:
- How long will you store old records?
- How many instances of old addresses will you save?
- When does a prospect stop being a prospect and just become “bad data?”
- What (annual) steps will you take to maintain the accuracy of existing records?
Without a basic set of data governance policies in place before the data migration begins, you will be forced to make governance decisions as you work through the process. Why? Because your data migration expert will keep asking you questions that you can’t answer. Better to get this out of the way first.
Decision 2: How many years of donor data do I migrate?
This is a frequently asked question and a tough decision for most nonprofits. The data hoarder in all of us wants to keep data “just in case” we need it, or to run those cool reports that show 10 years of trends. Stop and ask yourself this: When was the last time you went into your CRM and studied donors or gifts older than three years? If the answer is, “I can’t remember,” then go with three years. Archive retired data and save old trend reports. That is for your peace of mind.
Decision 3: What do I do about lapsed donors?
At the risk of answering a question with a question, when was the last time you reached out with a targeted message to lapsed donors — donors who have not given in the past two years? If you haven’t, I recommend you do not import lapsed donors to your new CRM. Instead, segment your lapsed donors and plan an outreach strategy. For example, two or three communications with new messaging that invites their participation in your mission. Anybody responding to this mini-campaign goes into your new CRM. Anybody who doesn’t stays in the archive.
Decision 4: What do I do about data that won’t import?
Every data migration we’ve worked on ends up with data that can’t be imported. Sometimes this is due to data quality issues, and sometimes it is due to limitations of the CRM database import tools. As your data expert prepares your data map from old to new, he or she will identify limitations of the old CRM database … which also validates your decision to migrate. Remember: your new CRM is your future. It is more important that the new database meets your future fundraising needs than supports 100% of your legacy data. For data that you “retire,” export it into a usable format, like an Access database for Excel spreadsheet, so you can refer to it later if needed.
Decision 5: We have a couple of ad hoc text fields with a lot of donor history notes. What do we do about them?
Text fields are notorious in older databases. With an insufficient data structure to support a growing charity, the easy short-cut to data management was to store more information in an ad hoc field— birth dates, family data, alma mater, notes from a meeting, etc. First, export this data into a spreadsheet and review it. Do you in fact have meaningful data? If so, import it into the new CRM, into a notes or text field. Once your data migration is completed, then go back to this ad hoc data and analyze it. In some cases, you have unmanageable garbage, but you only realize it once you’ve gone through the discipline of a data migration. In some cases, though, you have useful information that needs to be re-populated into your CRM. Parse and import the data into two or more new fields in your CRM database. You will need a parsing tool— did you know that you can do a lot of basic parsing using Microsoft Excel?
Decision 6: When should our data be cleaned, before or after the data migration?
As a rule of thumb, clean it before migrating. But be aware that this is not always the best approach. It depends on data quality from the legacy system, and data problems that you are trying to solve. For example, in one recent migration project, the legacy database comingled records for multiple nonprofits, and record ownership was not always clear. There was a concern that the data extraction could miss needed data. So we migrated the entire database to the new CRM, then worked with the customer to remove records owned solely by another organization.
Decision 7: We chose a new CRM, we are three months into our data migration project, and we are just now figuring out that some data fields won’t translate to the new CRM. What do we do now?
Don’t panic. This is not uncommon. This situation usually occurs after you’ve completed the data map from the old to new CRM database and initial testing is underway. The ah-ha occurs when you realize that some fields in the new CRM aren’t interpreting data the same way that you expected they would. Or you look at test data in the new database and “something is missing.”
What now? Stop and review your map again. Make a list of all fields that aren’t readily translating to the new. Can you remap to another field? Do you need to create a new custom field in the database? Is the real issue that the old database is suffering from bad data management practices that the new CRM won’t tolerate? That last question, by the way, is an important one. Based on our experience, if you can’t figure a way for the new CRM to accommodate the old data, you probably don’t need it.
Your data migration into that new CRM is all about the future. You can’t take all of your legacy data with you, so focus only on the data with you that you will use. Don’t let 20% of your legacy data become 80% of your migration project costs. As long as you archive the retired data, you can always come back to it later if you really need it.