email article printer friendly more resources CBCR Ports Critical App to .NET Careful prep work smoothed the way for the Central Bank of Costa Rica (CBCR) to migrate its mission-critical VB6 app to .NET. by Lee Thé August 2003 Issue Legacy An n-tier in-house application of more than 1.3M lines of Visual Basic 6 (VB6) code in more than 250 assemblies, using a SQL Server 2000 database. Solution Prepare the VB6 code extensively to port to .NET, then use the Visual Studio .NET porting tool to move 90 percent of the code over. Later modify the app to include more of its functionality Web services. Tools • Windows 2000 Advanced Server SP3 • SQL Server 2000 SP2 • .NET Framework 1.0 SP2 • .NET Framework 1.1 (RC1) • Windows XP SP1 • Visual Studio .NET • VB.NET • ADO.NET • Microsoft Distributed Transaction Coordinator (MSDTC) • XML, XSL, HTML, DHTML • .NET remoting • Web services and Microsoft Message Queue (MSMQ) • Application Center cluster • Network Load Balancing (NLB) cluster Challenges • Business-critical system with large code base. • Large VB6 code base required conditioning prior to porting. • Early adoption issues—primarily because .NET Framework 1.0 has memory management problems, forcing the migration team to use .NET Framework 1.1 when it was still in beta. • The team was also asked to develop some new services for SINPE, which put the conversion process under greater time constraints. -->

While it's important not to lose sight of the adage "If it ain't broke, don't fix it"—even in the fast-changing IT community—it's equally important to stay abreast of new technologies. Forward-thinking businesses often realize that by leveraging new technologies, they're able to not only provide customers and partners with new and improved services, but also increase their market share—even if that means upgrading an application that "ain't broke." This is true of the Central Bank of Costa Rica (CBCR) when it embarked on migrating its existing n-tier in-house app to .NET. It saw past the possible migration problems to the potential for greater application functionality. At the same time, it was able to leverage a substantial investment in an existing code base. The secret to CBCR's success was prepping the code base properly and bringing in outside expertise on .NET porting. It took work to migrate the application—but a lot less effort that it would have taken to completely rewrite it.

CBCR has a reputation for being technically aggressive, and it made an early decision to port its business-critical application—called SINPE (Sistema Interbancario de Negociación y Pagos Electrónicos or Interbank System for Negotiation and Electronic Payments)—to .NET. The application provides realtime settlements and clearance-house operations for inter-banking transactions throughout the country. It comprises a private network interconnecting Costa Rica's top 65 financial institutions with CBCR. Its 250-plus software assemblies span more than 1.3 million lines of (mainly Visual Basic 6) code in an n-tier architecture employing a SQL Server 2000 database (see Figure 1). The application supports around 100K transactions or half a billion dollars per day, with up to 500K transactions on especially active days.

As soon as CBCR's IT group learned about .NET they started thinking about migrating SINPE to the new technology so they could boost performance and developer productivity, and move to a Web services paradigm. However, the IT group was also under pressure to develop a number of new services at the time. They decided to delay the migration project, but began to prepare for doing the migration a few months later. They were assisted by ArtinSoft, which makes the porting tool incorporated in VS.NET,and offers migration consulting services.

ArtinSoft consultants worked with Harold Murillo and Mauricio Arroyo, project leaders for SINPE, and their team of 10 software engineers to evaluate the portability of SINPE's VB6 code base. This assessment turned up a number of areas where CBCR could improve the existing code to increase performance in the existing application and make the future migration easier.

For example, late binding in SINPE's code base made it possible to introduce errors into the code that are hard to debug. In VB6 you can define a variable without changing data types; your definition can simply say there's a variable "counter." It can take any data type later on. However, in .NET, data types are classes; you can't leave the data type hanging. So you need to add the data type to all the definitions/variables in your VB6 code—at least as a variant or an object. It's not a good programming practice anyway. And, in general, the changes you should make to VB6 code to prepare it for migration are changes you should make anyway to produce cleaner, easier-to-maintain code. It's often a case of removing programmer "shortcuts" that create more problems long-term than they solve in the short run.