Over the last few months I have had a large number of discussions regarding the best approach for achieving successful data migrations.  There have been three concepts that come up most frequently, and they are:

1. business or legacy system-orientated
2. big bang versus incremental
3. staged or non-staged, etc.

These are valid considerations and deserve serious deliberation; however, by focusing directly on the mechanics, many projects, in my experience, miss completely what I believe to be the fundamental goal of any data migration, that of risk management.

Put another way data migrations are not about moving data they are principally about managing risk – financial risk, technical risk, reputational risk – the list is endless. The majority of people I talk to have at least one horror story to share on this subject.

The bigger the project and the bigger the anticipated benefits then the bigger the risk an organisation faces if things do not go as planned.

The fact that an organisation’s data is complete, accurate and functionally useable and is successfully migrated to a new system or platform should just be the by-product of an effective risk management process and not the focus of the project itself. That’s what I mean by saying data migrations are not about moving data.

Having stated that the approach should be principally governed first and foremost by a risk management process, the next logical question to ask is – “how do I do this?” The answer to this question is relatively simple, control; that is “how can I control the migration in the most risk averse, effective and beneficial way?” From my perspective one of the simplest ways to achieve this necessary level of control is through a tools-based approach.

When considering a tools-based approach the more open comprehensive unified and economical the chosen platform is the greater the opportunity to simplify the process and hence the greater the ability to execute the necessary control to successfully manage the risk. This is not to state that such an approach will inherently make the task in hand easier (it may well do), but it will make it simpler; and simpler tasks are on the whole easier to control, and control is what we want.

What are the key elements of a typical migration that we want to control and hence risk-manage? The following is a list of common issues, challenges or questions that are typically encountered through a “classical” migration approach; such as:

• Data discovery is skipped due to time or resource constraints
• Data cleansing cannot be easily accommodated or is very resource-intensive
• Key data is not in systems which can be easily accessed
• Migration gets “Out of Sync” with target configuration or definition
• All the effort goes into just loading the data
• Too much time spent backing up the target
• Reconciliation is only considered as an afterthought
• No leverage into “Business as Usual”
• Is my migration logic under version control, is it being followed?
• How do I keep the data I’m migrating “up to date” as the source system?

Any of the above can significantly raise the risk levels of a project and jeopardise a successful outcome. Over the next few weeks I will present a compelling case as to how a tools-based approach can give the project team the control to successfully address these issues and the risk they present.