I’m a data person. I love data. No, really – I LOVE data! Getting lost in a database is almost as wonderful as getting lost in my boyfriend’s big blue eyes. Sometimes finding my way again is as easy as looking at a spreadsheet and seeing all the information right in front of me. Yet, there are times I feel like a mouse in a maze, trying different routes (many that lead to dead ends), but eventually, coming out mostly unscathed.
The best (and worst) part of being a data specialist is that our clients come from many different databases. Some clients are coming from Excel, others from different Salesforce instances, and some are moving away from really old systems. We’ve also helped clients migrate from Raiser’s Edge to Salesforce. It’s a behemoth of a database.
This is not a blueprint for a futuristic computer chip or some modern art. This is an actual schema of the Raiser’s Edge’s database. It includes many tables and many connections. Navigating through the tables can be messy, especially when it is hard to find a clear connection between them. There are numerous fields in each table and scrolling through all of them can seem like an epic, unending journey through the desert, with no hope of finding what you seek.
A data map is a great way to document the process of uncovering the secrets of a data set. We use them for different reasons – to catalog what is contained in the old system, to record the fields in the new system, to a show a client all of the data they have collected… this list could go on and on!
It is extremely important to our clients (as well as ourselves), that we clarify where the data is coming from and where it’s migrating. To do so in a clear manner, we use a data map. We outline which tables and fields are coming over and where we plan to put them. This may sound like overkill, but it’s an important step in each project because it will give the data specialist a clear understanding of where information is supposed to go and it gives the client the opportunity to tell us if something is missing. Every object is outlined and every single field that is coming over is put into a data map. If there are fields that are changing from one database to the other, we can specify those changes in the data map. If there were limitations in the last system that are now open and flexible within Salesforce, the data may change to reflect that and those changes would also be outlined in the data map.
After years of use, a database can get cluttered with data that isn’t useful anymore. The data map is also a good tool to help clean up that data. For example, if you have a field for Marital Status in your current database that has options for ‘Married,’ ‘Single,’ ‘Previously Married,’ ‘Divorced,’ ‘Widowed,’ ‘Married with Kids,’ ‘Married without Kids,’ and ‘Divorced with Kids,’ you may choose to pare those down to ‘Married’ and ‘Single.’ We can do that with the data map! A client just needs to tell the data specialist what should be done with historical data.
Most of the map will be done by a consultant and there will be lots of fields that won’t make a lot of sense to the client (ID fields and Record Types), but it’s still important to go through the data map and make sure that all fields have been documented in the data map. If there is a custom field that is relied on heavily, it needs to be included in the map because that’s the blueprint the data specialist (or consultant) is going to use. Nobody wants to lose an integral piece of data during this very important step of the project.
A database can be a tricky. Sometimes information is hidden and finding it can be a challenge. Moving from an old system into a new, squeaky clean system is great! It is important to keep the data you need, but you don’t want to bring over all the “garbage” that may be crowding your old system. Use the data map as a way to make sure you only migrate the information you need, instead of moving over years of clutter!
For more information on data migrations (my favorite subject), please take a look at these posts: