If we are migrating data this often, it seems quite surprising that there is a quite a high level of failure. A recent study by Bloor Research revealed that 38% of migrations fail.1 If you go it alone, without appropriate software, support, training or external methodologies, the chances are greater that you will fail than that you will succeed.
One of our recent white papers “Tackling the ticking time bomb – data migration and the hidden risks,” written by Johny Morris, identifies 4 common errors of why migrations fail. Johny is a well-established expert in the field of data migrations, with over 25 years of experience in the IT industry.
The first reason outlined in the paper is “underestimation of the scale of data issues”. We get so used to our existing systems we forget about the potential problems that hide beneath. “Looking into old systems is like being on an archaeological dig. Each layer reveals a new set of issues,” explains Mr Morris. Data issues can stem from a changing business as well as changing people and processes. Often well-established rules around data can be forgotten, bent to suit business needs, or simply just ignored. If this data came from a source that you have no idea about, such as data acquired from a merger or acquisition, then it compounds the problem. Diving into migrations without a good understanding of the state of the data, particularly its quality, can lead to problems down the line.
The second reason is “overestimating the ability of technologists to fix the problem unaided”. Data migrations may seem like a technical, IT-owned project; however at the heart of it all is data, which is a business-owned and business-generated product. Most issues within data could be handled by technologists, especially when it comes to correcting the formats of dates or standardising addresses using reference data. But consider the problem where the discount codes against some orders do not match the current list or that customer records do not match up between the sales and finance systems due to different account numbers. Technologists cannot rely on their own assumptions, but will need support from the wider business.
The third frequent reason arises from “poor prioritisation and management of data issues”. In most cases, it occurs when the technical and business sides of an organisation do not develop a coherent, centralised plan.
“Those of us that have been involved in data migrations before will be aware that we will uncover more data issues than we can fix in the time available before we go live.” Often the time taken to get consensus on the right approach to tackle a data issue is not considered, and on top of that appropriate priority of the data issues are not determined. It is important to acknowledge that while some IT resources may be dedicated to the data migration, most business users continue with their day job. It is critical to build contingency and appropriate priority within the data migration plan.
Finally, “misunderstanding what you’ve signed up for” is the fourth reason. Again, this is a consequence of miscommunication and a decided lack of awareness regarding what all parties involved in a data migration project are responsible for. There are two chief reasons why organisations end up in such a position: underestimating the scale of data issues (discussed above) and inflexible procurement contracts.
The latter results in a decided lack of flexibility within contracts, as suppliers will, for example, stick to what has been asked of them. Any unforeseen issues will fall out of their remit or go unnoticed, meaning possible problems at a later date such as increased costs, additional resources or worse, an unsuccessful migration.
These four common errors can be avoided or at least the severity of them reduced significantly. Thorough planning and organisation will ensure these obstacles are tackled from the offset, resulting in a smooth transition of your data.