| Now that we've explained why migrations occur and the benefits an organization can achieve by undertaking them, it's probably unclear why they are so dreaded within the IT industry. The simple reason is something quality advocates like to call "resistance to change." It is a natural reaction to resist change when substantial time and effort to make an environment stable and productive is required. Add to this the element of the unknown ”which is often the case when IT personnel are forced to migrate off a legacy system ”along with the cost and complexity of the move, and it is no wonder that IT professionals loathe migration projects. The following list summarizes some of the common problems you are likely to face during a migration project: -
High cost. Migrations can be expensive. You will need to pay for additional hardware, software, services, and staff to make your migration successful. Sometimes these costs can be easily estimated before a project begins. What is problematic for most companies is that the costs are often not planned for ahead of time and come as unexpected expenses during or after the project has completed. -
Complexity. Migration projects are an order of magnitude more difficult than ordinary new application implementation projects. Applications and processes already in place have a tendency to grow informally without planning or documentation. As a result, it can be difficult to ascertain the true requirements of a migrated solution or even the true state of the current implementation. Compound these problems by dealing with an unfamiliar technology product, and you can see how the complexity of even small migration projects can be daunting. -
Substantial time and effort requirements. Closely related to the cost problem, substantial time and effort will need to be expended to successfully migrate even average- sized environments. Often, this time and effort cannot be spared within an overtaxed IT department. This creates a vicious circle whereby the time and effort needed to migrate keeps increasing, along with the urgency of the business driver for migration. Take a mainframe Y2K migration, for example. Most organizations used this as an opportunity to migrate completely off mainframes instead of simply patching and upgrading their non-Y2K-compliant applications. Those who didn't take advantage of that opportunity saw their future migrations become more difficult and lengthy. -
Resistance to change. People, even highly skilled IT professionals, fundamentally dislike change. This is natural because most change entails increased risk, at least during the migration itself. In addition, it is human nature to become accustomed to the status quo, regardless of how good or bad it is. Resistance to change manifests itself in denial that problems exist, lack of will or direction to make changes, and even sabotage of the change process itself. This is especially true among IT professionals who are highly skilled in a particular technology. -
Lack of executive support. As we have seen, migration projects entail cost, time, and effort. Like any large IT project, it is unlikely that a migration will succeed without executive support. Because any migration must be a joint effort between business units and IT, executive ownership is crucial in providing resources, solving disputes, and forging agreements. Involving an experienced and highly skilled project manager, together with a business-driven project-management methodology, can help ensure that you receive the support you will need. -
Lack of accurate current information. Sadly, orphaned legacy environments always remain in any organization where, due to neglect or stability, solutions are no longer actively managed. This is usually because the original implementers of the system are no longer with the organization, leaving no one knowledgeable about its operation, design, or maintenance requirements. When the time does come to migrate off this implementation, you are left with nagging questions that cannot be ignored, such as "Where is the source code for this application?" "What users does it serve?" and "What are its availability requirements?" Without accurate information for answering all of these questions and more, successfully migrating to a new solution will be problematic. Many companies experienced this the hard way during their Y2K upgrade. Applications that had been in place for 20 years could not be ported to new platforms or upgraded to alleviate the problem because the original programmer had left the company without securing the source code. These companies were left with the unhappy choice between reverse engineering applications or starting over from scratch. -
Poor change control. It is impossible to migrate from a constantly changing or poorly controlled environment. If you cannot take an accurate snapshot of the current state of the environment, your migration will suffer from many of the same ills as it would from your having inaccurate information. Worse yet, the incremental changes will cause expensive rework in development and testing. -
Inappropriate scope. As in any large or complex project, it is imperative to control scope. Too narrow a scope might not satisfy the migration drivers, while too broad a scope will surely cause the project to overrun its budget and not complete on time. -
Limited skills and resources. Migration projects require the involvement of highly skilled people who are familiar with both the current and the new technology. In addition, large or complex migrations might need a lot of these people. If you do not have people with the right sets of skills or do not have enough of these skilled personnel, your project will likely fail. -
Unreasonable expectations. IT departments are usually not very good at setting expectations for end users about the level of service or functionality they will receive. In situations in which end users do not fully understand the current implementation or the new implementation, it is easy to understand how expectations might not be properly set. This misunderstanding can cause a technically perfectly executed migration to appear lacking in the eyes of the end- user community. -
Poor communication. IT departments often also communicate poorly to organizations about their intentions and actions. Examples of important communications include downtime for migration activities, new or replaced functionality in the solution, and participation from the end-user community. Poor communication, or the lack of communication, can cause problems before, during, and after a project. -
Unknown or unproven technologies. IT personnel tend to resist unknown or unproven technologies. This is quite justifiable because IT personnel are employed to anticipate and prevent failures in their solutions. However, this resistance can also be an unjustified reaction to a loss of technical superiority in the older technology. Either problem must be overcome for a migration project to be successful. -
Poor quality of the new solution. Like new applications, some migration projects simply fail. They might not work correctly, might not support the business properly, or might not meet minimum service levels. Of course, these failures result in lost productivity, missed business opportunities, increased cost, and increased resistance to change. As you can see, the problems that occur during upgrades and migrations are similar to the problems found in new environment implementations . However, because we are not starting with the proverbial "green field," the problems tend to be more complicated and their effects more severe. |
