Testing takes a multiple-level drive
December 10, 2008
The most exacting part of migration projects does not appear as the code is created to mirror the HP 3000's work in another environment. Migration partners and customers alike report that testing consumes the majority of resource and time in every project. Only when the answers and operations are identical on both systems, measured over a reasonable amount of time, can a migration be considered complete.
Migration testing takes place on eight levels, according to Chris Koppe, the director of marketing at HP Platinum migration partner Speedware. There's Unit Tests, determining if the code runs; functionality, checking the results of the code against a known application; then performance, integration, interfaces, processes, holistic system tests and finally user acceptance.
Speedware finished up work on a migration at Tufts Health Plan this year. The customer took on the bulk of testing because they knew their business logic inside the application best.
“At Tufts they wanted to make sure the application worked, because they wrote it,” Koppe said. In this kind of “lift and shift” migration, no rewriting or packaged applications are employed. A migration customer with this goal simply wants the same level of functionality on a platform that, like Tufts, they can describe as having less risk and more business continuity than an HP 3000.
Technology choices come from the customer, too, but only after they’ve been briefed on the potential of all prospective choices. In the Tufts project, the HMO chose Eloquence as its replacement database for TurboIMAGE, and then worked through multiple deployments of migration drops. For more than six months, the new target database ran in synchronization with the still-functional TurboIMAGE database. The Imaxsoft utility OpenTurbo managed the repeated synchronizations.
Tufts was using NetBase, too, and it was replaced with replication technology inside the Eloquence database. “You have to educate the customers on all of the options,” Koppe said. “We train them in what they choose to use, and they select on the basis of what technology stack they want to live with for the foreseeable future.”
Migration business in the 3000 community still presents a growth period for Speedware during 2009, he said. HP’s announcement of an extended Mature Product Support period in 2009-10 created a lull for the marketplace, but activity is restarting. With a mean time-frame of 15 to 18 months for a migration, companies starting in 2009 may just make the deadline before HP ends its support altogether for the system.
One good motivator for the launch of migrations might be something which Koppe called a human resources map. “You have an aging set of programmers who are managing these systems,” he said. “If companies actually did HR maps, they’d realize that a lot of the people who know how to maintain their legacy systems are up for retirement in the next five to 10 years.”