In-Depth
Unlocking Legacy Code
Mergers and acquisitions, Windows 7 and the Web are driving a legacy migration to .NET. Developers tell how they unlocked their old technology and made the sometimes-painful journey to the modern platform.
In 2008 Steve Pownall, chief executive of BEMAS Software Inc., knew that the company had to move beyond the Visual Basic 6 codebase that was used for most of its product line.
Microsoft had ended support for VB6 in March of that year.
A Microsoft Certified Partner, BEMAS (since acquired by Evolution Benefits Inc.) develops health care claims systems for the insurance industry and third-party administrators. In 2008, a lot of the larger insurance companies required security features dictated by the Health Insurance Portability and Accountability Act (HIPAA) and supported software. "They were concerned about our technology," says Pownall.
The company was also having problems on installations with third-party components, and with finding talented programmers who wanted to work on the older technology.
With 15 employees in 2008, and only a handful of developers among them, BEMAS wanted to migrate 300,000-plus lines of VB6 code in a client/server system that involved complex financial, invoicing and claims-processing features. The company decided to move to C# and .NET based on their installed base and market indicators.
"We felt that the least amount of risk was to convert it first, start supporting that [product] line and then move further to rewrite it so that it's more object-based in the future," recalls Pownall. "We did a few changes as we moved it over in support of our goals, but a full rewrite from scratch -- we just didn't see how we could accomplish it, either on time or on budget."
Like BEMAS, many companies are now faced with legacy code decisions as mergers and acquisitions, the promise of Windows 7 and the Web drive migrations to the more modern .NET platform. Many developers say .NET offers better tooling with Visual Studio and easier maintenance than older technologies. Modernizing legacy technology and grappling with architectural issues, decoupling of components and enabling code reuse can be an expensive and painful journey, especially if your dev team has to be brought up to speed on either your existing application or the new programming environment.
Migration Companion
The BEMAS dev staff was familiar with VB, but not C# or .NET. "We hired someone off the street, essentially, to head up the project," says Pownall. "The first three months or so were just getting him indoctrinated into what our product could do." A "lighter" developer from the support staff was also put to work on the VB6-to-.NET migration.
After conferring with the .NET project lead, BEMAS decided to use Visual Basic Upgrade Companion (VBUC) from ArtinSoft Corp., the professional version of the Visual Basic Upgrade Wizard that ships with Visual Studio 2003, VS2005 and VS2008.
"We support a direct migration to C# as well as VB.NET," explains Federico Zoufaly, director of marketing at ArtinSoft. "The tool that Microsoft has only converts to VB.NET. Over the years we've found that customers, because they have to migrate, they just go to C# because of some corporate decision not because one [language] is better than the other."
ArtinSoft originally developed the VB-migration technology for Mcrosoft, but the VBUC tool that the company sells today has diverged quite a bit from that technology, asserts Zoufaly. Several features -- conversion from ADO to ADO.NET, support for common third-party controls and error handling -- are designed to make the generated code more .NET-native.
With the Microsoft migration tool, the third-party controls aren't converted; it creates a primary assembly -- essentially an interop layer -- so that the COM components can be accessed from the .NET code.
The BEMAS developers spent several months analyzing their existing codebase. The VBUC helped the process by blocking out code, putting in comments and drawing attention to things like Windows API functions.
"We already knew we had issues with some of the older DLLs we were using," says Pownall. "We decided to replace those with some of the Microsoft standard stuff that comes out of the box for the grid control, for some mask edit boxes, things like that."
The objects that were in the legacy codebase came over very cleanly, according to Pownall. "When we didn't have objects, instead just sort of a spider web of code, it converted the code quite well but it still required some massaging to get it to run the way that we wanted it to," he says.
"We also ran into some issues with the conversion tool because early on in the VB code we did a lot of #ifs, which means that the code acts differently depending on how you compile it," Pownall adds. BEMAS worked with ArtinSoft so that VBUC would recognize those instances and convert the code correctly.
Overall, two-thirds of the source code came over fine through migration. The dev team had to massage or opted to rewrite the rest of the codebase manually in C# and .NET 3.5 using VS2008.
Manual Labor
"The majority of it was that way because we chose to do it quickly," explains Pownall. "Now we're going back and looking at making it more object-oriented in the areas that make sense," he says. "We also have a Web product that's already in C#, so what we're trying to do now is basically analyze all of our data structures and merge down at the object level. We would've been unable to do that if we tried it any other way. It would have taken us too long to rewrite it and start from that direction."
"Typically we migrate around 95 percent of the code," says Zoufaly.
"It sounds like you only have to touch 5 percent of the code, but in reality, 5 percent of the manual work is actually spread throughout all of the code, so you have to be familiar with all of it and actually make the fixes.
"Because this is an automatic tool, when it finds a pattern that didn't convert automatically, it generates Error Warning Issue [ERI] in the actual code," he continues. "Going through those ERIs is a pretty mechanical task; you learn how to fix it once but then you replicate the solution throughout all of the code very easily."
The automatic migration process is different from a normal development process, where you might build one module, test it and, when it works, move on to the next one. In an automatic-migration approach, you work in parallel across all of the code. "You have to make adjustments and then suddenly everything will run," says Zoufaly.
"If your source code is very computationally intensive -- you have a lot of algorithmic code -- then that gets translated into .NET very cleanly and you don't really have to refactor," Zoufaly explains. "If you didn't follow best programming practices in VB6 in the first place, the migration tool doesn't really change the architectural aspects of the application."
Some of BEMAS' manual work was based on architectural decisions. "We decided to take out a lot of the database access that was embedded in our code and write our own library for database access," says Pownall.
The developers worked on other areas of the codebase that needed to be massaged or refactored, such as Crystal Reports, interfaces to Word and Excel, and things like scanning and e-mail. "All of that we identified early that we needed to pull back out; not really convert it, but rewrite it so it used more of the native .NET," says Pownall.
The project cost "an extra individual" over initial projections. The two BEMAS developers worked on the project for 11 months, and then a higher-end C# developer and a couple more people were added to the project at the end "to slam it through the last three months," explains Pownall.
Part of the reason was the VB code was still changing. "We did the first migration and now we've gone back and done two other migrations for the delta of what has changed from the baseline -- that takes a lot more manual work," he says. "We decided not to try to use the automated tool to do that and instead just carry the code over and convert it using manpower. We went back and forth on that decision, too, but that's the decision that we finally settled on."
Testing and Performance
The client/server product is in the QA phase and is scheduled for the company's August release. "We said we'd be done in December of last year and we slipped to January to get it to QA, so we're on track," says Pownall.
The QA team, which is using IBM Rational, didn't know the BEMAS product well enough, so people from training and documentation were added to the project. "The trainers train on our VB product and then the QA people repeat that testing with the C# product," explains Pownall. "Any bugs that are found are turned over to the developers to fix and then the trainer comes back and trains them on the C# product to make sure that it all works as planned -- but we can do a little more rapid QA of the end product."
Performance has been very comparable or better in some cases, according to Pownall. "I was surprised, actually -- I was expecting more degradation than I've seen in the product."
ArtinSoft says migration projects are complete when the software has achieved functional equivalence with the legacy program. "You know you're done when you run the same set of test cases and the results are the same," says Zoufaly. Sometimes companies don't have test cases, but a power user can learn the app and make sure that it does the same thing; that person should be part of the migration team.
Unit tests will tell you whether it works, but performance is often determined by how reliably apps function under heavy loads in the target environment, observes Andi Grabner, technology strategist for dynaTrace Software, makers of dynaTrace.
Performance problems resulting from architectural issues often arise when developers migrate legacy code to third-party frameworks such as nHibernate, or even SharePoint.
"We've seen a lot of problems with SharePoint because people think, 'We can use the SharePoint object model to write great extensions,'" says Grabner. "But they don't know what's going on under the hood."
Application performance software can help developers address some of these issues during the dev process. "We extend the visibility of your functional unit tests into a performance architectural test," Grabner says. "We can tell you, for example, this will become a problem in the future because you're calling too many SQL statements or Web services."
Not a Long-Term Strategy
Despite a rough economy in which many projects are on hold, ArtinSoft is seeing more VB6-to-.NET projects in 2010. "People are beginning to think beyond the short term," says Zoufaly. "Especially enterprises, because they know that VB6 is not a long-term strategy."
Eventually VB6 apps won't run anymore, asserts Zoufaly, especially as the industry moves to Windows 7 and 64-bit systems. VB6 runs components in 32-bit mode. Already Windows 2008 R2 ships with the 32-bit mode disabled in the default configuration.
Microsoft has also moved on with Visual Studio. Unlike earlier versions, VS2010 doesn't provide a VB6 migration tool. Developers who need to upgrade VB6 apps will have to use earlier versions of Visual Studio and then upgrade their projects to VS2010, which is expected in April.
"We're working with Visual Studio integration partners to provide new versions of tools and services to migrate Visual Basic 6 applications to Visual Studio 2010," says Matt Carter, director of Developer Platform and Tools Marketing at Microsoft. Microsoft's VB migration resources can be found here. The next version of VBUC will support the new project system and other features in VS2010.
When companies start migration projects, it's important to go through an assessment stage. What's the target architecture that they're trying to achieve? What's the cost associated with the migration? Do they want to include new functionality or not during the migration process? Do they want to go through a staged or "big bang" approach?
Modernization in Stages
Gradual migrations in which developers write new functionality in .NET or migrate modules one by one "are OK -- and they work," says Zoufaly.
The downside is the complexity of maintaining two systems. "You take one of those DLLs and move it to .NET, then you have to actually build interop with the VB application," Zoufaly explains. "Now you have a system, at least for a period of time, where you need to maintain the functionality in VB and in .NET and you have to maintain a connection between the two technologies."
Sometimes rewriting part of your existing code is the only path to app modernization. "We needed a common language to develop our client-side tools," says Marc Firenze, chief enterprise architect at Eagle Investment Systems LLC.
A wholly owned subsidiary of Bank of New York Mellon, Eagle Investment Systems sells investment accounting, performance measurement and data management software to its parent company and the financial services industry. The company's product suite is a multiplatform -- Solaris, Linux, Windows and Apache Web Server -- enterprise application with an n-tier architecture that sits on top of Microsoft SQL Server or Oracle databases. Eagle wanted to modernize the user experience on the smart-client tier, which featured a host of different technologies: HTML, ASP, Delphi, C++ and ActiveX controls.
After doing analysis on the user community and its own engineering talent, the financial software company decided to move to .NET 3.5 and rebuild the UI using the Windows Presentation Foundation (WPF) framework. The goal behind the migration: The improved UI would ultimately reduce support costs and training, and position the company for global expansion of the product suite.
Eagle worked with Microsoft ISV Architect Evangelist Jason Delorme and participated in multiple architecture design sessions with staffers at the local Microsoft office in Waltham, Mass. "We hired usability consultants to help us with graphic design and usability treatment," says Firenze.
For the hard-core engineering, Eagle used about eight to 10 of its own developers, who were quickly able to get up to speed on .NET, says Firenze. The team used both Visual Studio and Expression Blend, which facilitated collaborative work between designers and developers. "There wasn't much code reuse that we could do because we totally migrated the platform from Delphi to .NET," says Raja Tummla, Eagle's team lead and technical architect. "It was basically a rewrite. From a code-reuse perspective, we used Microsoft's CAB [Composite Application Block] framework and their Enterprise Library."
The WPF databinding and refactoring tools in Visual Studio offered a huge improvement over how things were handled (hand-coding in Delphi, for example) in the existing codebase, Tummla says. The gradient and vectoring in WPF were also an improvement, but "the rendering experience on animations or transformations was not great, so we tended not to use it unless it was required," he says.
The Eagle developers didn't alter the legacy functionality in most cases, but they did reorganize and refactor to improve the user experience by streamlining workflows, rationalizing the features and functions of the suite and improving the UI.
"What's enabled by WPF is the experience and the controls and the accessibility and the time to market," says Firenze. "Our app suite is much more like Excel than any app that you see on the Web," he continues. "So, we chose to stick with pure WPF and not Silverlight. But it's something that we're keeping our eye on as the capabilities of Silverlight improve and mature."
The major challenge was in compartmentalizing the application suite and making it so that one component was loosely coupled from the other components, Firenze says. "When we found duplication, we identified what we wanted a common function to do, made a determination as to where to build it [and] how to build it, and then architected it so that it was loosely coupled from the other components so that it was more streamlined."
The client software has shown improvements. "I don't know if it was WPF or the .NET Framework, but we've seen improved performance and stability. Stability is more important," says Firenze.
Eagle tried to take advantage of the Microsoft ClickOnce deployment technology, but its multiplatform environment created some issues. "To deploy, we had to 'sign it,' and signing doesn't work on the Unix server," says Tummla.
ClickOnce has tremendous benefits, says Firenze, but packaging and deployment needs to be considered up front as part of the overall plan. "We should've spent a little bit more time on it. There was some work that we had to do that we didn't consider."
"Our experience with WPF has been great," says Tummla. "You do have to do some optimization."
The dev team has built the basic framework and is starting on a huge list of components for business-specific units that have to be rebuilt. "We have four of them converted into the new framework," Tummla says. "Then we have to do it for 25 more components."
"Our next goal is to port about 40 percent of the remaining codebase over the course of this year, and then the remaining 60 percent next year," Firenze adds.
Leaving a Legacy
Ultimately, the decision of whether or not to migrate an existing codebase should depend on the technical quality of the code, how important the app's functionality is to the business, and how frequently you make changes to the app and have to maintain it.
"If it has been working for the last five years with only very minor changes, then leave it as is," advises Zoufaly. If the app is important to the business and mission-critical, then the migration or the transition to .NET really injects new life into the application. "When you extend the life of an app, you're increasing the ROI on the original source code," he says.
When you talk to developers, it's always better to start from scratch, observes Zoufaly, but people forget how expensive it is to develop the source code and, ultimately, migration tools reduce the cost and risk.
"Companies will say, 'Yes, but I want it to work on the Web.' OK, what functionality do you want to expose to the Web? Everything, or is it some reporting and pieces of the user interface? You really need to make an assessment and see if it really makes sense to rewrite," says Zoufaly.
A typical developer can move 40,000 to 50,000 lines of code per month using a migration tool, according to ArtinSoft. "If you can compare this number to a rewrite, you can immediately see the difference in cost," Zoufaly notes. "In testing costs, it's about the same."
The majority of companies may still be on Windows XP, but the inevitable migration to Windows 7 will spur a lot of legacy code updates, from UI modernization to VB6 migrations.
"Right now about 98 percent of our clients are on XP, but we're seeing some acceptance of Windows 7. Some of the larger ones are talking about rollouts," says Pownall. He cites HIPAA regulations as the reason for some of the activity, because Windows 7 supports whole-disk encryption.
"I think [companies] need to do it sooner rather than later, just because Windows 7 looks like it's going to hurt quite a few applications out there when it comes to the legacy apps," says Pownall. "So I suggest people start on the project -- if they haven't started already -- to try to get it out, because Microsoft's not slowing down any."
Despite the challenges with the migration project, Pownall is not upset with Microsoft's decision to end VB6 support. "I think they handled it fine. I wish there was an easier migration path of VB6 to .NET, but I understand that sometimes to advance technology you really have to reengineer it a little bit. This has been very painful and very expensive, but I think overall Microsoft did the right thing."
Like many companies, the migration project at BEMAS is only the beginning. The company was acquired last July by Evolution Benefits, which is already a C#/.NET shop. "We're working on integrating their functionality and our functionality together as one product and making that available also as a Web-based product," says Pownall. "That's our long-term goal."