Casamba takes a different path to app modernization

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.

Project specifics

• Project start was January 2018.
• Six engineers--including one engineering manager--formed the migration team.
• Two members of the team were the original VB6 app designers.
• Initial field deployment of the .NET version started in October 2018. Deployment across the entire installed base of 100+ home health and hospice agencies was completed by April 2019.
• The separated financial piece contained 250K lines of VB6 code, no custom DLLs, several COM components used in the user interface (some of which had no .NET equivalent) and used ADODB extensively.

Guiding principles

Casamba's engineering team agreed on some basic principles they would follow during the project:

• Treat the VB code as an asset. Those 250K lines of code had been extended, refined, and field-proven over an 18-year span. The team knew that the business logic was sound. This was not going to be an opportunity to rewrite the application.
• "If it's not broken, don't fix it." Following the "do no harm" principle, code changes would be limited to what was necessary for the conversion. Refactoring otherwise functional code was not part of the plan.
• Keep the tool stable. Mobilize released multiple upgrades to the VBUC during the migration period but Casamba elected to remain on one version. They ran the tool hundreds of times and wanted to eliminate any potential issues from new releases.
• Once a migration process was defined, the team committed to keeping the process itself stable.

Project methodology

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.

Testing innovation

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.

Casamba took their own path

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.

Other issues

• Performance: The Casamba app uses XML structures to store snapshots of every insurance claim. The VBUC converts XSLT transformations via helper classes to make the migration as simple as possible. However, the helper classes added a performance penalty; Casamba was able to address this by using the native XslCompiledTransform class instead. 
• Code Quality: Like most large, complex VB6 applications, the Casamba application had been written by a number of different developers over its 18-year lifespan. Code quality varied according to who had written it: some code showed good separation of concerns and other not so much. Code that exhibited proper separation of concerns converted to .NET well--the UI code was simple and the business logic classes converted easily. Code that did not implement correctly separation of concerns was more difficult to migrate because the behavior was more difficult to trace.

Takeaways

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.