Code Search (Find, Follow), Analysis (Metrics, Static, Dynamic, Bugs) and Change (Modernization, Migration, Generation, Optimization, Rearchitecting)

Visual Basic 6 Software Migration

Semantic Designs and its authorized partner Nexaweb provide tools and services to help migrate Microsoft Visual Basic 6 (VB6) programs to new languages and technologies.

Applications coded in VB6 run critical business operations. Yet they are becoming difficult to maintain due to lack of available skilled people. Further, Microsoft has ended service and support for VB6 as of early 2008. Rebuilding such applications from scratch on a new platform is often proposed, but that process is long and painful, and often fails due to scope creep and missing knowledge about what the legacy application really does. Yet failure is not an option for critical business systems.

Automated migration of VB6 to modern platform such as VB.net or C# (on Windows using standard Microsoft technologies) or Java (on Windows or Linux avoiding Microsoft technologies entirely), with modern relational databases, is a cost-effective way to remove the dependencies on legacy techologies.

You can read more on general issues of Legacy Software Migration, but this page is specifically about migrating VB6.

Issues in Migrating VB6

There are a variety of problems that must be handled in migrating VB6 code:

• Form Conversion
  • VB6 applications use VB6 forms heavily. These forms are supported by special VB6 runtime libraries that are not available in the target context. New, equivalent UI screens must be constructed that achieve identical functionality using modern UI foundations.
• Database Conversion
  • Conversion of legacy data models to a Relational model. Many VB6 programs use ad hoc or indexed database schemes; these are not relational and definitely not normalized. Such data models should be converted into an efficient, maintainable Relational model, using datatypes supported by the Relational model as opposed to the legacy VB6 datatypes. A key consequence is that the placement and representation of the data in the database will not be the same and therefore data accesses and updates must change.
  • Conversion of legacy data base content into Relational database content. It is called "data processing" because ultimately these applications are about the data! The existing legacy database content must be extracted, converted to new representations, and moved into the new Relational form without losing any information. If the new target platform is not Windows, the data must moved off Windows.
• COM Interface and packaging conversion
  • VB6 heavily uses COM APIs to access a variety of Windows services, and often VB6 modules are packaged as COM modules. For services used, one must find or build replacement libraries. VB6 applications packaged as COM modules must be revised to not be COM, or to be packaged functionality using C# or Java equivalent technologies (e.g., web services).
• Native Character set conversions
  • Many VB6 applications have been code for national character sets, such as Japanese Katakana. Character strings for such languages are usually encoded using legacy Windows character sets. Such strings should be converted to Unicode. Alternatively, one might extract all the strings to a library, enabling online translation to make the application truly international.
• Code translation of VB6 to modern OO languages. The following changes must be achieved:
  • Legacy data types from VB6 must be replaced with equivalent C# or Java datatypes. Particularly troublesome is the Variant datatype, which can take on a variety of different types in different places in the code.
  • Spaghetti code cleanup. VB6 is a language with GOTOs, and poor coding practices often lead to VB6 applications which are a tangled mess. Java does not allow GOTOs, and while C# has them, usage is discouraged to ensure structured control flow. One should convert such tangles into structured code using only if-then-else, do and while, to maximize maintainability of the final result.
  • Objects should be inferred for the modern language. While VB6 Classes and Forms strongly hint at desired target objects, pure .BAS files do not and objects should be used to replace them.
  • The source code of the application must be converted to Java or C#. This includes replacement of control structures, and object accesses.
  • Screen input-output (typically Forms) must be changed to use the corresponding GUI or Web calls for the screen replacements.
  • Explicit legacy data access calls in VB6 must be replaced by database calls that understand the relational model and the representational changes. Reads and writes of flat files must be replaced by modern file reads and writes. Data Access Object calls should be replaced by explicit SQL statements.
  • External interfaces to other systems must be replaced by some equivalent
  • Accesses to COM-based functionality must be replaced.
  • Job Control and Scheduling must be replaced
  • Security must revised to support the broader accessiblity of the application
