Why? Because on all projects, and especially the longer, more complex, larger ones with multiple team members (and team members who may join half way through), someone somewhere will eventually ask about your current system with questions such as: What does this field do? What does this value mean? How does this field relate to that other table we have? And so on.
And if you have a data dictionary then you can answer that! Sounds simple, and it is (if time consuming), but you might be surprised (or maybe you aren't…) at how few organisations have such a document. You will also continue to find it useful once you are up and running with your new database - it's not just for data migrations - e.g. for reports, trainers, integration projects, development projects, for new database managers and technical staff etc.
So if you haven't got a data dictionary, then as soon as you start a new database project, even at the stage of requirements gathering, business analysis, investigation phase and the like, start one. And if you have got one, check and update it. It will save you a whole heap of time later.
And if you haven't created a data dictionary before then in my next post, I will provide an example of the sort of elements you could store in one.