In almost all fundraising and CRM database implementations, there will be some element of data migration - getting data out of your old database and into your shiny new one. But that isn't easy. Data migration takes time, skill and a knowledge of not just the new system itself but of how you are going to use it at your organisation.
And although data migration is not the most important thing in an implementation, it is still a very important thing. Hence: although data migration won't make an implementation succeed on its own, a bad migration can make it fail.
One of the problems/risks with database implementations is that it can start to be seen just as a data migration project. We lose sight of the benefits and process improvements and all the other good stuff we wanted to do with the new system and it just becomes an exercise in forcing the damn data from the old system into the new one. It's an easy thing to do. Try not to let it happen to you.
What you should be doing is running the 'functional and business process' stream(s) in parallel with the data migration. There may of course be some data which is comparatively easy to map to the new system (i.e. name, address, hopefully basic cash donation fields) and that can be done early on in the project; but as much of the project will be taken up with deciding how you are going to use and configure the new system for your organisation, then the data migration needs to reflect that - not the other way round.
I've seen good data migrations with good implementations; I've seen good data migrations and still seen the final implementation struggle, but I've never seen a bad data migration and a successful final implementation. Consider it carefully, spend time on it, get it right.
No comments:
Post a Comment