Where’s your data migration DMZ?
I received a call recently from an old colleague, now running the IT department of a fairly large local government operation. They were mid-way through a project and had turned their minds to how they were going to populate their new system with data. With confidence they turned to their supplier, but were astonished by the response.
"No," they were told. The supplier did not sign up to extracting, cleaning, and preparing the data. They were offering migration software to transform and load data prepared to the standard specified in the load template. It was the client's responsibility to produce that data.
They would report back the error records to the client and expect them fixed. Oh, and by the way, as a quid pro quo for accepting the tough liquidated damages clauses in the contract, insisted upon by the client’s procurement team, they had a matching wait time clause that meant their guys reverted to full-rate card rates if the data was delayed.
But how did my friend reach this pretty pass? He had used a form of contract his procurement department insisted was compliant with current best practice – so how had he been deceived?
The changing face of procurement
My friend’s experience is not uncommon. As the practice of tight fixed-price contracts has become the norm, most suppliers draw a tight circle around what they can and cannot do under the contract to protect themselves from being held responsible for delivering data from client systems they neither know nor understand, tied to timeframes they could not estimate and counting on the active support of client staff over whom they have no control. This is not to say that most suppliers will not go beyond the contract to strive to deliver, but push too hard, demand or expect too much and you will find yourselves being pushed right back.
Staying behind the DMZ
The facts: PDMv2
- Download this extract from Johny Morris's book: Practical Data Migration
- Includes a 20% discount code for Computer Weekly readers on Johny Morris' book valid until March 2012
Within PDMv2, as described in the new edition of Practical Data Migration, we understand this boundary as the demilitarised zone (DMZ). Just as in file transfers, where the DMZ is the space between the firewalls of two cooperating enterprises, the data migration DMZ is the boundary between client and supplier. However, it is more than a physical implementation, by extension it is the distinction between what the supplier is contracted to perform and what remains for the client to do. And the area outside the DMZ has all the most difficult business-centric activities.
How to not get stuck in no man’s land
Firstly, we have to accept that for perfectly good commercial reasons, our suppliers are going to protect themselves from being responsible for activities outside of their specialist knowledge. You hired them for their knowledge of the target, not the legacy data sources. Secondly, in cash-strapped times, to win business, bids will be pared to the bone – there will not be any spare resources. So understand your DMZ, understand what the supplier is doing and therefore what you need to do and, if necessary, be prepared to put in extra budget to get the resource needed to cover the gaps. Finally, data migration is often a once in a business lifetime experience. Do your research and build your project accordingly.
My friend had to compromise, foregoing some functionality and pleading for additional budget. He got there in the end, but not without an unnecessary degree of discomfort.
Johny Morris has over 25 years experience in IT and has worked as a data migration consultant for some of the biggest names in IT consultancy and large and small blue-chip clients. He is the author of Practical Data Migration
This was first published in October 2012