|
contents | business | |||||||
| Four Golden Rules of Successful Data Migration by Tony Sceales and John Morris Your company is implementing a new set of applications that better meet your changing business requirements. Or else you have been instructed to remove duplication and inefficiency in your IT infrastructure. You know that you can no longer avoid the inevitable: you are just going to have to bite the bullet and migrate your business-critical data. You are also well aware that while failure is not an option, industry failure rates for complex migrations are worryingly high. Perhaps it might help to know that successful data migrations share a number of common characteristics. In this article Celona's Tony Sceales and data migration expert John Morris outline the four golden rules of successful migration. Not all migrations are equal. Many migrations are fairly straightforward and motivated purely by technical or IT drivers. For example, at the storage level companies might need to migrate their data to cheaper forms of storage, and at the database level they might need to mirror data to another disk. At the application level, however, data migration can be very complex in large enterprises because it needs to span both technical and business issues. According to Bloor's Phil Howard, Forbes 2, 000 companies already spend at least $5 billion per year on migrations, and yet 80% of them still go over time or over budget. To understand why this is the case it is firstly important to recognize how complex IT infrastructures have arisen. Often they mirror an enterprise's history and have come about as the result of mergers and acquisitions, organic growth, product launches, new initiatives and so on compounded over many years. While individual parts of the infrastructure might be well architected, robust and functional, the overall structure might be poorly understood and far from optimal. However while IT optimization might be desirable, unpicking this complexity is far from easy and risks catastrophic failure – such as lack of availability of business-critical data or failure of service or product delivery systems. Analysing successful IT migration projects reveals, however, common success factors, as shown in Figure 1. Figure 1 Data migration success factors  Rule One: Data migration is a business not a technical issue. Historically migration has been viewed as a purely technical issue and the most pressing concern has been how to migrate data. But since IT doesn't necessarily 'own' either the source and target applications or the data that the business uses to function, it doesn't have the power or the necessary knowledge to deliver what is required by the business. Further, an increasing feature of the modern IT environment is that IT has come out of the data centre and is no longer controlled by the IT department in the way that it might have been previously. Involving business managers in data migration projects is therefore essential. In fact one of the most common characteristics of a successful migration is that they are business- rather than technology-led. Putting the business in the driving seat means that before we ask "how do we migrate data" we first answer a series of important related questions that help us frame and scope the project: - why are we migrating data? - what data should be migrated? - when should it be migrated? These questions cannot be answered by technicians but only by business managers, which is one reason why it is essential for the business to drive the migration. Ensuring the business makes the decisions and drives the project also frees IT up to do what it is best at, which is the technical aspects of moving the data. This suggests any technical solution to the migration must provide the business with clear visibility and control over the way the programme is progressing. Rule Two: the business knows best The second rule of successful data migration is closely linked to the first. This is that the business drivers, not technical ones, should take precedence. It is critically important that business goals should define the solution and approach selected, and not the other way around. The best technical solution is not always the best business solution. Therefore to be successful the chief business stakeholders must define their requirements and take responsibility for driving the project. The business is also better placed to prioritise the migration, deciding which data to migrate first. For example, it might decide that migration be triggered by a customer selecting a new service which can only be supported on the new application stack. Or it might decide that the most important customers be migrated first, or second, or last (according to business need). By allowing the business to drive the migration an enterprise has a better chance of delivering the right solution for its needs and maximizing the ROI on its investment. However, IT must be aware that the business will not be able to predict at the outset what issues will surface during the migration, and moreover in a long-running programme they will absolutely have to handle changes in priority and direction. The chosen migration technology must be able to support such changes without restarting every time. Rule Three: no one needs, wants or will pay for perfect data Applications are only as good as the data they have available to them. We also know that many a data migration has been scuppered by overestimating the quality of, or not understanding, source data. Oh the joy of legacy data with its gaps, inconsistencies and redundancies! However, while enhancing data quality is a worthy goal, it is really important not to go off on a tangent mid-project in the quest for perfect data quality. Like over-specification of an application, the quest for data perfection can result in negative consequences for the project. It is where many, many projects run aground – inflating both the cost and the time to deliver the project. To avoid this trap data owners and users need to determine the level of quality they require at the start of the project, in order that the technologists have an appropriate goal to aim at. It is also why project managers need to be aware of the true quality of their legacy data and allow adequate time and budget to achieve the requisite data quality. A successful migration strategy will also need to incorporate a range of cleanse strategies at different points in the life of the programme – sometimes pre-migration, sometimes in-flight, and sometimes post-migration – but always with a conscious decision from a business manager. Too many historical migration approaches have meant bringing the whole process to a halt while a data quality issue is explored and resolved. A modern platform will provide the flexibility to continue migrating while this is done. Rule Four: If you can't count it, it doesn't count Another challenge is how to measure data quality in order to assess the state of your legacy data and determine the level of quality your business users require. To make matters worse, data quality is not static but erodes and improves over time. It is really important that the measures you use make sense to business users and not just to technologists. This enables you to measure deliverables, perform gap analyses, and monitor and improve ongoing data quality. It also ensures that you are concentrating your efforts on where business users see value and can quantify the benefits. Reconciliation of the data migrated from source(s) to target(s) is always a critically important activity – how do you know when you're done? When dealing with dynamic environments where you can't freeze the data this becomes even more challenging: you need to be able to handle a shifting scope. Having a flexible data model and closely-coupled reporting capability is key to understanding and driving this process. Achieving a business-driven migration Having put a business-driven migration project in place the trick then is to select methodologies and technologies that can deliver against these requirements. A business-driven migration involves decoupling the technical problem of moving the data from the business processes that use it. This requires a migration solution that enables you to easily encapsulate the business problems you face, while being flexible enough to cope when those requirements change. This ensures that ROI from new application investment is maximised and operations are enhanced rather than adversely affected. The critical importance of getting the migration right from a business perspective was articulated at a recent British Computer Society meeting by BT’s Phil Dance: "Increasingly our business case is going to depend on how good we are at getting our data across. A bad data migration ultimately means a bad customer migration, and in a competitive market that’s very bad news." Tony Sceales is CTO of third-generation migration technology vendors Celona Technologies. John Morris is Director of iergo ltd and author of Practical Data Migration. write your comments about the article :: © 2008 Computing News :: home page |