Print

How to handle your own great migration



Email
June 27, 2012 —  (Page 2 of 3)

In addition to identifying likes and dislikes, find out what features are missing and what steps are still taken manually, said Maulik Shah. “All this should be factored into the new system.”

What’s missing is often the result of business processes that have changed substantially over time, noted Zeon’s Yash Shah. He recommended focusing on two key questions at the outset of migration projects: “What processes have changed and need to be redone? What do [the application’s] users do now, and how do we design the new app to support that?”

Once those questions are answered, the team can begin to prototype the new workflow, but don’t write the code, said Yash Shah. “Map out the steps, visualize what’s involved, and continue to work with the people who use the app,” he said.

First modernize, then migrate
Migration projects are all about moving away from mainframes and minicomputers. But the aging systems aren’t always abandoned entirely, said Ross Mason, CTO and cofounder of MuleSoft, which sells integration tools and services. “Large banks and insurance companies, in particular, continue to store data on the mainframe, even when the business application itself is migrated to a modern platform,” he said. To enable the modern app to get at information housed in older systems, the data is wrapped in a services layer, he said.

The services layer essentially restructures the mainframe codebase, added Steve Gapp, president of LANSA, which sells app development tools and services. “That means even a young .NET developer [for example] can easily be instructed to the call the service.”

Determine the data structure
Modern apps may pull data from the mainframe, but they also need access to other information sources. It’s crucial to design the application with this in mind, said Stefan Andreasen, founder and CTO of tool maker Kapow Software. “You have to restructure your data for the new world,” he said.

He offered an example of how the older systems differ from new ones: “Older systems typically have no references to outside data. Any references point to data that resides in the same application.” But modern systems must be designed to reference data from outside sources, he explained. Structuring a modern application this way makes it easy to grow the application in the future, adding new data sources as needed, he said.

Getting the data structure right also entails devising a common way to represent things like customer records across all data sources an application interacts with, said Mason. “The same customer may be represented different ways in different systems, so you have to determine what the master customer record looks like,” he said.

He said it’s easy to overlook this issue at the outset of the project, and Andreasen agreed. “It’s the No. 1 failure we see [in migration projects]. The team hasn’t sat down and taken the time to understand how to structure the data,” he said.


Related Search Term(s): legacy apps, migration

Pages 1 2 3 


Share this link: http://sdt.bz/36725
 
Most Read  Latest News  Resources

close
NEXT ARTICLE
webOS no great loss for developers
HP wasn’t able to build momentum for the former Palm operating system Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
MAY 2013 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?