Data Migration: Track Record or Process Maturity?

What's more important when it comes to engaging a vendor in the data migration space - a track record of prior success or a demonstrable maturity of both company and process? I suspect the answer will differ from person to person and project to project. Having recently been involved in a few vendor selection exercises I've spent quite some time pondering this question.

The obvious response might be to favour the vendor with an enviable track record of successfully delivering their past projects. Surely putting your faith in an organization that has consistently and regularly delivered is a good thing - right? Maybe not! I'd advocate considering a few other things before signing that contract. For one, how long is that track record? A 100% success rate is impressive, but what does it really tell you if the company is a new player or is entering a new market space? It may be an indication of things to come, but it could equally well be a reflection of the firm's (and her people's) early stage enthusiasm and a "do whatever it takes" attitude that has got those projects delivered.   If this is the case, is this what you want for your project? A successful delivery may be the end result,  and maybe what people see when the look at the project I years to come, but what might it look like on the inside whilst the project is in motion? Throwing people and dollars at a problem to get a project over the line can bring undesirable side effects for those involved. Increased working hours, last minute ad hoc requests, a scattergun approach and a feeling that true outcomes may have been sacrificed to the Gods of the Gantt Chart all take their toll on the morale of those on the project - both on the vendor and customer sides. People can and do burn out. Your best internal people may jump ship, recognizing what's coming, while others on your team may tough it out but carry the scars of their experiences from the project back into their normal roles, potentially causing distrust or reluctance toward adoption of the new system as a by product of their attitude. Factors like these can and do hit project costs but, perhaps more importantly, also can have a larger impact on realization of the projected benefits of the project. The unfortunate truth here, though, is that often success will be recognized and rewarded when a challenged project finally gets delivered, with no one noticing that the really important outcomes were missed. Be careful what you measure! But I’ll leave the discussion of selecting appropriate KPIs and their impact on driving behavior to another blog post.

What’s the alternative? I’d advocate looking for evidence of process, and not just for the existence of a few pages talking academically about the process in a tender response, but some indication that that process has actually been used in an organization’s prior data migration engagements. When this is apparent (and verifiable) it’s usually indicative of a level of maturity.  Chances are that in reaching that level of maturity the vendor has learned a thing or two. Among the ones that are likely to materially matter to you are how to ensure their staff make good use of the process rather than just blindly follow it, and (hopefully) the fact that the process has been born of experience, that the scars and successes of past projects have all had some bearing on what will happen on contemporary data migration projects (yours included). Having such a process will mean the success of your upcoming data migration project is less dependent on the knowledge or experience of one or two key people but instead allows a broader group to be able to make choices and take effective actions. Actions which are likely to be well aligned with the desired end result and not just knee jerk responses to a current problem. This is especially important as time and delivery pressures come to the fore as the go live date looms closer. Going down this path should also mean that there is far less need for heroic efforts to deliver the project. Those long hours that many of us recognize from past migration projects should be the exceptions rather than a daily norm. Your people will be less likely to burn out and / or become jaded with the new system and you’ll avoid the creep of toxic feelings that may otherwise have undermined the system adoption. And who knows, with all that good stuff going on you might even successfully migrate the data AND get good benefits realization!