Let's go back to basics. The first golden rule of data migration, above any technical consideration is:
"Data migration is a business not a technical issue" ("Practical Data Migration", The British Computer Society, 2006, p15)
Now why do I say that? Surely Data Migration is a highly technical subject?
Well yes and no. Sure we use a lot of sophisticated technology, and the scope of those technological tools is getting wider each year it seems. But in ten years of managing, trouble shooting, and consulting on Data Migration projects and software, it has never been software failure that has damaged a single project.
We are good at writing software. The industry has forty years experience at writing and testing software. It does tend to work, within its' own parameters.
When I am parachuted in to rescue projects gone awry, it is not the software that has caused the problem. Generally, it is the build up of semantic issues and the growing responsibility gap between an increasingly defensive technical team (with well tested software) and a truculent user population who do not trust the data that is put before them, or systems that go crash when they hit unexpected data.
To prevent the responsibility gap developing the business side must be involved in the virtual team from the start of the project. To this end, the first order task, prior to any legacy system investigation (well, ok, in practice in parallel with it) is to initiate the System Retirement Policies (SRP). These are the user written statements of the conditions that must be met before existing systems can be switched off. Last week I showed how User Stories are a great fit for capturing these statements.
However the SPR are not static documents. The first cut are developed, as I say, prior to any other migration activity. The new system may not be designed, training plans may not have been written and the migration strategy not agreed etc. Each of these will enhance mutual understanding of what the impact on real users of the migration will be. As the facts become clear we enhance our SRP to take account of these changing circumstances.
But this is only one avenue into the project for our Key Data Stakeholders. As participants in the Data Quality Rules activity the Business Domain Experts and through them the Data Owners, are actively involved in the day to day management of data quality activity.
Via the transitional business rules process the business community is involved in managing the disturbance data migration activity has on business as usual processes.
And so on. It is not sufficient to pay lip service to business involvement. To see a data migration project to a successful conclusion we need to build a virtual team across the traditional barriers of the IT - Business divide and consciously build into our project deliverables alignment to business priorities.
To hear a little more of what I'm on about, and for those of you who missed the web coaching session on erroneous approaches to Data Quality in Data Migration projects, the recording is now available at: http://www.datamigrationpro.com
