How is Mobilize different | Mobilize.Net

In past blogs we've talked about when automated migration of legacy apps makes sense compared to a full rewrite--usually when you have significant business logic in the code which you don't want to recreate, or when you have a need to move from client-server to web quickly, or when you want to save a great deal of time and money. Migration isn't the best course of action all the time, but frequently is for classic forms-over-data client server style apps.

So assuming you've decided to go down the path of migration using automation, which toolset/vendor do you pick? 

A quick Google search (or Bing--hey, I still love my old employer) will show you a number of different ways to migrate, for example, from VB6 to .NET. To go from client server (VB6 or .NET) to a web app is a tougher problem and fewer choices exist. I will cover those in a subsequent post.

We're familiar with most of the approaches to the VB6 to .NET problem, and I think I can safely categorize them into a few buckets:

• Syntactic translation: Probably the least useful, this is a simple approach that just tries to rewrite the syntax of the old code into the corresponding syntax of the new platform. For example, the tool can find "On error goto" and convert it to a "try catch" syntax. This approach is relatively useless because it can't address the runtime difference between VB6 and .NET. Nor can it convert the forms.
• Runtime translation: This converts the code using syntactic translation but leaves it looking a lot like the original VB6 code, using a binary runtime to map the runtime calls from source to target. This can get an app running quickly on the target platform, at the expense of a dependency on a 3rd party runtime. Additonally, it leaves the code in a weird "not VB6 but not really .NET" state. For applications that need to be maintained and improved, this is probably not a good solution. Furthermore you have the dependency--a vendor recently dropped support for one of these and the user base immediately started scrambling to figure out what to do. Not pretty.
• The workbench: This is a sort of interactive "super GREP" where the developer has an IDE she can use to examine code blocks and define specific mappings, usually with some degree of pre-determined automation. For a small, simple app this could be a viable approach, depending on the ratio of automation to actual dev time required. For a larger app it can introduce some issues as multiple developers work on discrete sections, perhaps using different rules or coding standards compared to other team members. 
• The Mobilize approach: From the beginning we wanted a different way to do this, something that would consider the entire app, not just a line-by-line analysis. Using the same concepts as a compiler, we create an abstract symbol table from the source code, a structure that shows all the interrelationships of the code. Using that AST, we then iteratively refine the code that is output until we have the entire app migrated.  The output is an entire code base--with no binary dependencies--for the development team to start working on (in order to clean up issues the migration tool was unable to resolve). 

Some of the fundamental ways we are different from other approaches include:

• The original Microsoft solution: Microsoft picked us to build the Visual Studio extension (Visual Basic Upgrade Wizard) years ago. After looking at every other solution, they chose our technology. You should too.
• We always default in favor of better code quality--rather than create a line of code that is sub-optimal, we'll comment it and let the developer know what the issues are. 
• We support a lot of the old VB6 3rd party control ecosystem.
• We include some helper classes to make the transition simpler, but those are all provided in source code to eliminate any dependency for future support.
• We preserve namespaces, comments, filenames, etc. Any developer familiar with the original code base will recognize the new code base, given that it's now in a new language calling a different set of libs.
• Custom mappings are available. Got a proprietary dll that needs to be transformed? Using an obsolete component with no current version? Want to implement error logging on any exception that is thrown? All things (well most things) are possible through customizations. In effect, we can create a unique version of the tool that's design specifically for your application to future improve your team's productivity. 
• You choose the handoff: We support a full range of DIY options from everything to nothing. If you have a dev team and all you want is tooling with support we offer it. If you want us to migrate the code to the point where it compiles and you do the rest, no problem. If your team is focused on other work and you just want someone to do the whole project, QA included, we do that too. And we've done it for just about anyone you can think of. 

We can move your VB6 code to .NET or the web. Find out how today.