Moving database’s is a lot like moving houses. First, you need to inventory your stuff and decide what you want to move vs. purge. Then you need to consider where in the heck you’ll put your old stuff in the new house. “Can we even fit the piano in the new living room?”. Then you’ll have to box everything up and label it carefully so that once you’ve moved the boxes you can unpack them in an orderly fashion. Physically moving the boxes can be daunting and always takes more time than you expect! And then, once you’re in the new house, you’ll likely change you mind 2-3 times on where the couch fits best.

Seriously, this is a LOT like migrating data.

Lesson #1 – Clean Out the Basement

Your nonprofit has data hidden in all kinds of places. Address books, excel files, old Access and Filemaker databases, email products, third-party applications and of course, your donor database. It’s time to take inventory of these, consolidate what you’re technically capable of combining and choosing which sources you’re confortable purging. The beautiful thing about Salesforce is that you technically CAN migrate all of your legacy data, but just because you could, doesn’t mean you should.

Lesson #2 – Find the Secret Decoder

Chances are, you’re relatively new to your nonprofit. And as such, there’s a good chance you’re inheriting some old taxonomies used to categorize people or classify donors, etc. If you are one of the lucky people who was provided documentation describing all of the antique codes, count your blessings. If not, it’s time to try and track down the historical knowledge of your data from those who’ve been around longer. Once you begin the migration process, there will almost certainly be codes, campaigns, attributes and other types of data values that will need some interpretation. Before you begin a migration, you’d be wise to hunt down what you can about your old data.

Lesson #3 – Understand Flat vs. Relational Data

The #1 most popular “database” used by nonprofits… Excel, is an example of a Flat File. This can work up to a point, but breaks down quickly as organizations grow. If your existing database is only capable of exporting a series of flat files, (e.g. csv or txt files) the migration process will be more laborious; however, if you’re able to retrieve a relational database from your current solution or vendor (e.g. SQL), then migration will be easier and you’ll retain more of your legacy data.

Before you start your migration process, identify what format you’ll be able to retrieve for your legacy data.

Lesson #4 – Data Quality is More Important Than Data Quantity

When migrating old databases, KELL is going to create migration procedures (a.k.a. scripts) that transform the old data into a new structure for Salesforce. Consequently, 10,000 records take virtually the same effort as 20,000 and is not much different when migrating 100,000. It’s the quality that makes the difference.

For example, if you have few duplicates, few errant characters, consistent naming conventions, consistent use of codes and few conditional rules, the volume or data makes little to no difference in the migration effort. Unfortunately, this is seldom reality, as most nonprofits will have a lot of junk data that has been poorly managed, duplicated and inconsistently structured. As a result, KELL’s team will likely need to create additional scripts to identify and transform the inconsistencies to achieve a unified structure for the migration.

One very important rule. Don’t change the architecture during the migration. For example, if you provide KELL with a series of Excel files at the beginning of the project, and then find a way later on to provide a SQL file mid-way through, this could have a significant effect on our effort and may require that we completely start over. Or if you export your legacy data one way, then change the format of the export later on, this too could have a significant effect. Stay consistent and do the work up front to learn how you’ll be providing KELL with backups. We’ll likely need 3 backups throughout the migration process.