By modernizing its 25-year-old mainframe application, financial services firm Moorcroft Debt Recovery Group saved...
its own money for a change, according to Moorcroft Information Technology Manager David Pickering. For many years, the legacy app delivered just what the business wanted, Pickering said. The emergence of new application platforms -- server, Web and cloud -- began to make integrating the legacy app with others difficult.
The original set-up was developed in-house and written in COBOL. With each new link to another system, the more difficult it became to move off the mainframe.
"At some point we had to draw a line and say, 'We've got to get into this new world,'" Pickering said. Furthermore, the competition was able to do a better job of using business information Moorcroft was struggling to produce.
With 30 years of IT industry experience, Pickering knew something had to change if Moorcroft wanted to keep current clients happy and acquire new ones. As he saw it, there were three options:
- Do nothing and continue to build around the current system
- Buy a package to replace the in-house development
- Migrate to a new system
Pickering's team decided migration was the only practical option, largely because of the high cost of making the legacy app work. Once the decision was made to embark on an application modernization initiative, it was time to search for a replacement. Basic apps that allowed no customization were quickly ruled out. "There isn't a package that would suit our business on the shelves," Pickering said.
While the Moorcroft team didn't have a lengthy list of criteria, it wanted to be sure development could continue uninterrupted during the project because as Pickering noted, "Our clients don't stop their requirements."
While there were a couple of contenders, which Pickering didn't name, Moorcroft ultimately went with Modern Systems. The decision was based on the company's past history with migration work. "We talked to quite a few of their [Modern Systems] customers to get not just a feel for the technology and how they work, but for the people and whether they have confidence in the method they used," Pickering said.
Moorcroft knows a thing or two about risk, so they put an extra safeguard in place after selecting Modern Systems. A contract was implemented so that if certain requirements weren't met, it could pull out.
The implementation process was a challenging one, although Pickering knew that would be the case. To help reduce the risks associated with such a large legacy app migration initiative, the project was broken into three stages.
The first segment of the legacy app migration project involved replicating data from the mainframe to a SQL server. "That was quite the challenge in itself because it needed to be done in a timely manner and repeated every night," Pickering said. The second phase entailed taking existing reports in COBOL and moving them in chunks from running on the mainframe to operating in the new environment. Finally, batch updates were converted.
One of the big obstacles with the project was the result of Moorcroft's data structures, according to Pickering. "We were limited on the mainframe in terms of size," he said. "We did use some fairly technically clever, but businessly stupid, techniques for reusing data fields." That resulted in a data field being used for something for one client and another thing for a different client; which created minor hiccups when converting data.
To help iron out such issues, work from the mainframe ran in parallel with the new system for two or three weeks to ensure the results were the same. This too, however, brought on a new challenge. "We tried to use the same people for both [the work on the mainframe and new system] initially and that just didn't work because what we were doing for the business on any one day was always more involved than the conversion," Pickering said. The team realized that it would be best to have people specifically dedicated to certain roles.
After the completion of the project, Pickering collected some valuable advice. "Split up the risk as much as you can, [and] then you will have fewer sleepless nights," he said. "Just have few smaller implementations."
Maxine Giza is the site editor for SearchSOA and can be reached at email@example.com.