Surviving A Change Management Migration
July 25, 2016 Dan Burger
Software migrations are the root canals of enterprise IT. Rarely do you find anyone looking forward to them. That’s not to say they are not being considered. High maintenance fees and minimal enhancements have encouraged software replacement strategies to become more widespread than they were just a few years ago. In the IBM midrange community, where application and database modernization is at the top of the priority list, migration obstacles–risk and complexity–are being overcome.
A recent example that has come to the attention of IT Jungle is the replacement of change management software at Vermont Information Processing(VIP), an IBM i software vendor specializing in ERP systems for the beverage distribution business. During the migration from SoftLanding‘s TurnOver to Midrange Dynamics‘ MDCMS, VIP took a close look at improving its software management policies and conflict management capabilities. It also required an examination of how comfortable the company–and in particular the IT department–would be handling the risk that comes with a migration project.
VIP had been using TurnOver change management for approximately 12 years before deciding to replace it in 2014.
“When we first started looking at alternatives, we saw that the migrations depended on manual processes with little or no automation,” says Brian Garland, software developer at VIP. “We were concerned about our change history. We didn’t want to continue supporting the Band-Aids that we had to apply to their [SoftLanding’s] software. We weren’t getting software updates and we didn’t expect to see any updates.”
“VIP, like many new MDCMS users, was progressing with their modernization effort and realized that their current change management solution could not adequately support them,” says Mary Langen, marketing director at Midrange Dynamics.
The migration process was accomplished in two months, but the time frame was not representative of the work involved. Several factors extended the time beyond what would normally be anticipated. Isn’t that the way it always goes?
“We could have done the migration in one month,” Garland says. “The second month does not indicate a month’s worth of work. We had to pick a date for the migration, and it happened to extend the period from when we started because of convenience, not necessity.”
The actual migration–the conversion, the testing, and the training–took about a week. The physical data migration was completed in less than five hours.
“We did two or three migrations to figure out exactly how we wanted it to look. Then we did a couple more migrations because of changes we made in our processes. You can make some assumptions on how you want the configurations, but they may not turn out to be exactly as you thought they would. So we’d fix those and run the migration again,” Garland explained. “We did the entire migration a couple of times and then pieces of the migration were done when the entire migration was not necessary.”
That may sound about as much fun as a root canal, but MDCMS includes a tool that allows users to preview a change process–try it and roll it back without committing. Although it would be an exaggeration to call it painless, it’s pretty close.
As the change management migration was in progress, Midrange Dynamics–which happened to be finalizing the latest version of MDCMS–added enhancements to its software to meet VIP’s unique needs as an ISV. Customer feedback went directly into product development.
While the beta testing was being done, both change management systems–SoftLanding and MDCMS–were running in parallel. When changes were made, it allowed them to be tested in both systems and compare the results.
“VIP was one of the more demanding environments we’ve gone into,” says Langen. “There were requirements for conflict management and other new functionality, beyond what their current change management solution offered, that we added to MDCMS. Working with VIP was like having an augmented testing team. When we added features, they pounded on it in testing.”
Having strong cross reference capabilities is critical for effective change management. When application changes occur, cross referencing reveals the effect of those changes throughout the system. For instance, when changes are made to a table, it’s valuable to know everything that references that table and how the new change affects all references, including those at the field level. Not all change management cross referencing tools have that capability.
“We are in a project now that involves obsoleting parts of the old system,” Garland notes. “Some apps have been replaced by Web apps and others are simply no longer used, so we want to drop them from our library. We use the cross reference tool (in MDCMS) to determine what the deleted program does to other programs that it calls.”
Garland noted the cross-referencing capability in TurnOver was sometimes inaccurate and SQL exposure was not good, a common occurrence among older CMS products where workarounds were often required.
“All of our coding for new data access now uses SQL. We are getting away from RPG data access and have been doing this since 2013,” Garland says. “We still have thousands of programs that do it the old way, but in the pieces of code that we are migrating to the Web these are written in the data-centric style.”
As this was taking shape, VIP was also streamlining change management processes it had been using for more than a dozen years. And on top of that, VIP was consolidating applications. Prior to the consolidation, each version of VIP’s ERP application included 54 separate add-on applications. After the consolidation, there were only four apps per version.
“If I were doing it over, I would have done those as separate projects and consolidated the apps first. That way, when problems occurred, it would be clear whether the consolidation or the migration was causing them. But the consolidation definitely had an effect on dragging out the migration process. The migration process itself worked very well. That might have been somewhat of a surprise because we were worried what might have happened. There’s always some worry with all projects.”
VIP purchased MDCMS (the core change management solution for IBM i), which includes MDXREF cross referencing, plus the MDOpen plug-in, which meets IBM specifications as Ready for IBM Rational software. New development is being done with Rational Developer for i.
The company has more than 300 customers in the United States and Virgin Islands, and approximately 75 percent of the customers run The Beverage System ERP in VIP’s hosted environment.
“Customers are willing to upgrade if an incentive is there. Our move from green-screen to Web-based applications was enough incentive to get customers to upgrade,” Garland says.
In the end, VIP was able to forge a business/IT plan that involved a substantial amount of legacy application maintenance along with new application development that is Web-based and new database development that is based on SQL. That’s text book modernization.
The lessons to be learned from the VIP example are: Don’t let the challenges of a migration project hold you back, evaluate your application portfolio, and recognize when it’s time to upgrade or migrate. The conversion of applications should not be a painful experience and it should provide efficient alternatives, technology improvements, and a cost-efficient option.