• Application Testing. This provide assurance to all parties that the result preserves the business logic and functionality.
• Maintenance change Integration. Migrations take time. The legacy application will continue to serve the organization during the migration, and business needs will force changes to the legacy application to even as the migration occurs. These changes must be moved into the migrated application.

VB6 migrations using Semantic Designs' DMS technology

It is the case the every organization's migration task is unique. While all VB6 conversions have these technology foundations, the other technology and organizational circumstances (other source languages, job control, security, external interfaces, architectural goals, ...) and a unique set of target technologies force customization of the migration to user's needs. SD's approach to migration using DMS ensures the flexibility needed to address the customer's unique needs are met.

Using DMS, SD's proprietary code analysis and transformation engine, SD offers clients two paths for VB6 migrations:

• Model based migration. This is the most popular path, and is handled by our partner Nexaweb. Nexaweb uses special DMS-based compiler-accurate VB6 analysis tool to extract models from the VB6 source code, and those models are forward engineered into Java applications. Special Nexaweb advanced Core and Platform libraries provide replacement services used by most VB6-based programs. Visit the Nexaweb site for more detail.
• Custom VB6 migration. Nexaweb's process works for most VB6 applications. If it is not appropriate, a custom solution can be implemented.

Custom VB6 migrations

Sometimes a model based migration is inappropriate due to the complexity of migration, interactions with other software systems, the need to re-architect the application, or the desire to use certain specific target technologies (e.g., C#). In this case, SD can provide VB6 migration services directly.

SD can automate VB6 migrations, preserving the business rules exactly, by translating the code structure more directly than through models, using a customized translator based on DMS and more sophisticated analyses and translations that DMS enables. The final result is still a OO-based system using modern databases and UIs. The issues above might be handled as follows, depending on the customer's needs:

• Form Conversion
• SD can design a custom UI to replace forms, as native GUI or HTML5 web-based forms. Sophisticated migrations may merge or re-organize forms to use screens more effectively.
• DataBase Conversion
• Data model conversion: DMS-based tools can automatically convert the set of legacy data models into a normalized relational model. Flat file record structure can be inferred, and corresponding tables created. Hierarchical databases can be located and converted to relational tables with appropriate indexes. The customer may rename fields and/or add additional keys. Data representations change from ASCII to ISO8859-1 or Unicode UTF-16 strings; decimal numbers can be converted to target relational database native data forms as appropriate.
• Database content conversion: DMS-based tools can be used to generate database content migration. This is accomplished by syntheszing VB6 programs and target language programs (Java, C#). The VB6 programs easily read the VB6 legacy data, and export the results as flat files; the target langauge programs read the flat files, convert the data representation as needed, and write the result to the relational data base. The generated data migration tools may be run repeatedly for testing purposes and to refresh the migrated code's database. One might choose to use an ORM such as Hibernate (Java or C# versions are both available) rather than a straight relational model.
• COM Interface conversion
  • Complex VB6 applications may be organized as large sets of COM packages. Analyzing the call graph for such packages can determine which ones are used as services and must be replaced, which are exposed as interfaces to the rest of the world, and must be be preserved as some kind of service (including retaining their COM-like nature under Windows), and which are completely internal to the the application and can be re-implemented as conventional packages or classes.
• Character Set Conversions
• DMS is fully Unicode capable, and can handle a huge variety of character sets. It is straightforward to read strings in one encoding, and regenerate them in an equivalent, but different encoding (e.g., Shift-JIS for Katakana).
• Code Translation
• Conversion of core VB6 constructs: SD migrates code by applying transformation rules to map the syntax of the source languages to OO target language syntax (e.g., Java or C#) in a way that preserves the semantics of the source code. This ensures that the generated program does exactly what the original program does.
• Handling of special idioms: Certain source language idioms need translation in special or efficient ways, including database access, screen I/O, and even clones in the legacy code. By writing custom translation rules, SD can ensure that the special cases are converted in the most effective way for the particular application system.
• Using DMS's data flow analysis capability, each use ("lifetime") of a data value, especially Variant types, can be checked to determine its type at time of use. Variant types that are used only to hold a single type can be safely converted to an equivalent, constant type. Decimal numbers can be checked for range and converted to longs or scaled longs to avoid the inefficiency of decimal arithmetic, without losing the nice conversion properties of decimal numbers for currencies. Strings can be determined to be in one representation or another, and appropriate encoding and replacements chosen.
• Using DMS's control flow analysis capability, the exact control flow of a VB6 function, subroutine or method can be determined. Unstructured ("spaghetti") tangles can be restructured into nicely nested loops. ON ERROR GOTOs over a range of statements can be converted into a structured block, then converted into try-catch constructs in the target langauge. In many case, RESUME targets can be determined, or at least marked for manual remediation.
• VB6 classes and methods can be converted to OO classess and methods straightforwardly. Additionally, STRUCTs can be converted to OO objects. BAS files can be treated as singleton classes. Use of clone detection can find repeated code that might be converted into additional methods for proposed objects.
• Database accesses: All VB6 data accesses to legacy databases will be replaced by idiomatic code in the target OO language, that satisfies two needs: a) it handles the data model changes caused by the legacy to Relational conversion determined by the data model migration tools, and b) organizes the data access according to useful architectural principles. For example, all database calls in the translated code might be abstracted in Hibernate API calls to implement an Object-Relational Mapping in the converted application. DAO accesses can be replaced by equivalent SQL or ORM calls.
• Forms accessess: VB6 access to forms will be replaced by idiomatic code in the target OO langauge to implement the types of user interfaces desired by the customer: GUI or HTML.
• COM Interface calls: Such calls will be replace by equivalent library calls, or by direct calls to the methods for the code in those COM objects which are actually translated.
• Job Scheduling: Applications are often controlled by scripting (e.g., VBScript) yet such scripts should not appear in the converted system. This is solved by providing a job scheduler (e.g., Quartz that runs in the target environment and translating the script calls into target language code modules executed by the target scheduler.
• Testing SD's migrations are tested several different ways using automated testing methods:
  • Unit testing of migration tool: each VB6 code element, and each interesting idiom, is coded as unit test in VB6, and verified that unit runs correcly as a VB6 program. The migration tool is applied to all unit tests, and the resulting OO unit code is executed; it will run successfully only if it correctly translates the semantics of the original program.
  • Functional testing of legacy application and the migrated version: The original application is augmented with tests of application functionality, coded in VB6 and verified for correctness in the original application context. These functional tests are translated along with the application code and indicate whether the translated application implements the functionality correctly.
  • Test Coverage Analysis: SD supplies Test Coverage tools for a variety of languages, including the targeted OO languages Java and C#. The functional tests are exercised to collect test coverage data for the VB6 program. The translated application is exercised, and test coverage is collected for that. The levels and areas of covered are compared to determine similarity.
  • Performance Profiling: SD supplies Profiler tools for a variety of langauges, including the targeted OO languages Java and C#. The translated application is exercised under essentially production load, and performance profiling is used to verify performance or spot bottlenecks.
• Ongoing change to legacy code: The SD process handles this easily and continuously. The legacy development team continues to revise the legacy database programs during the migration as though the migration were not happening. The automated migration tools can be used to convert the legacy application at any moment. Early in the migration the original legacy code base is converted and testing/tuning the migration rules starts. Late in the migration, a final snapshot of the modified legacy code base is converted and used for the final conversion and cutover. This ensures tha the final application is converted with all the knowledge gained during the migration, and the coding results are consistent across the entire system.

The bottom line is that automated migrations lower costs, time, and risks, and raise the quality of the result.

Assessment and Planning

Any large migration requires careful planning and support. Semantic Designs can

• carry out automated assessments of a source code base for troublesome constructs
• find/remove redundant code before conversion to minimize total conversion costs
• define an effective, economical porting plan with many visible milestones which minimizes risk
• determine how to handle special customer requirements effectively

To discuss migrations in more detail, contact us. Details about timeframe, your special circumstances, and desired modern target system configurations are extremely helpful.

Not ready to migrate? Tools to help you manage VB6

The decision to perform a migration is not an easy one. It is likely to be some time before a migration starts (if indeed it does), let alone ends, and the customer must enhance the application she has in the meantime. SD offers tools to support VB6 programming to help regardless of your decision or timeframe.