Data Migration: Don't Ask What Should I Take, Ask What Can I Leave Behind?

I've written before about the importance of Selling the Data Migration Strategy and getting senior management buy-in. Recently I've been engaged in that sales job within my own organisation and just the other day met some resistance. On past projects disagreements around my strategic intent often took the form of objecting to my position that migration is an activity that should be front and centre for the business with them, rather than the IT or IS function, having accountability for its success. However, that wasn't the case this time, instead the contentious issue was that the strategy I'd written didn't explicitly call out the we should only migrate the minimum amount of data.

From my point of view this isn't something that belongs in an Enterprise Data Migration Strategy. It's not that I don't think that keeping the volume of data to be migrated down has merit. I don't need convincing that involving more data increases the cost and heightens the risks of overruns or impacts outside of the organisation's walls but, even more importantly, I don't think it's my place to be mandating a minimum data approach in a blanket fashion. For me, each of our data migrations will have different needs, different profiles and different levels of data to be migrated. And let's not forget that it's the business, not the technical staff, who should be making the calls about how much data to migrate!

This discussion got me thinking. There is value in keeping migration data volumes low so how could I, through the strategy, encourage this behaviour without presupposing it was the right course of action for each migration project? After some thinking I've landed on updating the data migration strategy to include a new principle:

Migrate the appropriate level of data. 

Expanding this a little, I see two key points that should be considered in finding this appropriate level of data.

• Firstly, a default position of migrating all available data is not where we should start. 
• Secondly, and following on from this, don't just ask the question "how much data do we need to migrate", but instead try the question "how much data can we afford not to migrate - what data can we leave behind?" 

With this question as the starting point I think there is a way of ticking all the boxes: the appropriate amount of data is migrated, the data migration volume is kept as low as possible, and IT doesn't drive how much data is migrated - the business still gets to make this decision.

The unanswered question here is how does the business decide on the appropriate level of data? I've used various techniques to help in the past and I've some new ideas as well, but that's a discussion I'll leave for another blog post.