Legacy migrations are the second-class citizens of app development shops. At first glance, they appear smaller and less significant than from-the-ground-up projects. But, in reality, they require enormous effort from analysts, architects, coders and testers.

“A lot of folks don’t understand what’s involved. They don’t appreciate the magnitude of the effort required,” said Yash Shah, director of software engineering for app development consultancy Zeon Solutions. “There is so much detail to consider, so much investment in time.”

Yash Shah and other legacy migration experts shared best practices for succeeding at these challenging projects. Not surprisingly, migrations require many of the same skills as other development efforts. Even in cases where code can be ported from the old app to the new, there is always planning, coding and testing involved. The advice the experts offered focused primarily on app development practices that are especially relevant to migration efforts.

Understand the scope of the project
His recommendation is to group sets of apps that fit logically together, such as those for warehousing or those for accounting, and plan to move them at the same time. “You have to understand at the outset the implications of moving one but not all,” he said. It’s also important to factor in dependencies to off-the-shelf applications, he noted.

Dig deep and fix the flaws
It’s age-old advice but it bears repeating: Make sure the app does what people who use it need it to do. “Even though you are replicating the existing system, you need to ensure you are not redeveloping functionality that was incorrectly defined in the first,” wrote Joy Beatty, in a blog post published by app development consultancy Seilevel.

Moving an existing application to a new platform offers an opportunity to address the drawbacks of the older system, added Maulik Shah, cofounder and CTO of app development consultancy Mantra Information Services. “In any app, there are features users like and features they dislike,” he said, adding that it’s crucial to dig deep and find out what they are. “Talk to the people who use the software every day.”
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.
Conduct a data migration analysis
Migration projects present other data challenges as well. The team has to figure out what data is essential to the new app and what’s not. “Someone has to make a decision as to the right set of data to migrate,” said T3 Technology’s Townsend. This is often more complicated than it initially appears. He gave an example of a bank that would have a set of data at each of the local bank branches, and a set at the bank’s headquarters in Zurich, Switzerland.

Migrations that involve data subject to government regulations, such as the data privacy rules stipulated by the Health Insurance Portability and Accountability Act, further complicate matters, said Zeon’s Yash Shah. “Data is always important, and even more so when it’s subject to compliance mandates. You need to analyze what data must be ported over,” he said.

Mantra’s Maulik Shah offered an additional piece of advice: Don’t overlook historical data that dates back many years. “It can be useful, and if you don’t migrate it, you have to set it up yourself at the get-go,” he said.

Automate data access and analysis
How you get at the data matters, too. “When data is pulled from dozens of sources, you need to do it in an efficient way, using tools to automate the process,” said Ibrahim Surani, CEO of data integration tool maker Astera. Once the data is in hand, profiling tools can help clean it up by creating rules against which to measure the data, he said.

A final step involves reconciling the data moved from point A to point B. “How do you know if you have moved it correctly?” said Surani. “Compare the two and reconcile them.”

Avoid the “big bang switch”
Migration projects are often associated with the idea of “changeover at midnight,” said Andreasen. “But don’t think in terms of the big bang switch. It scares everyone,” he said.

It doesn’t make sense to shut down the old system and start the new one, added Maulik Shah. “You want to slowly phase out the old app, transitioning small groups to the new app one at a time.”

Starting small can minimize the impact of the changeover, said MuleSoft’s Mason. He offered an example: “An insurance company that offers auto, homeowners and life insurance policies might choose to migrate life insurance customers first, since that segment represents only 5% of its business.”

None of this happens overnight, added Yash Shah. “In a large company, you phase in one location at the time,” he said.

Until the transition is complete, the new app and its legacy counterpart should run side-by-side, said Surani. “Make sure you build a bridge between the two of them. How they interact during that period is important,” he said.

Don’t let past failures intimidate you
In many shops, migration projects have a bad rep, noted Andreasen. There have been many failures, and as a result, managers are afraid to undertake these migrations projects. “But if you do it right, in a modern way, migrations can turn into something good,” he said.