Over the next few months on the Perspectives blog, I would like to address the many facets of what makes a data migration project work, what makes it successful (and what defines success, for that matter). I am approaching this from the perspective of best practices, including processes, skills and, of course, tools. As a jumpstart, this post and the next five will cover ‘The Five Pitfalls of Data Migration’. These are five key areas that anyone starting a data migration, or in the midst of one, must consider.
First things first. What do I mean when I say data migration? Generally there are two types of data migration, the storage data migration to address a server or database upgrade, requiring little or no data transformation. The application data migration addresses an application replacement, upgrade or consolidation, and requires a significant amount of data transformation. You may be moving to a new version of your CRM application, or consolidating a single view of customer database following an acquisition. Your organization may be embarking on a modernization program, and moving from legacy bespoke applications to a new off the shelf solution. Whatever the driver, there are good sound approaches to include when planning your strategy.
Migrations are different than other IT projects, and not realizing this is one of the first common mistakes that planners make. They assume that their tried and true development methodology will work just fine for migrating data. And it just ain’t so. The thing to realize is that you are not moving new process functionality to your production environment: you are moving the data that supports that functionality. The focus is the data content, getting it right, ensuring that it supports your new business processes. This focus on content, as opposed to process or functionality, changes how you approach the migration process. (Don’t get me wrong, I am not presenting a data migration methodology here, Informatica has our Velocity Migration Methodology, there is a good book by John Morris and at least one good website – datamigrationpro.com that cover that topic. I am just calling out some of the approaches that work and the pitfalls to avoid.)
I’ll go into more detail in subsequent posts, but one example is the way in which you gather requirements. For a data migration, requirements are driven by two things, the functional needs of the target system and the state of the legacy data. Your data may support your current system quite well, but that does not translate into data that sits well in the new system. There are a host of potential risks, including missing data (especially when you are implementing new business processes), data that is inconsistent over time, across regions, or organization unites, and redundant data. So requirements need to include an assessment of your existing data, and an understanding of the gap between what you have and what you need. This is indeed unique.
So the next five posts will include more detail about:
- Some ways in which the data migration project is unique
- why profiling and analysis drives success
- considerations around access (connectivity) and transformation functionality
- the needed engagement of business data stakeholders
- the kinds of tools best suited to accomplishing a migration on time that supports the business processes on the new application