In many IT departments, there is a great deal of natural resistance to application migration due to the time involved in planning and performing a systems move. However, support cost issues in a recession-dominated marketplace are now starting to force the need to migrate on a growing number of users. In addition, this natural resistance also means that there is not a great deal of real, practical experience of migration out there within the user community, since most users typically do this only once in a working lifetime. However, not all migrations are painful. In fact, this article will show you an example of how one company took the migration challenge and made great strides in the process.

Why migrate?

Today many legacy applications once thought of as irreplaceable are becoming obsolete due to:

  • A high total cost of ownership (TCO) when compared to newer and cheaper alternatives.
  • A lack of integration with modern applications’ development environments.
  • A poor or even nonexistent upgrade path, particularly when it comes to supporting new hardware environments.

Case study of Protocol Systems
One such company undergoing migration issues is Protocol Systems, a UK-based company specializing in the provision of a wide range of IT services, including application development and Internet solutions, for the education market. Protocol Systems provides the IT support for the group, which, in the context of migration, includes Protocol Professional, a placement service for teaching professionals. The applications Protocol has developed suggest the right applicant(s) for any particular teaching vacancy, from a pool of around 110,000 teaching professionals on their books.

The “books” in question come in the form of a database built on Ingres, once a favorite relational database engine for business applications. Protocol had been using the database to run a placement system since 1994 and it was the chosen database for the operation until 2001 when the decision was made for a strategy review. “Ingres had worked pretty well,” said Protocol Systems’ managing director, David Miller, “but we realized that it would be expensive to continue using it if we wanted to upgrade the application, which is what was needed.” The pricing issue was based not only on the license costs, but also on the longer-term issue of staff costs. “The existing system does demand staff get their hands dirty,” said IT director Carl Shipley, “and they are skilled hands as well. Ingres comes from an era when databases were still something of a black art.”

A move to SQL
After looking at the current offerings of Ingres and Oracle, the decision that came out of the strategy review was to move to Microsoft’s SQL Server as the database engine. A significant component of the choice was that SQL Server proved to be much faster in operation than Ingres. Other important factors, however, revolved around cost. For example, Protocol found they could use the standard implementation of the database as installed, rather than having to tune the installation of the others.

In addition, the availability of people skilled in supporting and managing SQL Server is much greater, especially when compared to Ingres. “There is a potential downside to this that we have had to manage,” Shipley observed, “and that is the need to be more careful when recruiting developers with skills in SQL Server. The greater availability of such people means that it is occasionally possible for individuals to claim to be more expert than they truly are.” Protocol’s solution is to bring in all applicants for developer positions to spend a day with the existing team. “Microsoft also just works on the basis of a price for the product, coupled to volume discounts,” Miller said, “so we knew what the costs would be and could budget accordingly.” This has meant that Protocol has been able to save on the order of 50 percent on the list price of the databases. “In addition, there is now a wide range of other products and tools available that have been designed to work with SQL Server as the database back end. Data mining is just such an area.”

An equally important part of the company’s decision process was the fact that it had developed its applications using Compuware’s UNIFACE 4GL development environment. It remained sensible to stay with UNIFACE, and the decision was made to use the latest implementation, Version 8. This latest version, however, does not support Ingres any more, so the step into the world of migration became inevitable. The company also uses Microsoft’s Visual Studio .NET and Visual Basic .NET, so the move to SQL Server made sense on those grounds as well.

Hardware change is also inevitable
The company is not only migrating the application to a new database, but also migrating its hardware environment from HP-UX running on HP 9000 N-Class servers to 8-way, Intel-based systems from Dell. According to Miller, this move will have an impact on TCO. “We currently spend around £100,000 ($163,177) a year on support, which will drop with the change. In addition, scalability and disaster recovery will be much easier with the new environment. It gives us the future capacity to grow the system and develop more applications as required, and develop them faster and more easily. This is because of the graphical development tools available for SQL Server. There are none available for Ingres, so SQL offers a much faster learning curve.”

Having made these decisions, Protocol turned to Dell for support in the migration process. Dell, in turn, put the company in touch with Intel Solution Services (ISS), which is the division of the processor company that specializes in helping resellers and end users make the transition to the Intel environment. With many analysts now saying that the future for the majority of server vendors is inevitably geared to Intel’s Itanium, a growing number of enterprises are now starting to face the issue of migrating from their old combination of a legacy application running on a legacy platform. “We are now doing a lot of migration work,” said Paul Tartellin, a technical consultant with ISS, “and we have developed a planned approach to managing the issue. There are a number of stages to go through with a migration to a new platform, and the first is a risk evaluation of the existing environment. There is a need to look for ‘gotchas’ that can wreak havoc in the ordered migration from one environment to another.”

These ”gotchas” can be in the form of a third-party add-on or a utility that is not part of the primary application. In some cases, their incorporation may indeed have been forgotten. The other main problem is where the supplier of an application or tool has ceased operations and cannot offer any support in the migration process. This can be particularly important when it comes to documentation, or more likely, the lack of it. “This process normally takes about two weeks and should result in a properly organized plan of campaign for the migration, as well as a budget for the process,” Tartellin said.

Testing is key
The next stage is to create a working prototype of the application running under the new environment. In the database arena, Tartellin stated that this could be completed with relative ease, as the underlying structure of the application can normally be transported to a new database system with few problems. Only then is the application taken to the full implementation.

It is also necessary to build a scalability roadmap covering the next five years or so. “The idea here is to map out the projected user requirements over that time period and establish how they can be fulfilled,” he said. “This will involve mapping out the changes in both hardware and software that can be anticipated. It also provides the best TCO management over the time period, for it allows the user to migrate to the smallest possible system and maps out how to grow it, and when those growth points might arise.”

Linux vs. Microsoft
Finally, there were other aspects of TCO that came into play during Protocol’s migration. For example, with Linux now becoming an accepted enterprise-class environment, it will be easier to migrate many existing UNIX applications to that operating system rather than to Windows. “On the other hand, available staff skills will have an inevitable bearing on long-term running costs,” Tartellin said. “For example, it is a fact that there are more Microsoft Certified Systems Engineers out there in the field than in just about any other qualification, so employment costs will likely be lower. This is the option that Protocol decided upon, and it can prove to be a significant lever in some cases.”