Casamba is a national leader in providing electronic medical record (EMR) enterprise software to skilled nursing facilities, outpatient therapy clinics, contract therapy providers, and home health and hospice agencies. Founded in 1997, Casamba's products are used by more than 275,000 providers across the United States.
In 2017 Casamba's executive team decided to segment the home health and hospice back-office software, convert the financial piece from VB6 to C#, and deploy the resulting application as a standalone desktop application. They chose the Visual Basic Upgrade Companion (VBUC) as the migration tool for this 250KLOC project.
This was a significant project. The financial application is used by providers to bill more than one billion dollars of services per year. Neither Casamba nor its clients could afford any disruption in the financial workflows supported by this application.
Casamba's engineering team agreed on some basic principles they would follow during the project:
The project team decided not to adopt a "big bang" approach where all the code would be migrated as a single block. They felt it would be easier to get to clean execution on smaller, discrete modules. Since the application UI is structured as a series of tabs, each tab area was carved out as a single subsystem for independent migration and testing. That partitioning task was challenging but was simplified by having one of the original app designers help with the separation.
However, the goal was not multiple executables but rather a single .NET assembly for all the financial functions. So as each subsystem class and its methods were successfully migrated, these were then checked into a "gold standard" code base. This code base was subsequently checked against additional modules that depended on those classes and methods, and fixed when issues arose. Clean, tested check-ins reduced the number of regressions, so the gold code needed relatively few bug fixes after check-in. After all the subsystems were converted, the gold code became the new app code base, and all subsequent fixes are made there, not in the subsystems.
The Casamba team executed a full suite of manual test cases by exercising all the financial verbs in the application. But they also wanted to be able to compare the functionality of the migrated application against the original VB6 application in a more thorough, and automated, manner. For one thing, the number of potential code pathways is astronomical due to the high degree of configurability of the application. Fortunately, the source application contains a financial transaction logging function that collected years of data about actual billing parameters. Potentially this data could be used to "rebill" every claim that an agency billed, and indeed, an auto-test application was built--using VB6--to "rebill" claims using the legacy VB6 application. A second auto-test application was built using the .NET financial code (migrated application) to generate the same claim set as the VB6 auto-tester but with the migrated C# code. The results of the two test runs were compared and any discrepancies were investigated and debugged. Using this methodology, close to a million individual claims were generated and compared. Several dozen bugs were thus identified that would never have been exposed via manual testing.
Mobilize's guidance to customers is always to migrate the legacy app as is and fix problems in the generated code. Some customers feel it would be better to first alter the VB6 code to make it easier to convert, but since this requires re-testing the source application our recommendation is not to do this. Casamba chose not to follow our advice:
VB6 eased programming in a number of ways, one of which was that it was not a type safe language. Variant types in VB6 can allow for the addition, say, of a form to a string. Or an integer to a school bus. C#, on the other hand, is a type safe language, and so the VBUC has to make implicit type casts when it converts VB6 to C#--it tries as best it can to understand what the "real" type of a VB6 variable is and cast it appropriately, but it can easily be fooled. Take this example from Casamba's project, for example:
Dim InsurerID As String InsurerID = 10
VB6 converts the integer 10 to a string at runtime. But the C# conversion sees the value 10 as an integer, and so the migration has an issue (note: the current version of VBUC handles this string cast correctly). Initially, Casamba would change the VB code as in this example:
Dim InsurerID As String '[rework-VB ' InsurerID = 10 '] rework-vb InsurerID= “10”
This VB change converted correctly to C#. Later, Casamba recognized that conversion issues such as the one above appeared multiple times in the code. Rather than change the VB, Casamba used a search and replace tool to find and fix common conversion patterns in the C# after running VBUC.
Like many other companies with huge, vital legacy applications, Casamba knew that rewriting the app would take years and that trying to manually convert the code would be impossible. After reviewing other automated migration tools, they chose Mobilize.Net's Visual Basic Upgrade Companion as the most attractive option. The VBUC has the advantage of migrating the code in such a way that the underlying business logic is maintained, reducing defects and risk. To learn why 80% of the Global 2000 rely on Mobilize.Net for their software modernization projects, contact us.