So! Your org is implementing a new system. What’s your game plan for migrating all that data?
Perhaps you don’t have one, because #time. You spent enough of it searching for the right platform in the first place, and deciding whether to migrate at all. Then, you had to jump through all those hoops to start implementing!
But before you get lost in imports and csv’s, you need a game plan. After all, this could be your LAST CHANCE to get your data in tip top shape before moving it to its fancy, new home.
You’re nearly at the finish line. Migration is the last stretch of the race. (And in this case, you want to be the tortoise: steady & intentional.)
6 Questions to Prepare Your Data Migration
1. What kinds of data need to be migrated?
Think about the different types of records that need to live in the system. That might include donors, volunteers, students, donations, cases, events, campaigns, programs or whatever else.
You probably put this list together back when you were evaluating platforms. But if not, write these out now. You want to make sure you don’t forget any “object” types, especially if these need to be imported in a particular order.
2. How much data does your org have?
Are you working with a few hundred records? A few thousand? Maybe a few hundred thousand?
Run all the exports on your current platform (or submit the request to your vendor) and figure out how many records your org is working with. That way, you can get a jump start on #3.
3. How much data needs to be migrated?
Yes, this can be a different answer from #2!
The difference might depend on the cleanup you do beforehand. If there are lots of bad records or duplicates, then it’s reasonable to expect your database size to shrink.
But it also depends on whether you plan to archive records that don’t need to be accessed in the new system. (This is a great path to consider when your org is working with older data, but isn’t ready to part ways with it.)
But where can I store that data? Honestly, a zip file in your shared network/cloud drive is fine! As long as it’s in a secure spot.
4. When are you cleaning records: before or after you migrate?
Pro tip? You don’t want to move bad data into a new system if you can avoid it.
But sometimes, it’s your best option. If your implementation timeline is tight, you may not have time to do a cleanup before needing to go live on the new platform. Or maybe the admin tools in your new system would make cleanup easier, but only once the data is moved over.
5. What are the cleanup possibilities?
This migration is going to put you knee-deep in data anyway. So might as well fix everything you can!
List out those pain points. Do you have a bunch of first & last name fields with extra spaces or improper punctuation? Are your event or campaign records in desperate need of a naming convention? Now is probably your best chance at tackling those issues all at once.
p.s. I’ve got some tips on where to start with those spreadsheet duplicates. Check those out here.
6. Will you migrate unique IDs for your legacy system?
Imagine you’re all settled into the new platform. You look at a contact record and realize some data is missing or incorrect. You need to log back into your old system (or pull up those spreadsheet files) to fix it.
This is where unique identifiers come in. If your new record has the ID from your old system, you’ll have a much easier time cross-referencing the data. That’s why I recommend setting this up, even if you don’t think you’ll use it.
Set up a field in your new system specifically for the legacy platform ID. Then, be sure to include when importing/migrating your data.
Just add some timelines, and that’s your migration plan.
Happy migrating, gang!