Tools

Data migration is a scary daunting task!
Data migration is typically about 50% of the effort and cost of any data migration project; whether you’re migrating to Salesforce or any other database program, it’s always hard!

Data migration is typically about 50% of the effort and cost of any data migration project; whether you’re migrating to Salesforce or any other database program, it’s always hard! The reason is that you’re shoving about 1,000 square pegs into holes of all different shapes.

Indeed, data migration is typically about 50% of the effort and cost of any data migration project. Truth be told it doesn’t matter whether you’re migrating to Salesforce or any other database program, it’s always hard! The reason is that you’re shoving about 1,000 square pegs into holes of all different shapes.

To help prepare, first get to know your own data and understand the process you are about to embark upon. 

To understand your data, you need to have a good sense of the types of data you’re storing currently: Contacts? Check. Households? Check. Donations? Check. And so on. Get a good sense of how these data types relate to each other and whether you have any special rules (written or in your head) for how data is being managed.

A common rule nonprofits must consider with their migration is about householding. When do you want two contacts to be linked together within a household? It’s not as easy a decision as you might think!

The migration process will more or less follow this pattern

1. Analysis – we first analyze your legacy data. This involves getting to know the structure of all tables and fields and how they relate to each other; as well as, assessing the integrity of the data and deduplification and cleanup work that will be required. Every database has dirty and duplicate data, and it’s impossible to eradicate this 100%, but there’s a LOT that a data expert can do to improve the quality of your data.

2. Mapping – this is the slog, the really hard work that will take your time. We will walk through every table, every field and seek to understand its purpose and structure so that they can determine how this old data should live in the new system and establish migration rules. Buckle up for a few weeks, this takes time to get right and it’s absolutely critical that it’s done well.

3. Conversion and migration – the rules defined in the mapping stage are used to transform the old data to the new system based on the mapping and transformation rules. Once, the data is converted, your data is ready to be imported. Yahooo!!

4. Validation – now you get to see the results. But fair warning, you’re gonna work it. You’ll want to do some side by side comparisons of your old database with the new one, making sure the mapping rules were applied correctly and that you approve this new structure. Head’s up, you will find things you’ll want to change. It’s a lot like moving into a new house, after you see your furniture and art on the walls in the new place, you may want to move them around to get it just right.

5. Cleansing – Deduping, data appends, normalizing common values, fixing errant weird characters and more. This is where your data starts to get squeaky clean and you’ll begin loving all the new reports you can run!

6. Differential – it’s probably been weeks since you started your data migration project. Well you probably didn’t stop using it did you? That’s right, a differential allows us to rerun all of the conversion and cleansing scripts on an updated copy of your database and add or modify any records that have changed in the time since it was previously delivered.