EvolveWare Sees Growing Demand for Application Rehoming
January 24, 2022 Alex Woodie
The COVID-19 pandemic has acted like an accelerant for IT modernization, as companies seek a better technical base upon which to launch new digital initiatives, often from the cloud. At EvolveWare, which specializes in migrating applications, 2021 brought a flood of business migrating applications off legacy systems, including big iron systems from IBM, and 2022 looks to be just as busy.
Miten Marfatia founded EvolveWare back in 2001 to address what he predicted would be a surge in application modernization in the new millennium. Marfatia had put quite a bit of thought into the company’s business model, and figured there was a sizable number of companies with aging applications and aging workers that would be looking for help with migration or modernization.
“My reasoning for getting into this space was that the support personnel for legacy applications were basically retiring,” Marfatia says. “I felt that by 2005 or 2006, there would be a shrinking talent pool that would spur organizations to modernize their applications.”
For example, one of the early customers that EvolveWare worked with was a large truck manufacturing company. Most of the developers who had supported the company’s application were gone, and the youngest person left on the staff who could support the application was 76 years old, Marfatia says.
While his reasoning was solid, he overlooked a couple of important factors, including offshoring. Companies in the United States and Europe discovered a large pool of technically savvy, English-speaking engineers in India and other countries who could support the old applications at a fraction of the cost of hiring local engineers.
Then the Great Recession hit in 2008, and the appetite for big, risky migration and modernization projects dried up. Companies realized they could keep the old applications running a little longer by utilizing stopgap measures, such as emulators. Even by 2011, the big swell of application modernization and migration projects that Marfatia expected had yet to arrive.
“My timing was quite wrong,” he concedes. “But what I was expecting would happen maybe 10 years ago, we are beginning to see that happen now.”
In the 20 years of business between January 2001 and January 2021, Marfatia estimates that EvolveWare’s core platform, called Intellisys, has been used to migrated 100 million lines of old code from the 24 languages that it supports to new platforms. But over the past 12 months alone, the company has processed 30 million to 40 million additional lines of code.
“We have seen a concerted effort by financial and insurance companies,” Marfatia tells IT Jungle. “We’re working with about four different insurance companies right now, very large ones, and they are making a very concerted effort in moving or modernizing their applications. We are beginning to see also automotive companies.”
Intellisys supports two dozen languages (RPG is on the roadmap), but over the past year, EvolveWare has seen five or six languages dominate, including COBOL, PL/1, PL/SQL, T-SQL, PowerBuilder, and older Java. “We’ve also run into some VB6 on a Hewlett Packard platform,” says EvolveWare CTO Bruce Kirchner.
A big chunk of the 2021 business came from the State of New York, which contracted with EvolveWare to document about 20 million lines of Unisys COBOL code into Operational Decision Manager (ODM), the business rules management system (BRMS) from IBM. While the government is not migrating its applications at this time, it eventually wants to move to the cloud, and it’s using Intellisys’ code documentation capabilities to prepare for an eventual move in the future.
The company also has experience working with IBM i applications. About three years ago, EvolveWare was contracted with a financial services firm to migrate about half a million lines of COBOL code off the IBM i platform and its integrated Db2 database. The language target was procedural Java and the runtime environment Oracle Linux. According to Kirchner, the entire project, including user acceptance testing, took about eight months.
Kirchner recalls several aspects of that IBM i COBOL migration that stood out.
“The first thing that we did, before doing any processing of code or really any work on the transformation itself, was to identify all of those external interfaces and understand what we needed to do, because IBM iSeries is a slightly different animal than a lot of the other mainframes from IBM, as far as how much accessibility your applications actually have to operating system interfaces directly,” he says.
“If you’re dealing z/OS, z/VM and those kinds of things, the accessibility to the operating system is somewhat limited compared to IBM iSeries, so there’s a lot of functionality that the i operating system provides that applications can use directly,” Kirchner continues. “And so we had to map all of those type of features that were being utilized or referenced by the applications to something equivalent for Java and Linux.”
Some of the aspects of the applications could be mapped to their equivalents on the Oracle Linux system, particularly the job scheduling. But there were a number of functions that didn’t map cleanly, such as COBOL’s use of shared memory on the IBM i platform, and those had to be hand-written for the new platform.
Whereas the software usually hits the mid-70s in terms of the percentage of code that can be automatically generated, this engagement was in the low 70s. “Our automation was a bit low because of some of the challenges on the IBM iSeries platform,” he says.
The automated code generation in Intellisys improves with time thanks to its pattern-matching system, Marfatia says. Whenever the platform encounters a pattern of code which it does not have a map in XML, it captures those patterns, and we as a support team will add those patterns into the knowledgebase,” he says. “So the more code the product sees, the better it becomes in terms of automation.”
As the months turn to years, legacy systems aren’t getting any younger. More importantly, companies are beginning to wonder who will support their aging systems as the senior staff members depart. This is bringing a renewed appetite for the risks inherent in application modernization and migrations.
“If you look at the landscape of the results of people who were trying to modernize their applications, all the way up until 2016, 17, I believe there were more failures than successes and successes were limited to smaller applications, because you can modernize smaller applications manually, even though you may not meet your schedule,” he says. “About three or four years back, people wouldn’t venture into a large-scale initiative of modernization, because A. the tools were not there and B. the past history was so fraught with failures that you don’t want to risk your job.”
As companies get more comfortable with migration tools and processes, that hesitancy to touch the legacy applications is starting to go away. They still want to move to a platform with more agility than what they have, but they also don’t want to abandon the highly customized business logic they’ve written over the years.
“I’d say they see quite a lot of value” in the custom business logic, Marfatia says. “You’d be surprised that some of the rules that they have are so homegrown and so important to their operations, that they just cannot do without.”
Financial services firms, insurance companies, and state and local governments have been contacting EvolveWare about its migration solutions over the last three months or so, with some federal agencies also reaching out. Marfatia expects organizations in other industries to reach out soon, as the potential upside of a more flexible application outweighs the downside of a failed IT project
“I think the others are kind of treading water right now,” he continues. “Either they want to do proofs of concepts or they’re starting with the smaller systems. But they need to get the apprehension out of the way.”